Google Webmaster Central hangout: Jobs Postings markup

Google Webmaster Central hangout: Jobs Postings markup


MARIYA MOEVA: OK, we are live. Excellent. So hello, everybody, and
welcome to this special Google Webmaster Hangout on Air,
which is dedicated specifically to the Job Search feature. And we’ll talk a lot about
it from the perspective of a content owner
who is posting jobs either on their site or
on the third-party site. And we’re hoping to cover
the main points of how to get this done if
you’re interested in this. And then, once you
have it implemented, how you can see if
you’re doing well, what you’re getting
out of it, as well as if you’re having any troubles,
how to implement the debugging flow. And I’m hoping that there will
be some pleasant surprises along the way. We have a lot of stuff
that we’re working on, and I’m going to share with you
tonight a sneak peek of some of those things. So be prepared. We’re going to start with
a short presentation giving an overview of everything
in terms of the process. And then, we’re going to cover
the top questions that we’ve seen coming again and
again through our forums and from different other
partners who have implemented. We also have a
lot of people here with us today who will share
some of their experiences since they’ve already
implemented this markup. And so we’re hoping
that this will be useful for everybody in
terms of learning how to do this and then maybe
troubleshooting as well. So I’m going to go ahead
and get started and show you the slides. OK. So I’m hoping that everybody
can see the slides. Yes? All right, great. So together with
Sofia and Stacie, we’re going to go over the
basics and the fundamentals of the job search
experience feature. But taking a step back, why
are we doing this on the Google side is that we’ve noticed this
is a critical user journey. A lot of people do this
many times in their life. And we wanted to make sure that
it’s easy and well-organized for them. It fits very nicely with
overall Google Search mission. And here’s how it actually
looks like from a searcher perspective, and we’ve built in
many, many interesting features along the way to make
it easy for them. So if someone searches
for a specific position in a specific location– and currently, this is
available to searchers in the US on Google.com. They will see this new
jobs search experience, where there will be
different listings, which are matching to their query. And then, they can
expand this and browse. There is a lot of different
options to filter– by location, by company,
and different other factors. And finally, once they pick
something that is interesting, they can zoom into
the specific job and see a lot of
the details there. And they can actually apply
also directly from this feature. And sometimes, there
is one provider, and sometimes, there
are multiple options to apply through different
channels for the same job. So recently, we added
also other features, like the ability to save
specific jobs and get alerts. And then also, we’ve added user
reviews and the salary ranges from various providers. So we’re trying to do
as much as possible to make this easy and
interesting for users. But as a content owner
and maybe an employer, how does this
actually benefit you? So we thought about
this a lot to make sure that this is equitable
for everybody. And in fact, there are quite a
few benefits for site owners. So first of all, instead
of the standard blue link with a title and a
snippet, you actually get a much more
prominent treatment in the search
results, which results in increased discoverability
of your content and then also results in
increased convergence. Because a lot more
people will be coming over to the job listings
and then eventually applying. And we actually have
here someone with us from ZipRecruiter. So I was hoping that
maybe they would be willing to share
some of their experience since implementing the
job search feature. MISCHA: Sure happy to. Hi, I’m Mischa. I’m a product manager
at ZipRecruiter. MARIYA MOEVA: Hi, Mischa. MISCHA: Hello. Do you have a specific
question, or do you want me to just kind of
talk about our experience in general? MARIYA MOEVA: Yeah,
I’m just curious since you implemented this what
kind of changes you’re seeing. And how has it been
for you overall? MISCHA: Yeah, I mean,
the biggest thing we noticed when we implemented
the structured data and saw our jobs
growing up on Google– as you can see on
the screen shot– is that the traffic we were
getting from Google organic was a lot more qualified. The difference here is that
job seekers before would just search on Google, see a quick
title tag and a description, three or four lines of
text, and click through, hoping that they’re going to
find what they’re looking for, which was good. But this is much better. In the Google Search
experience, job seekers can see not just the title,
company name, and location, as you can see here. But once they click
on a job on Google, they’re able to see the
job description, read reviews about the company,
even see the salary range and how it compares to salaries
in general in the area. So by the time they’re coming
to ZipRecruiter to apply, they’re already much
more pre-qualified than they would have
been if they just clicked a regular Google link. So what we saw was a huge
increase in conversion rate from the traffic that we were
getting from Google to our job pages, because we think
that job seekers are now a lot more educated by the
time they come to our site. And they’re basically
ready to apply. MARIYA MOEVA: That’s
super interesting. Thanks a lot for sharing that. So in terms of implementation,
there is basically three things that you need to make sure
are happening in order to get to the listings. The first is make sure that
the pages you’re actually trying to show are indexable. There’s multiple
cases where we’ve seen the markup is in place,
the site map is submitted, but the pages are
not accessible to us. And that makes it harder to
show them, as you might imagine. Then, once you’re sure
that this is the case– so there’s no noindex meta
tags or any other issues at the markup– usually this happens either
through some kind of plugin. Or depending on what
type of CMS– maybe you have some kind of
custom in-house CMS– so you would be adding the job
posting markup through that. And we recommend using JSON-LD. Although, you could choose
to use other types of markup as well. But all of this, including
what are the required fields and what things you
need to include in order to make a very comprehensive
job posting– so not just reports but also nice-to-haves
are listed on the developer site in the Jobs section. So finally, after you have
all these jobs marked up, let us know about them
by submitting a site map. And here is a very key part. It’s really important to
keep everything up to date, because jobs are
quite short-lived. And if you submit one site
map and then these jobs– these vacancies are filled,
but they’re still indexed, and we might be showing them in
search results, that would not be a great experience for users. And anyway, it’s not going to
lead to any meaningful traffic for you. So make sure to update the
site map quite regularly. Depending on how frequently
and the volume of job postings that you have on your site and
how frequently they change, you could be updating the site
map anywhere from once a day up to every hour. And for sites or content owners
that have more than 100,000 job postings, we
actually have a forum that you can get
in touch with us. And then we can
think about, what is the best way to share these
postings with us so that we can get the freshest
information and display it in Search for the users
that are looking for it? And then another thing,
which is often omitted, everybody always wants
us to crawl and index as frequently as
possible to make sure that they have the freshest
version of their pages in the search results. But the host load, or how
much your service can handle in terms of requests
from our Google bots, is an important part
which people sometimes neglect to think about. So if you’re sending us a site
map with hundreds of thousands of entries and we try
to crawl these entries and we end up getting
Temporarily Unavailable 503 HTTP status codes from your
server, then we will back off. And we’ll start
crawling much less. So this is something
to keep in mind. And if you are not specifically
responsible for how to handle these issues, to
talk to your technical team to make sure that
this is something that the site can handle. And if you have only a few
jobs that you want to offer and you are not interested in
dealing with all of this stuff, you could just post them
to a fairly large set of third-party sites that we
have listed on our Help Center, including ZipRecruiter,
LinkedIn, Glassdoor, and so forth. And since they already
have this implemented, your jobs will also
be available and shown through their platform. So that takes care
of everything, and you don’t need
to do anything. And you will just get
applicants through them. So once you have
this implemented, then the next step is actually
to monitor what’s going on. And we know that it’s
a key thing for people to be able to see, OK, how many
applicants did I actually get? What is my conversion rate? And so forth. And therefore, we have- together
with the job search experience, we also launched a
feature in Search Console. So if you’re a verified
owner of the site, you can actually
see for job listings and job details clicks
and impressions. So this would look
something like this. You would be able to filter
for job listing or job details. And then, you would be able
to see things like queries and trend over time,
how many people saw these listings, how many
people actually clicked through to the job detail. And you’re able
to slice and dice here and see what’s going on and
what you’re actually getting. Now, the part which
people come to us most often is actually
when there are issues. And let’s say we
are not discovering all the different listings,
or we’re discovering them but we’re not indexing them,
or we’re indexing them, but we’re not serving them. So there’s a bunch
of different tools as well in order to make sure
that everything is going well. And the first of them is
the existing Search Console. It’s this Rich Cards report,
where there is a job section. And it’s possible to see how
many cards are completely invalid, so they
have critical errors, and then how many
are OK, so they have the basic required fields
but are actually not fully enhanced. So you could add
a few more things to make it a even richer
experience for users. And this is available
now in Search Console. But what I’m really
excited about and wanted to give you
a sneak peek of today is the new version of
Search Console, which, if you keep up with
announcements on the Webmaster Central blog and
the Twitter account, we actually have launched a beta
testing group of the new Search Console. It has a completely
different user experience. And one of the first things that
we wanted to implement there was actually jobs reporting
and debugging options. So I want to show you today
how this actually will look. It’s currently in
beta testing, like I said, from a limited group. But we’re hoping to make
it available to everyone in early next year, in 2018. So treat this as a sneak
peek of what you’ll be able to get in the future. So the new Search Console
looks very different. And it is mobile friendly, which
personally makes me very happy. And this is how the job
postings report will look there. So you can see that
in the same report, you’re able to see the
cards with errors, the cards with warnings, and
then also cards, which are actually
completely– completed with all the possible
fields, and we’ve indexed them successfully. And for each of these, it’s
possible to see examples. So here is the report. If you drill down to the
ones which are complete, then you can see specific URLs. And the way we’ve set this
up is that every time you click on one of
those URLs, you will be able to see directly the
new rich results testing tool, which we’ve also
built completely fresh. And so you can test this. And you can see that
everything is fine. And then, you can even
preview the search results, how it would look
actually in our page. So this is a completely
new flow that we have and we’re currently
testing and we’re hoping to release early next year. Now, of course, as
you saw, it’s not all of the different rich
cards that are complete. This would be the
best case scenario. But there’s not always the case. And what– we’ve built
a new error fixing flow, which saves states in
order to help site owners or anybody who is
managing the site and paying attention to what’s
going on in Search Console fix those issues. So if you look at the items with
errors and then you drill down, you will be able to
see, for example, for a specific type of error;
again, URLs from the site; and what really is the issue. And the same case as
with the complete items. You’re going to be able
to click and go directly to the testing tool. And in this case, it’s possible
to see that it’s actually an issue with a critical error. And if you actually
open this, you’ll be able to see the code
and what is missing. So then, you can fix
that, and you can also try to validate it. So this is a new flow
that we’ve been able– before and– well, actually,
today in Search Console, you can only see errors. And then after
you’ve seen them, you can fix it and then hope
that after you resubmit your site map we, will
re-crawl, reprocess, and then you will see
the line of their scope going down in terms
of absolute number. Whereas here, what
we are doing is if you think that
you’ve fixed the issue, you can actually click here
on the Validate Fix button. And what we’ll do is sample
a few pages from the error examples that we had before. And after we do
that, we’ll tell you if we think that you fixed–
really fixed the issue or there’s still
some work to do. If we find that there
is still an issue, we’ll tell you immediately. So then, you can go back
and debug those URLs in the rich result
testing tool and see what new problems are there. But this, we find, is– in the tests that
we’ve done so far– is a really good
and reliable way to optimize the fixing
workflow, because it allows you to get feedback immediately. If, on the other hand, after
performing this validation we see that the sample URLs
have actually been fixed, this will trigger a re-crawl
of all the pages automatically. It will also send an email
to the owners of the site, so they’re aware that
there’s been a change. And after we re-crawl
the pages in terms– and here, there might be some
delay in terms of host load and stuff like that. But after we re-crawl
all these pages, then we’ll be able to pick
the– you will see here that everything is fixed. And you will hopefully
see a downward trend in terms of number of errors. We’ve also enabled
this sharing button. So if you’re working with
a few different teams in different part of
the company or if you have a developer or
an agency that you’ve hired to help you with
this, you could just share this report with– the link to the report
with them, and so they can have a look as well. So we’re trying to
enable the collaboration between different
parts of a team that is taking care of
the technical parts and maybe the SEO
parts of the site. So this is all currently
in beta testing and should be available
early next year. But I am personally
really excited about this. And I’m hoping that it will
solve a number of issues that we’re seeing right now. And the entire team
of Search Console is also really looking forward
to releasing this and looking forward to feedback. And like I said before, it’s
all completely mobile friendly. So that’s probably
the thing that I’m most excited about that you
can walk on the sidewalk and bump into people while
looking at your job postings error report on your phone. So now moving on
to the questions that we’re actually getting. We went through all the lists
of the most recent questions to see what bothers
people the most. And we’re hoping to give
answers to all of these, so in the future we have a
ready preference for anybody who is wondering
about these things. So the top questions that
we’re seeing right now– the number one thing
that people ask is, how do we markup location? And currently, the JSON-LD
markup for location looks like this. We’ve said that it’s
good to try to markup as many fields of
these as possible to give people options of
filtering and finding the best job that fits them in
terms of their own location and what they prefer. But what’s important is to
complete at least those three specific fields. Because without them, the
markup will be invalid. And we are aware that there are
some cases in which it’s not possible to fill
this, for example, things like crew
on a cruise ship. So we’re working with the
schema.org team in order to see, what can we do to adjust
the schema to make sure that it actually fits these use cases? But for now, these are
the three required things that you need to have
in your markup in order not to get any errors and
for the markup to be valid. STACIE CHAN: Sorry
to interrupt, Mariya, just wanted to jump in and
say, the reason we also love schema.org is
because it is open source. And with the industry changing
and how employment is typically done, we want to hear
directly from you guys how you best
represent remote jobs. We appreciate that
more and more jobs are being flexible on multiple
locations, 80-20 split. How should we best represent
that type of job by a schema? So we’re looking forward
to your feedback. MARIYA MOEVA:
Yeah, so if anybody has any specific comment
on this on the Hangout, or if you want to
tell us later, feel free to reach out
to us on Twitter or in the forum, whatever
works better for you. And we really look
forward to this so that we can improve
it for everybody. Now, the next
question that we get, which is also
related to location, is, what locations
are actually eligible? So we are getting a
bunch of questions like, I am a company
that is based in London, but I’m hiring people
in New York City. Or the other way around– I am a US company, but I want
to hire someone in Sweden. All of these are possible. And the one thing
to keep in mind is that currently, we will
show this experience only to searchers in the
US on Google.com. So if that fits your purpose,
then go ahead and mark this up. And as we roll it out in new
countries to more people, we will make sure to let
everyone know on our blog and through other channels
so that when you find out that it works in your specific
target market as well, then you can actually implement it. STACIE CHAN: We’ve got questions
on the Google+ event asking, when is that [INAUDIBLE]
for international rollout? We’re very excited that– we believe we’ve launched
a really nice feature here in the US. But we realize that every
market is very different. And so our mission at
Google is to organize the world’s information. So where we do see
inappropriate market fit, we want to launch this feature
in other countries as well. So if you do have a presence
across multiple countries and you’re based in the
US, you should already start marking up
those jobs as well. And so we do launch
in another country, your jobs will already be
eligible to start displaying. MARIYA MOEVA: So
hopefully, that clears up a lot of the confusion around
what is available where. The next thing that
we see a lot is people asking about where it’s
possible to add the markup. So is it possible to add
it in job categories pages? Is it possible to add
it only in the site map? Is it possible to
add it only when they see that Googlebot
is requesting the page and remove it when an actual
user is requesting the page, because the user can’t
really see the markup? So the answer to all
these questions is no. And the markup should be
available in the source code of the page, regardless
of what kind of user agent is requesting this page. Otherwise, it
could be considered as cloaking, which is showing
different content to Googlebot then is showing to users. And this is something that
we take pretty seriously. So to repeat, don’t put
your markup in the site map. Don’t put a markup on
category pages, which show a number of listings. And just put it on
the specific job page that it’s relevant for. So hopefully, that
solves that issue that we’re seeing quite a bit. Another question that
we’re getting quite a bit is how to confirm if
the posting is indexed. And here, I want to make the
distinction between something that is being
indexed and something being served in search results. So there are two separate stages
of the whole search process, which is actually three steps. So first, we discover
and crawl things. Then, we index them. And then, finally, we
serve some of those things in search results. And this is specifically
for the middle part. So the best way to do
this right now is– until the new Search
Console version launches– is to check your site map. And then also, try a
site search, maybe, with a few keywords and
see if that page pops up. And then, of course, if you go
to the Search Analytics report and you search for
that specific page– because you can filter
there by pages– and then you see that
it’s actually serving, then, of course,
it will be indexed. So there are multiple
ways, as a site owner, to get very detailed information
whether a specific posting is indexed or not. We also get this question
a lot from people who have posted their jobs
on a third-party site. And for them, they don’t have
access to the Search Console account of that site. So they’re unable to see whether
their page is indexed or not. So for them, the best case
scenario is to do a site search and check that way. So let’s say you have some
jobs for gardening in Tel Aviv. You can do a site search for
the site where you posted them and then a few of those keywords
and see if they show up. And then, of course,
another option is to get in touch with
the actual provider and see if you can
get information about your specific postings. But that can be
quite tricky given the sheer number of people
who are posting jobs on the bigger sites. So this is a quick and
easy way to do this. Another question
that comes up quite frequently is that the logo
of the specific company isn’t showing up. So we wanted to
make sure that we have an answer for that one
that is recorded as well and we can share later with
different people who ask this. So I don’t know,
Stacie, if you want to explain a little bit
what the specific issue is. And what are the
workarounds here? STACIE CHAN: So
first, the reason we wanted to start showing
logos is really to strengthen employers’ brands. We know a lot of companies
take pride in their company and their mission and
their hiring practices. So we really wanted
to show the logo. We’ve seen two
challenges with this. One, the logo often
doesn’t show up. That’s because we pull these
logos from the Google Knowledge Graph, so that’s the graph
that really tries to organize all the world’s entities. And if the logo isn’t
in the Knowledge Graph, we don’t show it. How an employer
can resolve that is to actually prove that
they’re a representative of their company. And they can do
that in three ways. Mariya, I’m not sure if
the next slide shows that. I can also rattle them off. So you can verify you’re
the actual representative of your company by being the
owner of your YouTube channel; the owner of your website,
which you have to prove through Google Search Console; or you’re
the owner of your Google+ page. And so when you’re
the verified owner, you can then go in and
add or fix the logo. Because the second challenge
that we sometimes see is that we have the
wrong logo included. And so this is the
quickest way to fix this. So if you’re a
jobs provider, you can let your clients
know that that is how they fix their logo. One possible avenue
we’ve been exploring is actually allowing
providers to markup a given company’s logo
in the structured data job posting markup. That is something
we’re exploring. And if we have any
updates on that, we’ll be sure to
let everyone know. MARIYA MOEVA: Great. Thanks a lot. So hopefully, that settles this. It doesn’t quite
settle it, but it’s the most up-to-date information
that we can share right now. So I think this is actually– STACIE CHAN: Sorry, when we
have these types of questions, you guys should definitely
bubble these up. This is exactly how
we start to prioritize fixes for certain things, is
when we hear directly from you guys. So the more you
post on the forum– and you can– I think you
can +1 or upvote them. That shows that a
lot of people also feel the same way about this. So please keep that
feedback coming. MARIYA MOEVA: Great. So I think these are
all of the questions that we got from the previous– the people who submitted
prior to the Hangout. And I’m gonna stop
screen-sharing now and go to the Google+ page where I see
that people have been adding questions. STACIE CHAN: Lots
of good questions. So thank you [INAUDIBLE]
who’s tuning in live. MARIYA MOEVA: So
one thing that I wanted to elaborate a
little bit on as well is the situation
with manual actions. So structured markup, as
probably most of you know, has a bunch of
different guidelines. So they’re both
content guidelines in terms of what you can
mark up in order for it to be a truthful representation. And there’s also how
you mark up things. So there could be issues
with both of those. And when we notice
that there are some problems with
specific type of markup or the content that
is being marked up which are violating
the guidelines that are available on
developer site, we might take action in some cases. And what we do is we
just disable markup. So the site which has
this issue will not appear in that specific feature. So if this is the case, we
will always send the site owner a message with some examples. So they can start to
debug what the problem is. And from there,
after they fixed it, they could always submit
a reconsideration request. And the team that
handles these will then process it and either give
them some more feedback or resolve the issues so
that their markup can again be used in the future. And I think there has been a
lot of feedback about the fact that there are so many
different kinds of markup. And we don’t give enough
detailed information in terms of exactly which markup
and what type of violation is affecting a specific site. So I’m really happy
to let you know that we’re working on that. So I’m hoping that we’ll be
able to share with you more detailed messages with more
examples and specific steps that show exactly
what the issue is. And so it will make it easier
to fix these things as well. So that was another question
that came up many times, and I wanted to make
sure that we covered it. So with that, let’s go
to the Google+ page. So we got actually
a lot of questions since the Hangout started. OK, so let’s see
from the beginning. So Svetlana Wilson asked if job
reposting has an impact on SEO. And she recently noticed
that their competitor started reposting existing rows. And she’s wondering whether
this might give them some sort of advantage. So she’s wondering if we’re able
to recognize that the repost jobs are the same as before. Or will it count
as fresh content? So if the content
is exactly the same and it’s only that a
date that’s changed, there’s no point in
resubmitting the site map and just changing the date. We’re able to do a pretty
sophisticated reconciliation in terms of the content. So I don’t think that
really gives any advantage. And in any case, it’s a lot
of wasted effort on the site– of the site owner or the SEO. So if you have a job,
keep it in the site map until it’s actually filled. And then, there’s no– the
vacancy is no longer available. And only then make
sure to update the site map to let us know so that
we don’t show expired jobs. But there’s really no point
in resubmitting the same site map over and over again
with just changed dates. So then, there was
a question about, when will the markup be
released in other countries? So I think Stacie
addressed that. If you want to try it
out, go ahead and try it. And stay in tune. When we release it in
your specific market, you’ll be ready,
and your jobs can start appearing in the future. Let’s see. There’s a few people who
are mentioning that they’re unable to see anything. So if there’s not enough
spots in the Hangout, you can always watch
on YouTube and then post your questions here. So we’ll make sure
you address them. There’s another question about
availability in all countries. So I think we addressed that. Is there anything we might be
doing that would negatively affect their job postings? So this is quite a
general question, but if your postings
are up-to-date and if they’re
indexable and if you’re refreshing your site map
and have valid markup, I think those are the main
things that could help you appear in this feature. So I would say, make sure
to validate your markup and have a frequently
updated site map. Other than that, I don’t know. Unless you’re
purposefully marking up something that is not
really a job or you are– people end up on a page which
actually requests payment for them to receive
the full information or something like this, I don’t
think there’s any other issues that you could encounter. OK, then Marius asks, the
markup documentation says, do not include search
results pages, list pages, or other dynamic
pages in the site map. However, we would still
want them to be included in the regular search results. So this is kind of a
brother question, which is besides drops,
it really depends on the value of the category
pages and the search result pages whether it’s worth
showing up in Search. If you do want to
send them, I would say when you’re submitting
the job posting site map, don’t include them there. But I think this is
really interesting to see specific
examples of those pages to see if they’re actually
worth including in the search results. So maybe if you’re
interested in continuing this discussion in the forum
and showing some example URLs we could keep talking there. If you’re watching
on YouTube, please get in touch on the
forum or on Twitter. And then, we can
continue from there. But yeah, if you want to include
them in the jobs site map specifically, that’s
not really a great idea. Brendan asks, will integrating
with Google’s indexing API positively impact the
frequency with which Google crawls our career sites? So crawling frequency is
affected by many signals. I already mentioned host
load earlier in the Hangout. So that’s one of
the biggest things that is really key for us to
decide how much we’ll crawl. Other things here
is how important we think specific pages
are and how relevant. So Google’s indexing
API has a bunch of benefits in terms of being
able to send specific pages rather than resending
the entire site map. But increasing
frequency, I wouldn’t say it would be a direct
consequence of that. Maybe what you would
get as a benefit is more targeted crawling, which is– which is good in itself. So you’re not wasting
any of your re-crawls on pages which haven’t
really been updated. STACIE CHAN: And for those who
are wondering what the Google indexing API is, this
is a very early product that we’re experimenting with. And it’s designed for
sites that have probably hundreds of thousands of jobs
and the rate at which they expire is very immediate. And you want to be able to
alert Google almost instantly. That’s what the API
is designed for. And so if you feel that
updating your site map daily is not accurate
enough, that you’re not going to be sending Google
those updates quickly enough, you can register your
interest in the indexing API by going to our Developer site. It’s the same
Developer site that you use to look up the markup. So it’s
developers.google.com/search. Just look for jobs,
and then you can enter all of your
information into the form. And if we think you’re
a good candidate to test the indexing
API, we’ll reach out with the ultimate goal– everything do at Google, we want
to make sure it is available publicly to everyone– but
since it’s such a new feature, we do need to experiment
with it initially. MARIYA MOEVA: Yeah,
I would say it’s a new use case for the API. So Richard Gingras actually
talked a little bit about it in his I/O talk in 2016. So if you want to know a little
bit more about the thinking behind this indexing API
and the first use case that we applied it
to, I would suggest checking out Richard’s talk. So it’s really interesting to
see exactly how it’s set up. But for the jobs use case,
it’s, as Stacie mentioned, currently available to sites
which have really, really big volumes. MISCHA: Can I chime
in real quick? MARIYA MOEVA: Mm-hmm. MISCHA: Quick comment–
regardless of the API or not– for example at ZipRecruiter,
we have millions of jobs. And one of the things
that we hate seeing is a job seeker clicks
on a job and then they get that this job
is closed error message. It looks bad for our brand. And obviously, it’s a bad
experience for the job seeker. So using the API or using
a freshly updated site map I think is a really
good thing to do. And this is an
instance where we’ve seen Google update the
postings very quickly. So when a job is
taking down, we’re able to take it
down from Google. And therefore, it’s a better
experience for everybody. Having it stay in the
index for a day, even, I think ultimately, to us,
feels detrimental to our brand. So we do try to
stay on top of it. SPEAKER 1: Yeah. So on the SmartRecruiter
side, we post jobs for thousands of companies. And we’ve got the
exact same viewpoint. And that’s why we also chose
to go with the indexing API, so that we could protect
that protect the candidate experience. STACIE CHAN: Yeah, thanks for
that additional insight, guys. MARIYA MOEVA: I’m
scrolling through the rest of the questions. It seems like we have
maybe four or five more. So another question from
Marius about site maps where he’s asking
if it makes sense to add fields which are
more granular than the ones in the Google documentation. So in the current
set of docs we’ve listed, the things
that we actually use in order to
create this feature and to display it to users. And then they can filter
according to their preferences. If you want to add more things
which are not listed there, by all means, feel
free to do so. But it’s not going to
be something that we are, at least currently, using. Maybe in the future when we
increase the functionality, it might be one of the
things that we’re using, but it’s not guaranteed. So it’s up to you to decide
if you want to do that or not. It’s just not going to be
reflected in the feature right now. OK, then there is a question
about migrating to HTPS, which is not exactly our topic today. So I think we’ll leave
that for another time. And a really interesting
question about videos. However, it doesn’t seem
like this is for jobs. So just to address
this really quickly– if you have video
transcripts, that’s great, so that people who maybe
are having issues with hearing can actually understand
what’s going on. And it also helps us in
terms of understanding the content of the video. Make sure you have
a video site map. But not really relevant
to job postings, unless you have some kind of
company intro video on the page as well, in which case
this would apply to you. Will Google be considering
where the job posting originated in the future? Our clients would
prefer the jobs that originate from
their career page to be placed first instead
of the candidate being routed through a third-party
job aggregator with rich cards. So in this case, I would
say that if you want– as an employer, if
you want your page to be directly the
destination after the flow that I was showing
earlier in the slides, it would make sense to put
the markup in your own pages and then submit the site
map, validate everything, as we mentioned before. However, we do decide,
based on relevance, how to order the different
versions of the same job from various providers. So it’s not guaranteed that
for every job that you’ve decided to mark up it
will actually always be showing in the first
or in the top place. Depending on the
search and the users and many different factors,
we might cluster specific jobs so that we don’t
show duplicates. So for this, do go
ahead and try to put the markup on your own pages. But there is no guarantee
that you’ll actually be the number one
that is showing or the only one that
is showing there. MARIYA MOEVA: And Mariya,
something that we launched in our V1.1 launch, I
think, around last month– we call it Apply Options. But what this really
means is you can actually see multiple providers
where the user can actually view the job on. So we think this is a
new user experience. We’re not quite sure
if it’s superior or how it’s playing out. We really wanted to
give users options for where they view the job. Because they may have a
profile created on Glassdoor or another provider. And so we want to
give user that option to actually click the job
that they want to be on. And so that actually
goes to another question that was on the comment
section, Mariya. It asked how this was
going to be measured. So in Search Console, you can
actually start taking a look at clicks, impressions,
click-through rate, and position for your
job listing page– that’s more like the snippet
of the job– as well as the job details page. That’s the whole page. So say you were the
second provider listed on the job details page. That also still counts
as an impression. So we are calculating
the metrics around those Apply Options. And as always, we’re looking
to improve our feature all the time. So sometimes, we’re
testing things. You may see the Apply Options. Sometimes you may not. We’re always trying to create
the best, most relevant experience for our users. MARIYA MOEVA: Cool, thanks. I realized that I actually
scrolled through this without seeing it. So now we have that
one covered as well. There is a last question here,
which is about product markups. So I think we can
skip that as well. So we’re also almost
running out of time. So unless there are any
questions from everybody who’s actually in the Hangout,
we could call it a day. Anybody have any questions? STACIE CHAN: Aaron,
I see, popped in. He had a question. AARON: Oh. Yeah. So I wanted to ask what– in the case of the new
Apply Options interface, what counts as an impression
in Search Console? If you’re one of the
alternate options for Apply, is that being counted
as an impression? STACIE CHAN: Yeah, so
anything on the screen counts as an impression. And then, I think,
we’ll show potentially up to six providers. So if you need to scroll left to
see that fifth and six provider once that enters the screen,
that’s also an impression. And Mariya, I see– SPEAKER1: One more
quick question here. How much detail do you
recommend providing in the job description value? So for comparisons, some
of the older job publishers have some structured data
around company description and then job description
and qualifications, whereas the schema.org is
just a single job description. What do you recommend
including there? MARIYA MOEVA: So I
guess this refers back to the other question that we
currently– that I just looked at maybe a few minutes back. Everything that we
are currently using is based on a
schema.org vocabulary as is in in our docs. So for the time
being, we wouldn’t use this in terms of filtering
or sorting in the future. But if you think that
there are some things that could be used to
enrich the experience, then that would be very
interesting, definitely, to hear. It’s just not going to
be reflected currently in terms of additional
detail if you did that– if you did add that. If it’s already there,
though, like you mentioned these publishers have
it previously, then I don’t think it
does any harm either. STACIE CHAN: Right. And I do want to call
out that we actually did remove some of those
fields from our documentation. We asked for things like
skills and experience. And we think that’s important. But we weren’t using
those skills specifically as part of our display or RUI. So we didn’t want providers
spinning their wheels to go through and actually
populate those fields that we weren’t going to use. With that said, I
think that information is valuable to include
in the description. Now, you don’t
necessarily want a novel, because you’ll see if you
actually open up any job details page, you have
to click Read More to expand beyond a certain
number of lines of text. So as with any good
piece of content, you want to put the most
relevant information at the top. And if you feel like you
have some additional info, go ahead and add that there. And if we do decide to bring
back the skills or experience fields, they’ll
actually have a purpose. So that’s just a plug to always
look out for our documentation. Whenever updates happen,
that will go live on the
developers.google.com/search site. SPEAKER 1: Great, thanks. MARIYA MOEVA: OK, so I see
that meanwhile, there’s a bunch of more
questions that shows up. So let’s see what can we answer
in the next three minutes. All right, so Yuan Feng
asks, a client of ours has more than 1,000 invalid
job posting rich cards. Is there an efficient way to
fix these markups in bulk? Most of them are missing
location information. So I would say that
this really depends on what type of content
management system this site owner is using. If it’s possible to edit and
inject a JSON-LD in bulk, then you should be
able to do that. But if you are
managing the site, or if you are in direct contact
with the developer team, I would suggest talking to them. And then, just
resubmit the site map, so we can see the new markup. But I can’t really
give a specific answer without knowing what type
of schemas they are using. OK, so then, how are we
de-duping across providers? So Zoe’s asking if there should
be a duplicate content concern since she has jobs which are
posted on different websites. So I would say
that this shouldn’t be a concern if
you are an employer and you have posted
across different sites. Just leave to us and
to our ranking team to decide when to show
the most relevant job. It’s not something
that we generally go into details about in terms
of how we actually rank things, as many of you who watching us
regularly are probably aware. But if you have correct
markup and they’re indexed on the
different sites, I would just say to
not worry about this in terms of the employer,
and you have your jobs on multiple sites. MISCHA: I have a quick
follow-up question about that. So is there a plan to
somehow prioritize– if the same job posting comes
from three different providers, but one of them, when
you go to that job page, you’re basically just
being passed along to another job page where you
can actually apply to the job. Whereas another provider,
when you go to their job page, you can actually apply
for the job there. Because with ZipRecruiter, if
any of you have heard our ads, post your job to
200-plus job sites, so we’re all about sending
our jobs everywhere. And then we see them
showing up on Google, but they just send you
right back to ZipRecruiter. MARIYA MOEVA: Hm. I’m not aware of any plans
that are taking into account the user experience after the
user leaves the search results. But I’m hoping that
users themselves will notice this and
react accordingly. If we do see a lot of
feedback that people are not happy with a specific thing, we
obviously try to reflect that. But currently, I’m not aware
of any plans like this. I don’t know, Stacie, if you
know anything on this topic. STACIE CHAN: Yeah, that’s
a good point, Mariya. We want to hear from our users. So until we feel that’s
a vocal enough opinion, we definitely will
start exploring that. MARIYA MOEVA: OK, then
Radu asks if there’s any markup available
for remote jobs. So this is, again,
something that is similar to the cruise ships
jobs that I mentioned before. I don’t know that we have
enough flexibility in terms of schema.org
vocabulary in order to get this done right now. But it’s definitely
on our radar. And we’re in
discussions with them. So hopefully, we can reach
some sort of arrangement there. And then, it will be possible
to markup these type of jobs. And another question
from him, would you use the market for a company
job area with a small amount of jobs available? Will that make a
difference for queries that are brand
plus job name that are showing up high in search? So a small number of job
posts, will the markup work? I’m not sure I understand
this completely. So rather, if you’re watching
and you want to clarify– if you just have a few
postings on your site and you’re wondering
whether to mark them up, if you have the time and the
ability to do this on your CMS, then definitely go for it. But yeah, there’s not really
an issue here that I see. I think I’m not understanding
the full context of the question. But yeah, either mark it
up when your own site, or submit it to a
third-party site– whichever way is preferable. Then Marius asks,
which factors determine what jobs you show up on top of
the list for a specific query? So I would invite Marius to
apply for a job at Google. And then we can
discuss all the details of how the ranking works. But this is not something that
we disclose in detail normally. OK, let’s see. So Danielle is asking about
providing options maybe related to a previous question. Stacie, do you
see which question this might be related to? It doesn’t quite
make sense by itself. STACIE CHAN: I
think it might still be a ranking question
about Apply Options. MARIYA MOEVA: [INAUDIBLE] STACIE CHAN: Let’s dig into
it, and we can always respond. MARIYA MOEVA: OK, yeah, we
can just reply in the comments later. OK, so then finally, Matt is
asking about evergreen jobs. So for those, I guess it’s
just possible to mark them up as usual and then just
have the Apply button, but they don’t expire. So that would be
my recommendation and just accept an endless
number of candidates or however many you have available. Meanwhile, we’ve got
two more questions. So we have user data– Florian’s asking, we have user
data for estimated hourly rates and salary range. What exactly do I need to
get the listing feature? So we recently
added documentation about the specific type of
markup that you can use. It’s the occupation markup. So I can post a link later
in the comments here. And then, you can go and
have a look at exactly what type of markup you can use in
order for the content to be eligible for that feature. OK, then Brendan–
and this truly should be our last question,
because we ran out of time. Brendan is asking, we own about
25,000 career site properties. Is there an easy
or suggested method to verify ownership
of all of these pages so that we can track
them in Search Console? OK, so Brendan, one way to– one thing to keep in
mind is that there is a limit on the
number of properties that you can have
verified in Search Console as a single account. And that’s 1,000. So I’m not sure when you
say career site properties if you mean individual
websites, because that’s a pretty sizable and very
interesting number, 25,000. But keeping in mind the 1,000
site per account limitation, the easiest way– or I
guess the most automated way to do this would be to make
use of the Search Console API and the verification
API together in order to verify
ownership of these sites. You would still not be able to
see them in the same account, but you could at least
verify them faster. OK so I think with that, we can
probably start to wrap this up. We’ll go through
the questions again. And we’ll reply in the
thread here to people that maybe we didn’t
understand enough context or we asked for more examples. So if you do have
follow-up questions, definitely get in touch
either here in the thread or on the forum or on Twitter. And we’ll keep
listening and keep trying to improve the future. So thanks for
everybody who watched. Thanks for everybody
who participated live. And especially thanks to
Sofia and Stacie for joining and for helping run the Hangout. STACIE CHAN: And thanks
to all the providers who were able to join
and add some insights. We know that we create the best
experience when you guys have high-quality jobs to offer
to job seekers looking for employment on Google. So thank you guys as well. MARIYA MOEVA: All right, so
happy job hunting and job finding.

3 thoughts on “Google Webmaster Central hangout: Jobs Postings markup

  1. Here is Richard's talk that Mariya was taliking about (it was hard to find) https://youtu.be/xeGzQhAU2XI?t=16m37s

  2. Please I've created a career page, added google jobs structured data and validated them already. I have also created an API but my challenge here is, how can I actually "USE THE API TO NOTIFY GOOGLE ABOUT MY CAREERS PAGE ON MY WEBSITE?"

    Please this is urgent.

  3. I have implemented the code on job details page which have script reading the job for posting onto google search.

    My job gets display within Google Search Jobs Explorer, but the logo is not displayed. Instead, the First letter of the Job Title is being displayed onto google. I reviewed various documents as well as googled a lot to understand why the image isn't been displayed, although I didn't get any solution yet. I had around 1.5 Yrs old articles (https://developers.google.com/search/docs/data-types/job-posting) stating that its a common issue faced with Google jobs, but I want the recruiter company logo at any cost if URL exists on Azure Image Blob.

    I tried replacing logo URL of Azure Image Blob with the one at local domain based URL path for getting job logo into google search explore but that too didn't work.

    Here is Added Screen Shot : http://prntscr.com/no958l

Leave a Reply

Your email address will not be published. Required fields are marked *