And for the most part, people can ping me and ask


English Google SEO office-hours from December 10, 2021

to kind of be followed so they can send me a DM,


if that makes it easier.


Right, thanks.


Cool.


All right, let me take a break here


with regards to the recording.


I can be around a little bit longer,


but not as long as usual this time,


because we have more meetings.


But thank you for joining.


Thank you for all of the questions so far.


And I hope we can get through some of the remaining


questions as well.


And so many people still have their hands raised.


If you're watching this recording on YouTube,


feel free to submit questions for the next sessions, which


I'll be setting up as well.


I don't know how the timing of the next sessions


will be with regards to holidays and things like that,


but we'll figure something out.


Cool.


And with that, let me pause the recording here.


Merchant listing experiences eligibility (6 tips)

Google Search supports multiple shopping experiences in search results, broadly referred to as merchant listing experiences.


These experiences include product snippets, which add details to search results such as their star ratings, price and availability,


popular products, which shows a set of similar products that may be of interest to the shopper,


shopping knowledge panels, which display deeper information about a product and lists multiple sellers,


and image search, which can annotate images of products available for sale.


For your product web pages to be eligible for these experiences, Google needs rich product data.


The first decision to make is whether to provide your product data via structured data on web pages, via a Google Merchant Center feed, or both.


Google recommends doing both if you can.


If starting out, you might decide to start with structured data on web pages, then add a Google Merchant Center auto-feed,


which creates a feed from your web page content, and then grow into providing a direct high quality product data feed.


You can check for existing structured data on your product pages using View Source in your web browser.


Look for structured data with type Product.


You'll need to talk to your technical team to determine if you have a Google Merchant Center feed, as it cannot be detected from web page content.


If you are using a platform, refer to your platform documentation to see if you have any control over structured data embedded on web pages.


Also check if there is any built-in support for Google Merchant Center feeds.


Beyond that, check your platform extension marketplace to see if there are any relevant third-party extensions.


It is likely that built-in support or installing an extension is your most practical path forwards.


If you are developing your own site, check out our online technical documentation on both adding product structured data to web pages and creating Google Merchant Center feeds.


If you decide to add structured data, how to make sure it's correct?


Google Search Console includes a Merchant Listing report that shows issues found in your product structured data relevant to merchant listing experiences.


Fixing your structured data is dependent upon how it is provided.


After making a correction, you can use the URL inspection tool in Search Console to check if all issues have been addressed.


Product pricing can be complex.


The simplest form of price is a single amount specified along with its currency.


But there are many more advanced forms of pricing, such as quantity discounts or special offers for VIP customers.


While Google supports an increasing range of options, your site may use a form of pricing not supported by Google Search.


So what do you do?


The first step is to review the pricing options used on your website.


Then read through the Google documentation on pricing models to see what it supports.


I recommend periodically reviewing the Google pricing documentation as new pricing options may be added over time.


Once you know what pricing your site uses and what Google supports, you may need to simplify the pricing data you provide to Google.


For example, provide Google the price of a quantity of one, even if you offer discounts for purchases with higher quantities.


This is to avoid shoppers becoming upset if one price is shown in Google search results but a higher price is shown after arriving on your site.


It erodes trust.


Shipping information is also popular in search results, such as shipping costs.


Free shipping is particularly attractive to shoppers.


I already mentioned pricing can be complicated. Well, shipping can be even more so.


Shipping costs can be influenced by many factors, such as carrier used, total order weight and dimensions, shipping distance, and more.


To see if your listings have been correctly annotated with shipping costs, use a site query so you can see your products in search results.


You can check for errors in shipping structured data via the merchant listing report in Search Console.


Otherwise, use the Google Merchant Center Console if you provide shipping details that way.


Like pricing, you may need to simplify the shipping information you provide to match what Google supports.


Check out our online documentation for current capabilities and keep an eye out for updates as more capabilities may be added over time.


If in doubt, like pricing, it may be safer to overestimate shipping costs to avoid surprising customers at checkout with higher than expected charges.


Eligibility to many merchant listing experiences requires you to provide product identifiers such as a GTIN number, an NPN number, or a brand and product name.


The more you can provide, the better.


A SKU, or stock keeping unit, is not an acceptable product identifier as it is not consistent across merchants.


For example, the shopping knowledge panel displays multiple sellers of a product.


Dismatching is more reliable if a strong product identifier is present on your product pages.


To see if GTIN or similar product identifiers are present in your web pages, inspect the structured data markup.


Also check the Merchant Center report in Google Search Console for warnings or error messages related to product identifiers.


Your Google Merchant Center feed should also be checked if used.


To fix any issues, add a supported form of product identifier.


How to add an identifier depends on your specific platform or implementation.


There are many options for merchant experiences on Google.


Check out the Google Merchant Center online help to understand the full richness of information you can provide.


Also check out the Google Search Central documentation site for information on product structure data supported by Google.


While structured data currently supports fewer features than a Google Merchant Center feed,


the gap is closing as new capabilities are added over time.


To keep up with possible future directions, you may also like to check out the Schema.org site


for the broader set of structured data for e-commerce sites.


Schema.org markup is used by search engines beyond Google.


That's all for this episode.


To be notified of new content, please subscribe.


English Google Webmaster Central office-hours from May 12, 2020

All right, welcome, everyone, to today's Webmaster Central


Office Hour Hangouts.


My name is John Mueller.


I am a Webmaster Trends Analyst here at Google in Switzerland,


or, well, still in Switzerland, but not in the office,


at least.


And part of what we do are these Office Hour Hangouts, where


people can join in and ask questions around their website


and web search.


And we can try to find answers if that's possible.


As always, a bunch of stuff was submitted already on YouTube.


But if any of you want to get started


with the first question, you're welcome to jump on in now.


Hi, John.


Hi.


We have an issue with the meta description that is being


displayed for our home page.


So even though we have a meta description that


is being implemented on that particular page,


somehow in Google, when our website appears,


the meta description is completely different.


And in some cases, if we search for our company name


plus the word UK, the meta description


makes no sense whatsoever.


It's just a bunch of words put together


from various parts of the page.


I know sometimes Google goes hunting for various things


on the page if it cannot find relevant content


for that particular region.


So I guess my question is, because we


have a lot of traffic that is coming up from branded searches


so it is important for us to have the correct meta


descriptions showing up, what do we


do to rectify the situation?


It's hard to say without looking at the search results.


So that's kind of the one part.


Usually what happens is we need to have the description meta


tag on the page.


So that's kind of the first step.


It sounds like you already have that set up.


The other thing there is that we need to be able to, I guess,


trust the meta description on the page


so that it looks kind of reasonable.


In particular, sometimes when we see a bunch of keywords that


are just kind of collected in the meta description,


then that's something that our systems might look at and say,


well, this doesn't look that useful for users.


So they'll try to rewrite something else.


And most of the time when it tries to rewrite something,


it's based on the content on the page itself.


And the other thing, like you noticed,


is the description can vary depending


on the query that is used.


So the first thing that I would do


is just take the normal branded query that you use


and double check that the description that you provide


in the meta description is actually pretty useful


and not too kind of spammy or overdone.


And then go from there essentially to figure out,


is this something where Google always gets it wrong?


Or is this something where sometimes Google's algorithms


pick up something else on the page and get it wrong?


If you feel that it's something that Google is always picking


up incorrectly, then I'd love to have some examples like that.


So things like the queries, maybe a screenshot


of what you're seeing, if you could send me that or maybe


post it here in the chat, that would be really useful.


SPEAKER 2


Other questions from anyone before we get started?


SPEAKER 3


Hi, John.


I actually have a question around getting your website


verified.


We're trying to get our website verified


through our analytics tag.


We have the tag on the page.


We actually have used the Google Chrome extension


that detects if you have a tag already on the page,


and we're finding it in that.


But when we actually go to the verification site


and enter the URL for it, it's saying


that it can't find the verification tag on the page,


even though the user has all the edit access


rights to that particular container that it's stored in.


Do you have any tips for troubleshooting that?


It's hard to say.


So sometimes this is something where


the folks in the Webmaster Help Forum


can help because they can take a look


to see for a look at the common issues.


One issue that I've seen a few times that has popped up


is if the verification or if the Google Analytics code is not


exactly the same as we would provide that within Google


Analytics, then that might still work for Analytics


because it's still proper JavaScript.


But for Search Console, it would be something


that we might not recognize immediately.


So that's probably what I would watch out for there.


Because if you're saying that it's showing it


with the Chrome extension, if it's working for Analytics,


then it sounds like the JavaScript part


is working well.


It's working in a way that works well for Analytics.


But Search Console, when it tries to check that page,


it just can't recognize that this is really


that block of text that's used for verification.


Sure.


Great.


Thank you.


Hey, John.


Hi.


Hi, John.


I am having two questions on hlflang sitemap.


The first question is, do we need


to submit the same sitemap in all the language path?


Let's take the example.com file, flash, f4, and the product


name.


And do we need to submit this, the same hlflang sitemap


in all the parts of the language?


And the second question is, now we


are using the Spanish, sorry, the Brazilian Portuguese


in our web pages.


And what will be the hlflang tag?


Either it's pd-only or pd-br.


We are serving the language across the globe,


not only the BR, not only Brazil.


OK.


So for the first one, in general, with regards to hlflang,


we need to see both parts.


So we need to see kind of if you have two pages that


are connected with hlflang, we need


to see the hlflang markup on that first page.


And we need to see the same markup on the second page.


So if you have, say, an English page and a Spanish page,


we need to be able to see the markup for both of them


independently.


So if that markup is within separate hlflang sitemap files


that you're using, then we would need


to see all of those versions.


Depending on the way you set up hlflang within the sitemap


file, it's possible that you also just have one sitemap


file that has all versions.


And in that case, that's also fine.


But if you split up the language versions


into different language sitemaps,


then we would need to see all of them.


So that's kind of the first one.


The other one with regards to Portuguese, with hlflang,


you can specify either a language alone,


or you can specify a language plus a country


if you want to target a specific language within a country.


So if you had different Portuguese versions,


like Portuguese for Portugal and Portuguese for Brazil,


then marking that up appropriately


with the country and the language version makes sense.


If you just have one Portuguese version,


and it's one of these two, then I would just


use that language code and not the country code as well.


OK, thank you, John.


But even if they're all in French,


every page is for a country.


So now we updated the hlflang, and we


asked Google to re-index the page.


The crawl happened, but the pages are still de-indexed.


I can get them indexed.


Is it the same content just for different countries?


Or what's the same content, but the title is different


and the header one is different?


But these are trainings.


So it's just the content of the same training,


but we have different headers and titles.


OK.


So practically what probably is happening here


is we are recognizing that these pages are essentially the same,


and we're folding them together.


So we're seeing them as duplicates of one page,


and we'll try to make it easier and just index that one page.


And with the hlflang markup, essentially what happens


is we don't change the indexing side,


so we would still index these as one page.


But if we recognize that the hlflang markup is correct,


then when a user searches in those individual countries,


we would try to show the appropriate URL.


So if you have a URL, say, I don't know,


for let's use English UK and a URL for English US,


and it's the same content for whatever reasons,


and we fold them together as a duplicate version,


then what would happen is we would index just one of those.


And if someone is searching in the US,


we would show the US URL with the snippet and the title


from the one version that we have indexed.


And if someone is searching in the UK,


we would show the UK URL.


So the indexing side wouldn't change,


which makes it really complicated to debug.


But in the search results, we would use hlflang


to swap out those URLs.


And from our point of view, that's


something that makes sense as an optimization for indexing,


because we just have to index one version,


and we have to keep crawling one version because it's all


in that one version.


But for the webmaster, it can be really tricky


to monitor what is happening there.


In particular, the index coverage report


in Search Console will just show one of those versions


as being indexed, even though we show


both of those different URLs.


And the search performance report in Search Console


will also just report on one of those URLs, the canonical one


that we choose.


But you can see if you switch to the, I think,


the individual countries that you can see in that report,


you can still drill down and see how many users from this country


saw that page and how many users from a different country


saw the page.


So it doesn't really fix the problem in that sense,


in that we still just index one version.


But theoretically, we should be able to swap out


the individual URLs.


If you need to have both versions of these indexed


independently, maybe for tracking purposes


or maybe because you have a different rich result


type depending on the individual country, for example,


then you would need to make sure that the content itself


of these pages is significantly different so that we


wouldn't assume that these could be considered duplicates.


Yeah, but actually, I mean, it's the home page,


like domain.com slash fr.


I can't see it on Google, even in France.


So even if I'm in France and I'm looking for the home page,


I can't find it on Google.


So the page isn't indexed at all?


Or?


It isn't indexed at all, yeah.


Google drops it.


If you search for the company name, or?


Yeah, the company name, like domain name training,


training center in France.


And I can't find it.


I can't find it.


OK, but in that case, it wouldn't


be a situation where we would pick one version


as a canonical.


So that wouldn't be a matter of the duplication in the URLs.


But it sounds like that's really just something where we're not


indexing that page or that site at all, which


from a practical point of view would usually


come from three things.


It could be a severe technical issue on the site


from the start, essentially.


It could be manual action from the web spam team, which


is not something that would happen if this is just


duplicate content.


That's not something where the web spam team would take action


on.


Or the third one that sometimes happens


is that someone used the URL removal tool, maybe


incorrectly or accidentally, and accidentally removed


the site from being shown in search results.


Like Google Search Console is saying


they picked the canonical URL.


They're just indexing the Canadian one.


But they're dropping all the other countries.


Yeah, but in that case, we would still show the URL.


So that's something.


If you're seeing that the canonical is chosen


as one of these, then that's a situation where


we would see this as being duplicate content, essentially.


And we would pick one of those versions to index.


But if you search for the company name,


you should still see that result.


It might be the Canadian URL.


But essentially, we should still be able to show that.


It would be different if it's really


like the whole website is not showing it all


for users in that country.


Then that's more a matter of these detailed technical issues.


So the hreflang isn't giving signals?


The hreflang helps us to swap things out.


But it doesn't change indexing.


So if it's the same content on those two pages,


that wouldn't be affected by hreflang.


Because that would be penalizing for us, because a French guy


would see a Canadian URL in the best case.


So he wouldn't click on it.


If you have hreflang set up properly


and we can recognize that across those pages,


then we would swap out the URL against the local version.


OK.


Yeah.


So it should.


It would take some time, maybe?


So it should look OK, even though


from a technical point of view, the indexing side


would still be indexing the other version.


Perfect.


Sure.


Thanks.


This kind of situation, especially


with international websites and the same content


in the same language, is really complicated sometimes.


All right.


Let me run through some of the submitted questions.


And we can open things up to more questions from you


all later on as well.


We have some questions regarding the URL parameters


tool in Search Console.


In a significant number of cases,


we've used the URLs with tracking parameters


for interlinking.


It's quite an amount of work to completely change this.


So we decided to add parameters to the parameter tool.


And now if we set the parameter to representative URL


and to know this parameter doesn't affect page content,


does this mean Google will only crawl the URL


version without a parameter?


Will it still consolidate signals


between the parameterized versions


but only crawl the URL without parameters?


We don't want to negatively impact our interlinking


because of these settings.


So yes, this does essentially try to do the right thing


in that it recognizes that we've seen


all of these different URLs.


And we can fold them together into one kind


of representative URL and use that one for indexing.


So it consolidates all of those signals that we've seen


and folds them into one version.


With regards to crawling, if you choose the option


representative URL, it doesn't mean that we would


crawl without a parameter.


It might be that we would drop the parameter.


It might be that we pick one value with that parameter


and just crawl and index that version.


But from a practical point of view, both of those


are essentially the same thing.


And like I said, from a ranking point of view,


from a signals point of view, everything is folded together.


So that would be fine.


We noticed that half the parameters added to the URL


parameter tools have disappeared.


We had about 160 in January and now only 80.


Is this problem with the dashboard displaying


all the parameters, or should we add back


the ones that are missing?


It feels like if you have 160 different parameters that


you're adding to the parameter handling tool,


then that seems like quite a complex website where probably


it would make sense to find ways to significantly reduce


that number of parameters that you actually use.


So parameter values is obviously something where


you might have a lot of them.


But individual parameter names feels like something


where you should aim for a, I don't know, maybe 20 maximum,


something like that, different parameter names,


because otherwise it's really, really hard


to understand how to crawl and index a website like this.


So that's something where I don't quite


know exactly what you're seeing with just the drop in parameters


that you have listed there.


But I'd really try to limit it to something


that you can kind of watch over for a website.


Since the last core update in June 3, 2019,


our news website has disappeared in short, top stories,


AMP and desktop.


We didn't make any technical changes,


which could explain this.


And we analyzed our whole domain.


We don't see anything.


What do you think could be affecting us in that sense?


We review our news articles, and we


don't see any issue about that.


So the updates from last June are a really long time ago.


So it's really hard to say what specifically


might have changed there.


But in general, when it comes to core updates,


we try to use these to essentially improve


the relevance of our search results.


And that's something where oftentimes, if you're


seeing changes from there, it's not


because of any specific technical issue on your site


or anything specifically that you're doing wrong,


but rather where our algorithms have recognized,


for whatever reason, that maybe this website, this search


result, wasn't as relevant to some of the queries


that we had shown it for in the past.


And we have a long blog post about different things


that you can do to kind of take a deep look into your website


and see what you could be doing to improve.


So I don't want to kind of rehash the whole blog post.


I kind of recommend taking a look at that.


And if this is something where you're


seeing those changes since last year,


then that feels like something where it's not just kind


of this one-off thing where it's like a little bit


that our algorithms are deciding to change things a little bit,


but probably things are still in kind of a shape


where you might be able to improve them overall.


I'm receiving a content injection security message


in Search Console for some of my URLs.


I check those pages with every possible aspect,


including Google expert advice.


I even watched the latest video regards the security issues


and didn't find any issue related.


And there are a whole bunch of URLs.


So I don't know.


I'll pass these URLs on to the team to double-check.


Usually, the content injection message


is something that we would show if our systems believe


that there's content that is hosted on your website


or served through your website that might not be something


that you created yourself.


That might be something that maybe a spammer created


or a hacker created, and they're hosting it


on your website for some reason.


Usually, this is something where maybe if your website is


about cars and then suddenly there's


pharmaceutical content in there, then our systems might say,


well, this feels like something where we need


to be a bit more careful with.


In general, these kind of messages


apply to individual URLs.


So it's not that your whole website


would be demoted or shown differently


in the search results.


It's really just those individual URLs.


But I'll pass these on to the team


to double-check to see if there is something maybe


on our side that we're picking up wrong,


or maybe there is something that we can let you know about.


Google is showing our old contact number


as a featured snippet.


Though we updated the new contact number,


it's still showing the old one.


Steps we've taken so far, we updated the number


and submitted for re-indexing, applied for Google My Business


page, which is still pending, removed the old number


from the existing pages, and replaced it.


So in general, these are the right things to do.


If you're seeing things in a featured snippet,


that would be due to essentially what


we would show as a snippet on a page, which


is based on the content itself.


So updating the number on the page,


removing that page from a or removing


that number from existing pages, making sure


that you have the new number in maybe the description meta tag


if that's where it was shown, or in any structured data


that you have there.


Those are kind of the right steps to take.


With regards to updating the search results,


sometimes this takes a little bit of time.


So it's not always the case that you click the button for kind


of submitting to index, and it updates it automatically.


Sometimes this is a process that takes a little bit longer.


So I'd give it a little bit more time there.


If it's really critical that this number is not


shown in search, so for example, if it's


in a number that doesn't belong to you,


or a number that doesn't work at all, then what you can also use


is the outdated content tool in Search Console,


where you can tell us that there is specific content


on this one page that has been removed.


And you can tell us what that content is that was removed,


the URL of that page.


And then our tool will take a look at that.


And either suppress that snippet for the time being


until it's been updated, or at least wait


until that search result is such that that old information


that you used to have there is no longer in there,


and then it would show that again.


So that might be something that you could do if this


is really a critical issue.


Recently, I requested outdated URL removal


from Search Console.


And I noticed that the site colon domain is still


showing the actual number of pages that are live on Google


to me after the URL removal.


And Search Console indexing status


shows more pages even after removals,


including previous outdated URLs so the data doesn't match even


after the removals.


This creates confusion.


So I'm not exactly sure what you're seeing.


But probably what you're seeing is


kind of a mismatch between the site colon search results


and the data in Search Console, specifically for the index


coverage report.


In general, the site colon number


that you see in the search results,


where it says of about so many thousand URLs


that we know for this site, that number is optimized for speed


and not for accuracy.


So I would not use a site colon request for any kind


of diagnostics purposes.


Instead, I would use really the number


that is shown in the index coverage


report in Search Console.


That's based on what we actually have indexed for the site.


So that's kind of the one thing.


The other part is specifically with regards


to the URL removal tool in Search Console.


The URL removal tool doesn't remove URLs from indexing.


It essentially just hides them from search.


So in practice, what can happen here


is that the URL might not be shown at all


or would not be shown at all in the search results


but would still be counted in the index coverage


report for the time being until we've removed that URL


completely from our index.


So that's something where you might see a mismatch there


as well.


In particular, if you remove a large part of your URLs


using the URL removal tool, maybe a whole subdirectory


full or subdomain full, then that's


something that could significantly


affect the number of URLs shown in search


but wouldn't necessarily affect the number of URLs


that we have indexed in search.


So we might have indexed them.


We know about them.


But we would not show them.


If you want those removed from indexing as well,


then you need to make sure that there's a no index


on those pages, that there is a 404 status code,


all of those usual things that you would do to remove pages


from the index.


We have multiple location website.


The content of the pages is similar.


So Google dropped the.com slash fr page


and said the domain.com slash ca page is canonical.


I think we talked about this briefly in the beginning.


So skip this one.


Google currently limits the number of URLs in a site map


to 50,000 URLs.


Does that include hreflang alternate URLs, videos,


and images?


No, it specifically specifies the primary URL elements


there.


I don't know.


I think the tag is the loc component tag


that we use in the site map file.


Not 100% sure.


But essentially, it's the pages that


is limited in the site map file.


The attributes where you have extra information


for those individual pages, like hreflang alternates, videos,


or images, those are not counted in the totals.


In practice, they're kind of a part of the totals


as well because there's also a limit on the file


size of a site map file.


So if you have a large number of other URLs


that you supply in addition to those pages,


then usually the file size would get large enough


that it would also be too large and would


need to be split into separate site map files.


But you can create separate site map files.


You can submit them individually.


You can submit a site map index file,


which points at a number of different site map


files automatically.


So all of that is possible to really exceed those limits


by quite a bit.


We've seen some websites being targeted by Black Hat SEO.


They have consistent bad links pointed at them daily,


and they've also seen some big drops.


We're constantly having to block links.


Do you still maintain that bad links don't matter?


So this is certainly something that our systems work really


hard on to make sure that any kind of negative SEO


or any kind of irrelevant backlinks,


unnatural backlinks, that as much as possible


we're able to ignore them completely.


Usually the cases where I see that something


around negative SEO is happening are kind of the cases


where when you would look at them manually,


you would say, well, this looks like maybe someone has built


these links up over the past.


And it's not really a competitor,


but maybe an SEO that's been working for the company.


So that's something where our web spam team,


if they look at that and they see this kind of situation


where it's really kind of improbable


that a competitor has built up links for a website


over the course of the last decade,


then that might be something where the web spam team would


say, well, maybe you should clean those links up.


Second part is we've seen some websites that were hit


by Google Burp update, and they still


have not recovered.


Was that update only about intent?


Because it seems like it was about more.


So BERT is essentially a way of better understanding text.


It's not a ranking change in that sense.


It's not an update, kind of algorithm update,


that suddenly we rank things differently.


But it's really about understanding text.


So it means that we work hard to understand


when people enter queries into the search results.


In particular, when these are long queries where


we need to understand what is the context here,


what is something that people are actually


searching for within this query.


And when it comes to pages themselves,


we try to figure out what are those pages actually about,


and how do those pages map to those specific queries


that we've got.


So it's not a ranking change, per se.


It's really about understanding the text on a page


and the text that people enter in the queries.


And from that point of view, it's


not that websites get hit by this update.


It's really that we're trying to understand


what these pages are about.


And if these pages are such that it's really


hard to understand what they're about,


then users will have trouble with them,


and our search engine will have also trouble with them.


Usually, in the cases I've looked at where people say


they were hit by this kind of update,


it's more that there were just general changes in search


over time that also took place.


And we make changes in search all the time.


So it's not necessarily the case that because Google understands


the pages better, we suddenly decided


to kind of penalize a set of individual pages,


because we're trying to understand these pages better,


not try to understand what people are doing things wrong.


Image search results sometimes show images


from a related product section on an e-commerce site


with the title of the containing page, another product page.


This could lead to results with the title Product A,


an image of Product B, misleading users


and creating false information.


We saw it also on big sites like Etsy.


Is there any way to signal to Google


that these images are not describing the page,


but are describing the target page,


similar to how an anchor text describes target pages?


Or is there another way to solve this problem?


So in general, we do try to understand


where the primary images on a page are


and to use those for image search primarily.


So if you're embedding the main images in a visible way


within a page, in particular, if you're also


using the structured data to tell us


about those images on a page, for example,


if you have the article markup or something similar


and you can really specify the primary images on a page,


then that's something that makes it easier for us with regards


to Google Images to understand which images we


should be associating with this particular page.


Obviously, if you have related images, kind of like thumbnails,


sorry, thumbnails leading to other pages


and those other pages are not indexable


or the primary image on those other pages


is not recognizable, then it can still


happen that we would show those thumbnail


images associated with that particular landing page as


well.


So that's something where if we don't have anything better,


then we might choose something suboptimal.


But if you can specify those images in an optimal way,


then it's a lot easier for us to pick those up


and to actually use them.


Many times due to website structure,


we have long and weird anchor text.


Price, number of reviews, review text, ratings


are included in the anchor text.


Is it OK for SEO, or should we fix it,


or should we just make sure that important keywords are


present in the initial part of the anchor text?


So from our point of view, you can leave your anchor text


as natural as you want.


And if you're including more information in an anchor text,


that's perfectly fine.


It's not the case that we kind of count the words in an anchor


text and only evaluate each word as a fraction


of the total number of words in a piece of anchor text.


If you're giving us more context about a specific page


on your website through the anchor text,


then that's fantastic.


So for the most part, I wouldn't recommend


doing anything particularly artificial for the anchor text


just to make sure that only the keywords that you


want to have associated with that page


are visible in the anchor text.


On one of our mobile domains, I'm


seeing that level 3 depth category


pages are not crawlable from level 2 category pages.


We have breadcrumbs also.


Will Google be able to make the relationship of level 3, level


2 by breadcrumbs present on level 3?


Or should we make all important subcategory pages crawlable


for bots on the parent page?


Currently, they're not Ahrefs, but the user can navigate.


So I don't quite understand this question.


But in general, if you want to make sure


that we can crawl your whole website,


then we need to be able to find links across that website,


ideally from both directions.


So in particular, if you have different category levels


where you can go down one category,


maybe like a submenu or different subcategories


section on your website, then we really


need to be able to find links so that we can go down that path


as well.


And it's not enough to just find links leading us back up,


but we really need to be able to find a way down as well.


And ideally, we'd also be able to find some way


across those different pages, so between individual items


and maybe related items or other items that are


within that same category as well.


So that's something where I really


recommend that you make sure that this kind of structure


is crawlable on your website, that it's


kind of a reasonable structure, that it's not too deep,


that you just have lots and lots of categories,


but also not too broad that you put everything


on the same level.


So finding that balance is sometimes a bit tricky.


But making sure that we can crawl in essentially


any starting point and reach the rest of your website


from there through clicking on links,


that's essentially what you should be aiming for.


And there are a bunch of third-party crawlers


that you can use to test your website in that regard.


If you're unsure about this and it


sounds like you have some understanding already


of what it takes to make a crawlable website,


then I would strongly recommend using one of those crawlers


to kind of start crawling from one URL


and see, does it actually reach the other side of my website,


and kind of find all of the pages within my website?


Or does it get stuck somewhere?


Maybe there are individual categories


that don't have links to the next parts, where you're


using some kind of other maybe JavaScript-based navigation


that doesn't use links.


So that's kind of the direction I would head there.


Lately, I noticed new pages on my website


are not being indexed.


And there are no errors related to crawling or other things.


The content is unique.


It's been around for three weeks since a new page is indexed.


What should I do?


Is this normal?


I have a new website.


In the past, pages were indexed relatively quickly.


But the process of indexing is getting slower and slower.


So we don't promise to index all pages on the web.


That's kind of the first thing there.


It's not a guarantee that just because you create a page


that Google will go off and crawl and index that page.


Even if you use the kind of inspect URL tool


and submit it to indexing, it's possible


that, especially with a newer website,


if there's a lot of content suddenly on a new website,


that our systems might be a bit cautious and say,


is this really something we should


be spending a lot of resources on to crawl and index


all of these pages here on this website


that we don't know about yet?


Or should we be a little bit more cautious there


and wait to see until we have better signals


about that website to understand why that website is so


absolutely fantastic that we must absolutely go forth


and crawl all of the content on that website?


So in particular, if this is a new website,


working more on quality rather than quantity


is something I would recommend.


And working to make sure that your website is well


embedded with the rest of the web also makes sense.


So that's something where maybe it makes sense


to promote your website a little bit


to get things going on your side,


how you would do that with a normal business.


If you open a business in a new city somewhere,


you don't just open your business


and hope that people find you and come to your store


and buy something.


But rather, you do something to get things started.


And over time, if you do things right,


if you have fantastic content, then you'll


have that word-of-mouth effect that people


will recommend your content.


And over time, that's something that we would pick up


for search as well.


I'm looking at a website that's approximately 100,000 pages


in size.


Approximately two years ago, they


made a bunch of fairly significant changes


to a website all at once that caused the algorithms


a lot of confusion and haven't really recovered since then.


They saw a drop in rankings and visibility across search


results in general.


After changing the main name, framework, platform, content,


et cetera, OK, that's a lot of changes.


One of the key pages seems to rank OK


for some of the commercial terms,


but they don't appear for all of the other variation.


This page doesn't even appear for the term


in the top 250 results.


Less relevant pages like blog posts from the original


or from their website rank somewhere in for the term.


It seems that the page itself is not a problem,


as it ranks for other popular pages.


This particular keyword is also used in the footer


and makes up 98.9% of the anchor text pointing to that page


over the other terms.


Have you seen other cases like this


where pages penalize for this particular keyword because


of over-optimization?


So I don't know.


The 98.9% sounds like a lot.


But depending on a website, especially


if you're talking about internal links,


it is very common that individual pages have


a lot of the same internal links.


Depending on the CMS that you're using,


it's possible, for instance, that you have a product,


and that product has a name, and it's always


linked by exactly that same name.


And then all of the internal links to that product


use that product name.


And that's perfectly fine.


So that's something where it's not necessarily automatically


the case that we would kind of algorithmically ignore things


just because they're used a lot in the anchor text.


It's really hard to say specifically


what is happening here.


I think you sent me some examples.


So I'll double check those together with the team


and see if there is something particular that I can pull out.


But it can certainly happen that individual pages rank well


for some popular queries but don't rank that well


for other popular queries.


So that's not necessarily something


where I'd say there's automatically something


broken that needs to be fixed.


I experienced the following situation.


I published a new blog post.


For the past two weeks, the URL was and still is


listed under discovered but not indexed in the coverage report


in Search Console.


Inspecting the URL, Search Console


says the URL is on Google with the correct self-transparenting


canonical tag.


Looking into a search performance report,


I discovered that the URL is indexed twice


with different UTM parameters from Facebook and Twitter.


Is this something that Google will fix by itself


because the correct canonical is set up?


Or do I have to take any action?


I'm using a domain property in Search Console.


Should I also add the URL prefix property


and use the legacy URL parameter tool?


So if you're using a lot of these parameters


on your website and you want to simplify the tracking,


then it's probably worthwhile to use the URL parameter handling


tool for this.


Because with that, you can more clearly


specify which URLs you would like to have indexed.


From a practical point of view, I


don't think this page will be ranking differently


in the search results.


Because if we already have one version indexed,


if we have the non-parameter version indexed as well,


we would see that as a duplicate of these parameter versions.


And we would essentially just fold those signals


into that preferred version.


So from a tracking point of view,


it's a little bit trickier because you


have these UTM parameters.


But from a performance point of view,


it should be essentially the same.


So that's something where I wouldn't see this


as a critical issue that you must fix immediately,


but rather as something that just makes reporting a lot


harder than it needs to be.


So if there is a way that you can tell us


that you want those parameter names excluded or ignored,


then I would go ahead and do that.


Otherwise, what will usually, I mean,


what should happen here is over time,


if we see those URLs with the parameters,


with the URL canonical pointing to the non-parameter version,


we'll pick that up as well.


And we'll just do that automatically.


So if you wanted to give it more time, that's perfectly fine.


That should just settle down.


If you want to take things more into your own hands


and using the URL parameter handling tool


is an option there.


With the parameter handling tool,


it's still not the case that this will immediately


fold everything over.


But in particular, with new URLs, as we discover them,


we'll be able to ignore that parameter essentially


from the start.


In our old articles, there are photos


that host on HTTP servers.


Google Chrome says that we have mixed content.


Is this really a problem for us?


I read that Google Chrome automatically


changed HTTP to HTTPS.


And if the object is no longer available,


then it would be ignored by the browser.


So in practice, this is something


where when talking with the Chrome team,


they obviously don't like to see this.


And it is something that is shown in the browser bar


that you have mixed content on a particular page.


The security effect here is that with mixed content,


if the browser is requesting HTTP URLs,


then you could be leaking information


about that user session over HTTP, which theoretically


someone along the way could be picking up or taking


advantage of in other ways.


So in practice, I recommend to try to clean this up.


From a ranking point of view, it doesn't really


have any effect.


It's more a matter of for your users,


it's worthwhile to clean this up.


Sometimes there are ways that you can search and replace


for things like old host names with HTTP


and just replace it with the HTTPS version.


So in particular, if your content is already


accessible on HTTPS, then it might


be an option to do it like that, to pull together


some kind of an SQL query to automatically swap those out,


if that's something that is on a database-based site.


If these are old HTML pages that are individual files,


then maybe there are different things that you'd


need to do there.


Let's see.


I recently am trying to QC one of my clients' hreflang


implementation, a huge e-commerce site with more


than 10 million pages.


I found it extremely hard to QC or examine certain pages


because they're using a sitemap hreflang, especially


when I try to examine a specific page


and I have to go back to the sitemaps


to see if there are references.


I already found a lot of errors in their hreflang sitemaps


too.


Should I recommend them to use HTML or HTTP method instead?


I heard that HTML hreflang will increase page weight,


but those codes are not render blocking,


nor do they have any download or send HTTP requests.


They're just in plain text.


So it shouldn't affect page speed too much.


What about HTTP hreflang?


How would you deal with a huge e-commerce site's hreflang


setup?


So we support hreflang through the meta tags on a page


or through HTTP headers or the sitemap file.


And from our point of view, all three of those are equivalent.


So if there is a method that makes it easier for you


to maintain or to track or implement hreflang,


then I would try to use that one.


If you're finding it really hard to maintain


a particular implementation that you didn't add yourself,


then maybe it makes sense to migrate that


to an implementation that works better for you.


With regards to the HTML version of the hreflang tag,


so if you're using it in the header of a page,


you're correct.


This is essentially just static text.


It compresses really well.


So for the most part, it doesn't change a lot considering,


assuming this is an e-commerce page with a lot of content


on a page, it doesn't affect the payload significantly,


depending on, obviously, how many hreflang variations you


have.


But this kind of content compresses really well.


So it shouldn't affect the payload too much.


This is something you can double check, though.


So you can add this kind of hreflang annotations


to some test pages, use kind of static testing tools


to determine the actual payload size


and to determine the effect on theoretical page speed.


When it comes to speed, I would recommend


taking a look at the new Web Vitals, which we put together,


I think, last week or fairly recently,


which includes some neat metrics that we think


are fairly relevant for the web.


So it might make sense to double check what those metrics say


with these two variations.


OK, kind of running low on time.


Maybe we'll just switch over to live questions


if there's anything still left from your side.


No more questions.


Sure.


AUDIENCE 1 Hey, John, can I?


OK, just double clicking on the first question


about the meta description.


During April, we had updated one meta description


from one client adding, during COVID-19 outbreak,


we are working because it's just an online business.


And it has nothing to do with health or anything.


Just to emphasize, we are working.


And we didn't see it on the SERPs.


So we updated again.


We thought maybe it's a red flag for Google.


Let's exchange COVID-19 for April.


And still, it doesn't show on the SERPs.


Now with algo update, it's not showing still.


Is there anything wrong with it?


Or what would you say about it?


It's hard to say.


But I mean, with the meta description,


if you're putting it into the meta description,


on the one hand, there are limits


to how much we would display from a meta description.


So maybe that's the limit.


Inside the limit.


We consider the limit.


Yeah, OK.


The other thing is if it looks like something


that is kind of spammy where it's more keyword stuffing


related in the meta description, then that


might be something where our systems try


to determine a meta description to show ourselves.


My guess is that's less the case if you're


adding additional textual information.


And the other thing is it's worthwhile to search in the way


that users would search.


So not by checking with a site query,


but rather by searching for your company name


or kind of the common queries that you would do.


Because we do change the description


that we show in the search results based on the query.


And if it's a site query that you're checking,


it might be that we're not really sure


what we should be showing in the description part.


Right.


We work on that.


Thanks.


Yeah.


I mean, the other thing is also that sometimes this just


takes a while to be updated.


But if you're talking about April,


then it feels like it's more than a couple of weeks already.


So that feels like something where


we should have updated that.


Sure.


Hi, John.


Can you hear me?


Yes.


Yeah, this is Ahmad.


So something I just wanted to share and see if you


have any ideas or thoughts.


So we have a site where US doctors are answering patients'


questions anonymously, just like Quora or Stack Overflow.


So we have several million long library.


We recently did an infrastructure update


where we had to change some of our URL structure.


So we basically did a 301 redirect


for many of our pages, and we submitted a new site map.


Since then, a majority of our pages


have been stuck in discovered not indexed,


and pretty much like 90-plus percent of our pages.


And it's also resulting in some traffic drop,


some significant traffic drop.


So just trying to understand if there's something wrong


that we did, or we should have done it in a different way.


My guess is it's unrelated, because with a redirect, what


you're really telling us is that we should pick


a different canonical URL, which means if we haven't processed


the redirect yet, we would keep the old URL in search.


If we have processed the redirect,


we would use the new URL in search.


It wouldn't be the case that the URL would drop out


of the search results.


So it's not that we would show less in search.


It's really just, do we show this URL,


or do we show that URL?


If you're seeing a traffic drop overall,


then that feels like something that


would be unrelated to this kind of site move.


SPEAKER 2 Got it.


So the old URLs that are not in the new site map


are not automatically being removed from the index?


JOHN MUELLER Exactly.


Yeah.


So that sounds to me like it's more a matter of maybe


our quality and algorithms just not wanting to index as much


from this website as before.


It's not something where there's a technical issue


with that redirect.


OK.


Thanks.


JOHN MUELLER Sure.


All right.


I think there's someone else that wanted


to ask a question in the chat.


SPEAKER 3 Hey, John.


This is my first time joining the chat.


And I totally feel like the new kid


that walked into a very, very advanced class.


And I know my question is going to be really stupid.


So please just bear with me.


I don't know SEO.


I know that the Webmaster guidelines.


I've been reading them.


But if you had, let's say, for example, a website that sold,


I don't know, let's say baseball hats.


And they sold baseball hats for, let's just say,


every single team.


And there was different colors.


This is all hypothetical.


What on earth do you put in the meta description


besides like Yankees blue hat, Yankees red hat?


You know what I mean?


The meta description is kind of the description of the page.


So if it's essentially like a Yankees blue hat,


then you might use something to describe that in a more,


I don't know, readable way, which


could be like buy your Yankees blue hat on our website.


Or add something like free shipping,


or whatever kind of additional information


that you might tell someone if you


were to meet them on the street and they're like, oh, I'd


like to buy a hat.


Then it's like, what would you tell to them?


Kind of that level information.


So the different things across those different products,


that would probably be like the product name or some attribute


from the product.


But the rest can definitely be the same thing.


It can be like buy your Yankee blue hat here,


or buy your Yankee black hat here,


depending on what the individual products are.


And you're talking about on the meta description


of the individual products.


It's Shopify.


I don't think that makes a difference.


Awesome.


Thank you.


Thanks for taking the time.


All right.


I need to jump off to another meeting.


But it's been great having you all here.


We have the next one lined up, I think, for Friday.


If you all want to join, depending on time zone,


maybe that works better or less well.


And I'll set up the next meetings as well in two weeks


again as well.


Thanks a lot for dropping by.


And hope to see you all again in one of the next Hangouts.


Bye, everyone.


Bye, John.


English Google Webmaster Central office-hours from March 17, 2020

All right, welcome, everyone, to today's Webmaster Central


office hour hangouts.


I guess not office hours anymore, but kind of like,


I don't know, people hours.


My name is John Mueller.


I'm a webmaster trends analyst at Google in Switzerland.


And part of what we do are these hangouts


where people can join in and ask any question related


to their website and web search, and we'll


try to find some answers along the way.


It looks like people are busy with other things, which


is totally understandable.


Not a ton of questions were submitted,


but we have a bunch of people here.


So if any of you want to get started


with the first question, feel free to jump on in.


Hi, John.


Hi.


Pretty good.


So I have a question today about,


I have a single source AMP carousel on mobile.


So it's my page in the results.


It has a carousel of AMP articles.


So we've had it for a while now, for I think almost two years


or something.


But since around Christmas, the article


stopped updating less frequently.


So we stopped getting fresh articles in the carousel.


It used to be maybe articles that


were published after two or three hours,


they would appear in the carousel.


Now we are lucky to get articles from within the last 24 hours.


And there's a lot less content in there now.


So we used to have more items, 10, maybe a little more


around there.


Now we have around three, I would say.


So since this started happening around Christmas,


we've made a few changes to our schema.


We've updated.


I noticed there were some inconsistencies


in our timestamps, so on the article versus on our site maps


and our feeds and stuff like that.


So we've updated all of that.


And I'm not really sure what else it could be.


But the carousel itself still hasn't updated.


And I don't find too much information


online about single source carousels in the first place.


So I'm not really sure how to diagnose this issue.


Yeah, do you have any advice for how we might be able to fix it?


I'm not quite sure what kind of carousel you mean.


Is it the top stories thing on top of the results?


Or?


Actually, if you want to pull it up, if you type movie news,


you'll see it's the results.


It's like a result for a single page.


And it has just a carousel underneath the site link


for AMP articles.


OK, I probably need to check that afterwards.


Kind of tricky to check that live.


And online, of course.


Yeah, if you could maybe post some links or a link


to a screenshot in the chat here,


I can pick that up afterwards and double check.


Sure, that would help.


Usually, I'd say the date is definitely


something to watch out for.


That's something I know a lot of sites get wrong,


in that they have inconsistent time zones, for example,


on the page and in the structured data.


But otherwise, my hunch is that for a lot of these cases


where there's just less content showing up in the search


results, it's more a matter of quality,


in that our algorithms are not quite sure about the quality


of this content.


And therefore, they're kind of reducing the visibility


of that content appropriately.


But I'm not.


I'm sorry.


I tried to send the screenshot, and it accidentally


changed the page.


So I just missed what you were saying.


Can you repeat?


Sure.


So I think dates is probably a good point to look at.


That's something that a lot of sites get wrong,


especially if there is an inconsistency with time zone,


for example.


So that's definitely a good thing.


But otherwise, for a lot of these cases


where the site or its content is just not


as visible in the search results,


it's really more a matter of the quality of the content, where


our algorithms are a bit unsure maybe how much of this content


we should be showing.


So that's something where, on the one hand,


double-checking all of the technical issues


is definitely a good idea.


But I wouldn't only limit your kind of review of the site


to technical issues, but really kind


of be critical about the quality of the content as well.


And I haven't looked at your site.


I don't know exactly what kind of content you have there.


I'm just kind of throwing this out there.


But if you can post some links in the chat,


then I can take a look at that afterwards.


OK.


So the other thing that might thicken the mystery


a little bit is we do perform very well in top stories


carousels in general.


And we have other carousels for some other pages in the search


results.


So some other queries that we rank for,


those carousels seem to update more frequently.


And if you even Google just the brand name of our site,


and there's a carousel for latest articles,


those always are very recent and plentiful, I guess.


So it just seems to be for that query in particular.


And it was a bit of a recent change only a few months ago.


So does that shine some more light to the situation?


It's hard to say.


Yeah.


I mean, to me, that would sound like,


from a technical point of view, you're probably doing it right.


And it's really a matter of us trying


to understand which pieces of content from your site


we should be showing.


So especially if you're seeing it in the top stories,


if you're seeing it for other kinds of carousels,


then that means we're technically


able to crawl and index the content fast enough.


So it's probably, from a technical point of view,


not an issue and really more a matter of we


don't know how much of your content


to show for those particular queries,


especially if you're saying for some queries it works well,


and for others it doesn't.


So maybe more of a relevancy thing here?


Could be, yeah.


Because we did change our content operation slightly


around that time to expand it to doing


newer types of newer verticals, I would say,


newer genres of content that we didn't do before,


whereas the movie news content, that


was our primary content before.


So that potentially affected.


I think it's tricky when it comes to things like that,


because our algorithms, when things change,


it's often not based on the things


that you change on your website just the moments before.


So from a technical point of view,


you do have this relationship very quickly,


where if you make a big technical change,


that'll take a couple of days and so be visible in search.


But from a quality point of view,


usually the quality changes take a lot longer


to be updated in search.


So if you're seeing significant changes in search


and you just made some changes a couple of days ago,


then those changes, unless there was a technical issue


with those changes, then that probably wouldn't be related.


So if you're saying you changed the way that you created


the content maybe a week before this change in search,


then my feeling is that wouldn't be related


to this drop in visibility that you're seeing.


SPEAKER 2 OK.


OK, I'll send over a screenshot in the chat


so you can take a look.


Thank you.


And then if you have time, I had a second quick question.


OK, go for it.


SPEAKER 1 So we get a lot of discovered.


I work on publishing websites that get a lot of Google


Discover traffic.


And I know you said in the past that you guys currently


don't have plans to add a referral source for Google


Discover in particular.


So recently, we had a situation where an ad partner


that we were trying to work with audited one of our websites


that gets a particularly high amount of discovered traffic.


And they assumed it was a suspicious activity


on the website because there was no keywords.


Like the keyword data didn't match up with the amount of search


traffic, or Google traffic, I should say,


that we were getting.


So in this case, we have a pretty good relationship


with that advertiser.


So they contacted us and we were able to explain the situation


and stuff.


But I don't know if this is something


that you've heard affects other publishers.


Given that that's the case, that these situations arise


from there not being a proper referral for Google Discover,


is it something you guys would consider adding in the future?


I don't know.


I'd like to have a clear refer for Discover.


But at the same time, from kind of a bigger picture


point of view, we see Discover as a part of search,


as a part of this big Google family of ways


to get traffic for a website.


So other people are saying, well,


we should just fold it all together into one big refer


and keep it like that.


So I totally get the advertising angle.


That's probably tricky.


The one place where we do have Discover data


is in Search Console, where you see


the total amount of clicks and impressions that you got,


the click-through rate there.


So that's something where you could point at that,


or you could export that as kind of a CSV file


and show that to them, too, to show a little bit how


the split is between normal search traffic


and Discover traffic.


For sure.


And on that note, we do have the Search Console data.


But in GA, it can be hard to map, I would say,


the two sources to each other.


For us, our Google Discover traffic


ends up kind of the dark, direct traffic.


So it gets lumped in there, and then it


becomes difficult to sort of untangle it.


And the numbers for sessions and clicks


never really quite match up.


So it just becomes a little muddled.


So even internally, I find that there


are issues with disambiguating that Google Discover data.


So given that, I think Chrome article suggestions


are properly distinguished as Google APIs as a source.


So it is a bit of a confusing situation


from sort of all aspects.


And I mean, if there's any way to maybe pass this feedback


on to the team or something, I would really appreciate that.


Yeah.


I'll push for that again.


I think lots of people want more data with regards to Discover,


especially when they see a lot of traffic going through there.


So I totally understand your point.


OK, thank you very much.


Sure.


All right, any other questions before we get


started with the submitted ones?


Yeah, sure, John.


I've got a question about FAQ schema or QA page schema.


We write a lot of content and a lot of articles


where the main topic is a single question,


but there are often multiple answers.


So I'm just wondering about how to mark that up,


because the way that I've marked it up,


it doesn't really look good when I get the schema generated.


It's question.


The question just shows up multiple times.


I have the title of the question multiple times,


and each with a different answer.


I'm assuming that that's probably not super good to do.


What would you suggest I do instead


of listing the question five times with the five


different answers?


What might I do differently?


I don't know.


Hard to say.


I think QA page is also more meant for user-generated


content, right?


Yeah, so then it's FAQ, the other content.


Yeah.


I was confused with those two.


Me too.


I would test things out.


I think the nice part about this is


that you can see fairly quickly if it gets picked up and shown.


And that makes it a little bit easier for you


to double-check things like the clicks and impressions,


click-through rate.


If you're getting what you think you'd


like to achieve with those pages,


then I think that's a good idea.


I don't know with regards to the policies


if something like this is OK to say, well,


it's the same question, but there are multiple answers.


So therefore, I have multiple entries in the FAQ.


That's what I'm mostly worried about


is if I'm against some sort of a policy.


Yeah.


I'm not aware of anything particular with regards


to the policy in that regard.


And usually what would happen if there were something


where this would go against the policy, what would happen


is someone from the Web Sam team would take a look at that


and say, oh, this is not compliant.


They'd apply a manual action for that,


which would essentially mean that the structured


data, the rich results, would not


be shown that way in search until the reconsideration


process has been kind of completed.


So it's not that your website would drop in ranking.


It wouldn't disappear from the index or anything.


It's really just, well, those elements


where the team says it's not compliant usage,


those would not be shown.


So it's something where, especially


if the guidelines aren't completely clear,


then that feels like something where


you can try things out a little bit,


see what works well for you.


And kind of if someone from the Web Sam team


were to look at that and say, well,


this really doesn't match our guidelines


or we've changed our guidelines because we see people


do things in weird ways and that suddenly includes things


that you're doing, then in the worst case,


you'd be going through that reconsideration process, which


is it does take a bit of time, but it's not


the end of the world.


SPEAKER 2 And might that only affect that page,


or am I putting my site at risk?


JOHN MUELLER That would generally affect the site


and that type of rich result.


SPEAKER 2 Got it.


OK.


I'm going to try doing question, and I'm


going to append maybe part of the first answers,


so that it doesn't look, because it just looks really spammy.


It's question, question, question showing up


in the FAQ schema.


I'm going to try something a little different,


but thanks for your help.


JOHN MUELLER Sure.


John, on the FAQ schema, they used to show emojis.


Do you know if Google recently stopped showing emojis


in FAQ schema?


Are you not aware of anything with that?


JOHN MUELLER I don't know.


So we're not showing them anymore?


SPEAKER 2 Somebody said they're not.


I tried to search for them for a long, long time,


and then I found one French site that happened to show it,


but I don't have every query.


I have old screenshots, and those don't even


show FAQs at all, schema at all.


So you're not aware of any change there.


I'm not aware of anything particular with FAQ


and emojis.


I know with emojis, one of the things that they always


struggle with is kind of misleading emojis.


So if people have stars, for example,


and they make it look like review stars,


then that's something where the snippets team might look


at that and say, well, we should filter out


these particular characters because they're


misleading to people.


But that's less a matter of the FAQ markup or not,


but more it's like, well, we've noticed


that this is really being spammed,


and people are using them for misleading ways.


Then that might be something where we take action.


But otherwise, we have lots of weird characters in the search


results and try to allow people to be a little bit creative.


Barry, I'll throw a question mark emoji


in one of my FAQ schemas and see if that shows up for you.


Cool.


OK.


Let me get through some of the submitted questions,


and then we can get back to more questions from you all.


Hang tight.


If Google has moved my site to mobile-first indexing,


do I have to optimize or at least put


more effort into my AMP pages?


So from my point of view, this doesn't change anything


with regards to how much effort you


should put into the AMP pages.


The AMP pages should be consistently matching


what users would see anyway.


So that's something where the mobile-first indexing side


is kind of independent of how much work you should


be putting into your AMP pages.


In general, the AMP team, for example,


is not fond of pages that are very simplified AMP pages where


there's a lot of content missing.


Obviously, there are some elements


that you can't easily do on AMP pages, and that's fine.


But in general, the AMP page should


match as much as possible what you have on your normal pages.


My site is no longer appearing in search results.


There are no violations on my sites,


and it stopped appearing completely from March 12.


It's a Google News-approved site.


I received over 3,000 bad backlinks from my competitors


and over fake DMCA complaints from my competitors, which


I have countered them in awaiting Google's response.


Why is my site de-indexed and loaded in Google


when there is no violation on my site?


It's really hard to say without a site.


So that's something where what I would usually


recommend in a case like this is to post this in the Webmaster


Help Forum, where there are a bunch of people that


are able to take a look at your site


and give you some guidance on what you could


be looking at there.


And they're also able to escalate issues


that they're not able to resolve in the Webmaster Forum.


So that's something where it's kind of like a normal


escalation path there.


They can also help you to figure out what kind of issues


you're really looking at there.


Because on the one hand, you're saying


your site is no longer appearing.


And then the last question is, why is my site de-indexed


or demoted in search?


And from our point of view, there's


a really big difference between a site that's de-indexed


and a site that is demoted.


So de-indexed would be not appearing at all.


It's not indexed at all, which oftentimes is either


due to a very significant web spam


issue or a technical issue.


And so if it's really de-indexed,


that's something where oftentimes there are really


clear paths to resolving that.


Whereas if it's demoted, where it's just not ranking as well


as before, then that's a lot trickier


because that can be due to a lot of different reasons


with regards to the quality of the content,


kind of the general setup of the site.


All of that can kind of play a role there.


In general, I wouldn't worry too much about these 3,000 bad


backlinks from competitors.


Our systems are pretty good at recognizing those kind


of things and ignoring them.


So that's something I wouldn't focus on too much with regards


to DMCA complaints.


Obviously, responding to them if they're invalid


is the right approach there to do.


There seems to have been a very significant change that


took place on January 14.


My traffic and revenue have been negatively affected


despite no penalty or notification of any problems.


While I'm used to an ebb and flow of traffic and revenue,


I guess it goes on like, are you able to give


any advice on specific things to focus on to get back on track?


So first of all, I'm not aware of anything specific that


happened on January the 14th.


So I don't really know exactly what you're pointing out there.


I also don't know your site.


So it's really hard to say what might be involved there.


In general, I think there are a few things to keep in mind.


On the one hand, there are lots of sites in the search results.


So it's never the case that everyone


is demoted and no longer visible in search,


because there are always sites that come up as well.


It's not that we don't show anything in search.


So these kind of changes are generally pretty normal,


and they can come and go.


And that can be due to changes in our algorithms.


It can be due to changes in the way that people search.


So if a topic suddenly is no longer as interesting,


then maybe you will have less traffic


for those kind of queries, just because it's something


that people don't search for anymore.


It can also be due to changes in quality on the website


or the perceived quality of a website based on our algorithms.


But all of these things are really


kind of hard to guess at without knowing your website.


So that's something where I'd also


start a thread in the Webmaster Help Forum


to kind of get other people's input on this.


And when you start a thread there,


try to be as transparent as possible about your site,


the kinds of queries that you're seeing changes in,


maybe significant changes that you've


made on your website in the past so that people are really


able to look at this problem and give


you honest and direct advice.


There is no need to kind of hide things that you're aware of,


but you don't really want people to notice offhand.


It's a lot easier for people to help


if they have kind of the clear picture of what's


involved with your site.


What are the major differences between any two posts that


rank at number n and at number n plus 1 in the search results?


That's really hard to say.


It's not that we have this one factor that


determines the ranking of pages in the search results.


It's really more that we have lots and lots


of different factors that are involved.


And sometimes there is subtle differences


between pages and the way our algorithms review them.


And they can result in one page being ranked higher


at one moment.


And then maybe when we review them again, our algorithms,


we maybe rank them in the other order.


And it's not the case that there's this one magic thing


where everything is sorted by this number.


I don't think that would really make sense.


So there's no kind of like one search ranking factor


that trumps everything else.


How to hide text in an SEO friendly way?


For example, we have a big table of content in an article,


and we want to hide part of it for mobile users.


So I think in general, this kind of question


is tricky because on the one hand,


you're saying this content is important.


Otherwise, you wouldn't have it on your pages.


On the other hand, you're saying, well,


you want to hide it from your users.


So you're saying it's not that important.


My general recommendation here would


be to make up your mind and to pick either


leaving the content on there and making it available to everyone,


including users and search engines,


or removing that content from your pages


so that it's not on that page anymore.


In particular, when it comes to mobile users,


at least from the numbers that we see,


most users are using mobile devices nowadays.


So if you're trying to hide content from most users,


then that seems to me a pretty strong signal


that you probably don't need this content at all.


If you do want to keep that content


and you just really think mobile users don't need this,


then I would just put it on a separate URL


so that those who do want to see the content,


they can navigate to that URL.


They can click a link to go there.


And those that don't want to see that content


have the page without that content.


I'm working on an international site revamp and migration


project, which takes the phrase approach for launching


different market sites.


There will be a transitional period


with different new and legacy market sites concurrently


running with different URL structure on the same domain.


The issue is this situation will make implementation of hreflang


very difficult, as each market site has around 1,000 pages.


Every time a new site is launched,


the update of hreflang tags has to go


through thousands of pages.


For this transitional period, would it


be OK to just have geosignals with location targeting


setting in Search Console and subfolder structure


differentiating countries without implementing


hreflang tags until all new sites are launched?


From my point of view, that sounds


like a reasonable strategy.


In general, when it comes to hreflang,


especially with large international sites,


the one thing I would watch out for


is that every time you add a new connection within your matrix


of hreflang pages, that expands and adds a lot more complexity


all the time.


So if there is a way, for example, for you


to go from having all of these different versions


and go to having fewer versions, maybe just country-based


versions, then I'd try to go in that direction.


Usually, fewer pages makes everything a lot easier.


Especially if you have pages that can be either just purely


geotargeted where you don't need hreflang,


then that makes it a lot easier as well.


One way you can think about this is if you're already


in this transitional period where you remove the hreflang


data, then you can track the usage of your site


in Search Console or in Analytics, for example,


and see if people are actually hitting


the right version of your site.


Because it might be, for example,


that you only need to use hreflang


on a limited number of pages rather than all pages.


So what I often see is that, especially when you're


using hreflang just to differentiate


between different language versions,


then that's something where maybe for the brand name,


it'll be hard for us to recognize which language


version to show for queries.


But especially when people are searching for long tail


content, specific pages within your website,


they'll be searching in ways that is easily recognizable


to be in one particular language.


And if we understand the user's language


and we understand you have pages in this language,


then we can just map them.


We don't need hreflang to match that better.


But for example, for home pages or maybe for category pages,


that's something where sometimes hreflang helps


us to figure out a little bit better what people mean when


they're just searching for a brand name.


I was working with a website person who made himself


an admin in Search Console.


And we're no longer working together or speaking.


But now I can't delete him from the console.


It's him and I that are both admins.


So I guess that's always an awkward situation, especially


if you're no longer speaking.


But in general, in Search Console,


there are two main ways that you can add people


as owners in Search Console.


On the one hand, you can do that by adding


a token for verification.


And that makes them the owner, essentially, of that site


as well.


Or you can also use delegation features


in Search Console, which means essentially you


have the site verified.


And you're just telling Search Console,


by the way, this other person also has access.


Depending on how you set that up,


that determines how you can revoke that access.


If it's done through delegation, you


can just remove that in Search Console.


And that'll essentially be picked up.


And then that user will no longer have access


to your site in Search Console.


On the other hand, if that access


was created through a token on your site,


so maybe a meta tag or verification file or DNS entry


or whatever, then you need to remove that token


from your website first.


Because otherwise, Search Console


will just be helpful and re-verify that owner


if you were to remove them from Search Console.


One way to figure out how that user is verified


is to go through Search Console into the Settings section.


There is a section, I think, for users and permissions.


And there you should see a list of the users


that you have there.


And next to the username, there's


a dot, dot, dot menu that you can click on


to manage the verified users.


And that takes you to yet another page


where you see the different verification methods that


were used for that site.


So that's where you can see which user has which type


of verification access.


And if there's a file involved, I


think it shows you the file name.


If there's a meta tag, it gives you the ID


that's shown in the meta tag.


And with that, you can go and remove that information


from your server, that token.


And then you can unverify that user


in Search Console in that place.


So that's a little bit more involved.


That's something where you kind of have to dig through


a little bit to find that.


But essentially, those are the two main ways


that you can remove someone from access in Search Console.


Usually, my recommendation is to use delegation


as much as possible because that makes it a lot easier for you


to add people.


You don't need to change anything on the server.


And it also makes it easier for you to remove access


once people move on.


We have many products that don't vary much in their details.


But these are genuinely different products


and therefore have their own URLs.


One of my considerations is that Google may perceive this


as a lot of thin content.


While this was still the case before our domain move


and our rankings we previously had were good,


my thoughts are that the loss of authority that


occurred during the domain move and still seems to exist


meant that Google no longer overlooks these issues


and treats us in a way similar to that of a new domain.


In effect, it's possibly seeing this as spammy,


therefore negatively impacting the whole domain's listings.


Is this likely to be a problem?


If so, how can I solve it?


Should I, for example, noindex the product pages,


use rel canonical on product pages


to their respective categories, or something else?


So I think I've seen your site a few times.


I took a look at your site with some folks,


I don't know, a couple of weeks back,


when I think you were in one of the Hangouts.


And from our point of view, we don't really


see anything holding the site back.


So it's not the case that there's


anything kind of problematic with the site per se,


in the sense that you'd have to do something


different than any other website.


From our point of view, we're trying


to rank this content the way that we would try


to rank it on any other website.


So it's not something specifically tied


to the domain move or the changes that you had there.


I think a lot of those fluctuations


that you had there with that domain move, which,


from what I recall, weren't that great,


in the sense that the redirects were kind of weird,


and I believe there's some JavaScript issues or something


initially.


I think, from our side, all of those details


are essentially resolved, and it's really just a matter


of us trying to figure out how to rank your content


appropriately.


And there's nothing different that you would have


to do than any other website.


So from that point of view, I would


treat this as any kind of situation


where you're creating a website and you


have different products.


And if you think these are unique products that people


would be searching for separately,


then keep them separately.


That's something where, if someone


is looking for something that really matches what you're


providing, then that feels like a good idea


to have a landing page for that and to have that product be


visible in search.


On the other hand, if there are ways


for you to reduce the number of pages


so that you can focus on fewer pages that are stronger,


then I think that's also a good idea.


So that's something where you kind of


have to balance those two sides.


On the one hand, having pages that are really well targeted


for individual queries, on the other hand,


having pages that are really strong.


And sometimes with a website that can evolve over time,


where you say, well, initially, maybe you


have fewer pages that are indexed,


and you try to make them as strong as possible,


and you try to build out your offering so that search


engines and users understand which parts of your site


are really important.


And it helps you to focus on those pieces of content


as well so that you can kind of create more pieces of content


in that style, all of that.


But that's not something where there's kind of like a yes


or no, like you always have to do it like this


or always have to do it like that.


You kind of have to find that balance yourself.


One thing that's kind of useful about this situation


is you can also test this, where if you


take a part of your website and say,


well, I'm not really sure if we should reduce the number


of pages that we have indexed or expand them,


you can take a part of your website


and have a more limited set there.


And you can have the other part of your website


with a more expanded set there.


And if the overall numbers are fairly comparable otherwise,


then you can pretty much see if by making one of those changes,


you're increasing the visibility of your content overall,


getting better targeted users, or if you're


going in the opposite direction.


And with that, you can kind of try


to refine things a little bit.


Is it OK to expand from narrow niche to a broad niche?


To me, it's normal.


But in different examples, I find bad results by Google


when doing it.


Is it because Google doesn't understand


the expansion or different approach by the webmaster


or an EAT issue?


So you can definitely go from a narrow niche to a broad niche.


You can go from a broad niche to a narrow niche.


You can expand your site or reduce it or focus


on more specific areas.


All of these are completely natural and normal changes


within a website.


And they happen with any business,


where you kind of evolve and change the products


and the services that you provide


to match what users are currently looking for.


And it's never the case that you figure out


what users are looking for.


And you can keep doing that forever.


You kind of have to continue to evolve this over time.


And usually what people do is kind of A-B testing


to figure out which of these variations works best,


sometimes expanding things, sometimes folding things


together.


So that's something where there's really


nothing special from Google's side that says you can't create


more pages of this type or you can't fold multiple pages


together into one page.


That's totally up to you, essentially.


My question isn't related to page rank.


I'm asking about URL discovery, site architecture.


We always keep our category pages as noindexfollow.


Is Google seeing our product URLs in those categories,


or are they completely 404 in Google's eyes?


So that's kind of hard to say without knowing your site.


So if the product pages do exist,


then we definitely don't see them as 404s.


If these are category pages and you're blocking them


from indexing, then we wouldn't be able to index those.


And over time, we would have trouble finding the links


that you have on those pages.


So that's something where if those products are only


linked from pages that are within this set of pages that


are noindex, then that's probably


going to be hard for us to understand


that those products are actually useful and important


for your site.


Your products can be linked in a variety of different ways,


though.


So they could be in multiple categories.


So maybe in one category page they're linked,


and another one they're not linked.


That's also fine.


It could be that your products are cross-linked


between each other so that you have


something like related products that you're linking together.


That's also generally fine.


They could be linked from your home page as well.


If you have your best sellers, then that's something.


We'd be able to find those products fairly well, too.


All of these are different ways to discover


these URLs on your website.


From our point of view, we currently


don't have any exact guidelines on how


to deal with category pages.


I think what we're probably going to evolve towards


is to say that for category pages in particular,


you should allow one set to be indexed.


So you pick one sorting order, for example,


and let that order, that set of category pages


be completely indexed.


And all of the alternate variations


of that with different filters or different sorting orders,


you'd probably want to set to no index.


So that would allow us to go through one set of category


pages and really find all products


that you have linked there and essentially go off and index


your product pages directly.


And if there are things in specific versions of category


pages that you find critical, where maybe a specific filter


set or a specific sorting order is very critical,


then maybe let that first page of that variation


be indexed as well.


But that's kind of the direction where we'd be headed.


I think, in general, just always setting all category pages


to no index and follow.


That's probably not a great strategy.


And that's one where I would recommend at least using


some kind of a local crawler tool


to double check that we can actually find


all of your category pages.


Because if we can't reach them with normal crawling,


then it's kind of hit and miss if we'd


be able to show them well in search anyway.


The Google News algorithm is now working as the old style


because my news trends on Google don't really


understand that question.


I think, in general, with Google News,


we've made a number of changes.


And that's something where things


will continue to evolve.


So I don't think there are any plans to say,


oh, all of these changes that we've


worked on for such a long time, we need to drop them all.


That's something where, if you have specific feedback


on specific kinds of queries or specific results in Google


News, that would be really useful to have.


And I think, in Google News, you can also


submit feedback directly.


So that's kind of the direction I would head there.


If this is specific to your site as a news publisher,


I would go to the Google News publisher forum


and kind of chat with the other publishers there.


OK, I think we kind of made it through the submitted


questions, so I'll just open it up


to more questions from you all, if there's


anything on your side.


SPEAKER 2 OK, John, I have one quick question.


I have noticed on the Google Webmaster forums,


and we have experienced it with some of our projects.


Sometimes we see that, for example,


for a very quick time, the home page is a little specific website.


Just go away from the index, and we don't see it on the results


with the site's comment.


It's the point the same for the Google Search Console,


but once we re-index it with the indexation request,


it appears back again.


Could you explain, please, why this happens?


And I know that the reason could be very different,


but the most common reasons you have observed, if you have.


I'd love to see some examples like that,


if you see that, because then I can double


check to see what is actually happening internally.


Usually, this kind of fluctuation,


especially with things like home pages, shouldn't be happening.


What might happen is if you do a site query,


that the home page is just not the first result.


That's completely normal.


From our point of view, a site query is an artificial query,


so there is no predetermined order where we'd say,


this is the order we should always give the results in.


So just because the home page isn't


the first one in the site query results, from my point of view,


wouldn't be a sign of any problem.


If the home page were not indexed at all,


that seems a little bit different.


That seems like something where it would be useful to look


at examples.


SPEAKER 2


Cool.


SPEAKER 3


OK, thank you.


Thank you.


Sure.


I have another question, John, if nobody else has one.


Sure, go for it.


I think confirm something first, hopefully.


I think you guys have always said,


when it comes to the speed of a site,


you're really only negative, directly,


from a ranking standpoint, directly impacting


the slowest of slow sites.


Is that just an SEO thing that we say,


or is that actually true?


And then I have a follow up to that.


I think, for the most part, that's still the case.


So that was essentially the, I don't know,


when we initially launched all of the speed


as a ranking factor things a number of years ago,


that was definitely the case where


we tried to differentiate between normal speed sites


and really slow sites.


I could imagine that over time, especially with mobile sites,


we might find a more granular approach.


But it's really still the case that if you're


tweaking milliseconds, then that's probably not


the best use of your time if you're only worried about SEO.


Yeah, just from an SEO perspective.


Because you and Martin did a video,


and the very first question, I think, was about speed.


And then Martin said something like,


I don't remember his exact words, but something


like, we only look at the really slow sites


and the really fast sites.


So he did include that other end of the spectrum.


So I don't know if that was just him saying


that you look at those things, or if you actually


boost sites that are on the 95th percentile,


or whatever it may be.


Yeah, I think it probably all comes to the same thing.


So if we reduce slow sites, then essentially we're


boosting faster sites.


It's kind of like, it's not, there's


no real difference between saying like, one set of sites


is ranking higher, and another set of sites is ranking lower.


It's like, you can't do one without the other.


So that's always kind of that two-sided thing.


OK, so maybe all things, I know you can never


say all things being equal, but a site that


was middle of the pack, and then a site that


was 95th percentile fast, the one that was faster


might rank above for that reason?


It is possible.


I think if you're talking about sites that are reasonably fast,


then probably you wouldn't see a big difference there.


But if it's something where there's really


a noticeable difference between those two,


then I would expect there to be some differences.


The tricky part, I think, with speed


is that there's so many different ways of measuring


speed.