 OK, we are live. Excellent. So hello, everybody, and welcome to the 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 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 Sophie and Stacey, 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's a lot of different options to filter by location, by company, and different other factors. And finally, once they've picked 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 from 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. Sure, happy to. Hi, I'm Misha, I'm a product manager at ZipRecruiter. Hi, Misha. Hello. Do you have a specific question or do you want me to just kind of talk about her experience in general? Yeah, I'm just curious since you implemented this, what kind of changes you're seeing and how has it been for you overall? Yeah, I mean, the biggest thing we noticed when we implemented the structured data and saw our jobs showing up on Google, as you can see in the screenshot, 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, a meta description, three or four lines of text and click through, hoping that they're gonna find what they're looking for, which is 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 that 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 blue link. So what we saw as a huge increase in conversion rate from the traffic that we're getting from Google to our job pages, because we think that job seekers are now a lot more educated by the time they're coming to our site and they're basically ready to apply. It's super interesting. Thanks a lot for sharing that. So in terms of implementation, there's 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 index meta tags or any other issues, add 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 requirements, but also nice to have, 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 in any way, it's not gonna 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 form 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 servers 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 wanna offer and you're 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 health center, including Zip Recruiter, LinkedIn, Glassdoor and so forth. And since they already have the 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, okay, 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 jobs section and it's possible to see how many cards are completely invalid so they have critical errors and then how many are okay. So they have the basic required fields but are actually not fully enhanced. So you could add a few more things to make it 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 wanna 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 result 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 gonna 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 enabled 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 errors 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 really fixed the issue or there's still some work to do. If we find that there's 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 test 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 of 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, you will see here that everything is fixed and you hopefully see a downward trend in terms of the 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 the different parts of a team that is taking care of the technical parts and maybe the SEO parts of a 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 we'll 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 reference 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 to mark up location. And currently the JSON-LD markup for location looks like this. We've said that it's good to try to mark up 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's 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. Sorry to interrupt, Maria. I 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 on how employment is typically done, we wanna 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. Yeah, so if anybody has any specific comment on this on the hangout or if you wanna 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 wanna 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. So we got questions on the Google Plus event asking when is that time 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 an appropriate market fit we wanna 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'd already start marking up those jobs as well. And so when we do launch in another country your jobs will already be eligible to start displaying. 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 than it's 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 that is 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 the 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 the 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 or 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, Stacey, if you wanna explain a little bit what this specific issue is and what are the workarounds here? 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 where 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 Plus page. And so when you're the verified owner, you can then go in and add or fix the logo. Here's 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 mark up 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. Great, thanks a lot. So hopefully that settles this. Well, 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- Sorry, when we have these types of questions, like 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 like plus one or up vote them, that's a lot of people also feel the same way about this. So please keep that feedback coming. Right, so I think these are all the questions that we got from the previous, the people who submitted it prior to the hangout. And I'm gonna stop screen sharing now and go to the Google Plus page where I see that people have been adding questions. Lots of good questions. So thank you for having me who's tuning in live. 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, is has a bunch of different guidelines. So they're both content guidelines in terms of what you can markup in order for it to be a truthful representation. And there's also how you markup things. So there could be issues with both of those. And when we notice that there is some problems with specific type of markup or the content that is being marked up which are violating the guidelines that are available on the 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 issue 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 is 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 and 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. Okay, so with that, let's go to the Google Plus page. So we got actually a lot of questions since the Hangouts started. Okay, 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 roles. 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 reposted 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 the dates that's changed, there's no point in resubmitting the sitemap and just changing the date. We're able to do a pretty sophisticated reconciliation in terms of the contents. 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 sitemap until it's actually filled and then the vacancy is no longer available and only then make sure to update the sitemap to let us know so that we don't show expired jobs. But there's really no point in resubmitting the same sitemap over and over again with just change dates. Okay. So then there was a question about when will the markup be released in other countries? So I think Stacy 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 to address them. Okay. So 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 our 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 sitemap 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 sitemap. Other than that, I don't know, unless you're purposefully marking up something that is not really a job or 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. Okay. Then Marius asks, the markup documentation says do not include search results pages, list pages, or other dynamic pages in the sitemap. However, we would still want them to be included in the regular search results. So this is kind of a broader question which is besides jobs. 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 sitemap, 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 you're else, 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 sitemap specifically, that's not really a great idea. Okay. 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 a 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 sitemap. But increasing frequency is, I wouldn't say would be like a direct consequence of that. Maybe what you would get as a benefit is a more targeted crawling, which is good in itself. So you're not wasting any of your re-crawls on pages which haven't really been updated. 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 sitemap 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 slash 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, like everything we 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. Yeah, I would say it's a new use case for the API. So Richard Gingris actually talked a little bit about it in his IO 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 Stacy mentioned, currently available to sites which have really, really big volumes. I'll chime in real quick. Quick comment, regardless of the API or not, like for example, at ZipRecruiter, we have millions of jobs. And one of the things that we hate seeing as a job seeker clicks on job and then they get like a, 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 side 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 taken 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 like a day even, I think ultimately to us feels detrimental to our brand. So we do try to stay on top of it. Yeah, and so on the smart recruiter 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 the candidate experience. Yeah, thanks for that additional insight guys. 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 side 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 gonna 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 wanna do that or not. It's just not gonna be reflected in the future right now. Okay, then there is a question about migrating to HTTPS 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 set 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. Okay, well, 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 decide to markup, it will actually always be showing in the first or in the top place, depending on the search and the user 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 in 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. And Maria, 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 do the job on. So we think this is a new user experience. We're not quite sure if it's superior or has 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 wanna give user that option to actually click the job that they wanna view on. And so that actually goes to another question that was on the comment section where it asked how this was gonna be measured. So in Search Console, you can actually start taking a look at click some impressions, click the 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 full 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 play options, sometimes you may not. We're always trying to create the best, most relevant experience for our users. Cool, thanks. I realized that I actually scrolled through this without seeing it. So now we have that one covered as well. There's 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? Erin, I see you've popped in, you had a question. 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? 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 sixth provider once that enters the screen, that's also an impression. memory, I see. One more quick question here. Mm-hmm. How much detail do you recommend providing in the job description value? So for comparison, 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? So I guess this refers back to the other question 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 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 gonna be reflected currently in terms of additional detail 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. Right, and I do wanna 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 fields specifically as part of our display or our UI. So we didn't want providers spinning their wheels to go through and actually populate those fields that we weren't gonna 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 wanna 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 slash search site. Great, thanks. Okay, so I see that meanwhile, there is 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 Fang asks, a client of ours has more than 1,000 in valid 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 JSON-LD in bulk, then you should be able to do that. But if you're 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 sitemap so we can see the new markup. But I can't really give a specific answer without knowing what type of CMS they're using. Okay, so then how are we de-duping across providers? So Zoe is 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 watch Hangouts 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 employer and you have your jobs on multiple sites. 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 to the job there because for Zip Recruiter, if any of you heard our ads, like poster job to a hundred plus job site. So we're all about sending our jobs everywhere and then we see them showing me up on Google but they just send you right back to Zip Recruiter. I am 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, Stacey, if you know anything on this topic. Yeah, that's a good point Maria. We want to get more users so until we feel that's a vocal enough opinion, we definitely will start exploring that. Okay, 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 are in discussions with them. So hopefully we can reach some sort of arrangement there and then it will be possible to markup this type of jobs. And another question from him, would you use the markup 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 Radu 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 and 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 maybe, I think I'm not understanding the full context of the question. But yeah, either mark it up on 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 the 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. Okay, let's see, so Danielle is asking about providing options, maybe related to a previous question. CCG, do you see which question this might be related to? It doesn't quite make sense by itself. It might still be a ranking question about the options. Yeah, let's dig into it and then we can always respond. Okay, yeah, we can just reply in the comments later. Okay, 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 to 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 got two more questions. So we have user data, Florian is 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 the link later in the comments here and then you can go and have a look exactly what type of markup you can use in order for the content to be eligible for that feature. Okay, then Brendan, and this truly should be our last questions 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? Okay, so Brendan, one thing to keep in mind is that there's 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. Okay, 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 Sophie and Stacy for joining and for helping run the hangout. And thanks to all the providers we're 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. All right, so happy job hunting and job finding.