Google Search News (Dec ‘21) - Google ranking algorithms updates, SEO quiz, and more!

Happy Holidays everyone and welcome back to the Google Search News. I hope life is treating


you reasonably well wherever you are. I'm your host today, John Mueller, here from Google


Switzerland. With this show, we want to give you a regular summary of what's been happening


around Google Search, specifically for website owners, publishers, and SEOs. If you find


it useful, which I hope you do, and if you'd like to stay up to date, make sure to subscribe


to the channel. How is it already the end of the year? Well, it's good to see you all


here again because I have some updates. Today, we'll look at Search Central documentation,


briefly cover search updates, look at options for a recent security issue, and more. So,


without further ado, let's jump right in. A year ago, we launched the new Google Search


Central site. It's a place where all search documentation for site owners comes together.


It covers everything from quality guidelines to structured data implementation details,


including tips for e-commerce and JavaScript-based websites. I think it's awesome, but it's also


run by my team, so I might have a slight bias. Anyway, we recently announced that we work


together with the Google SEO team on it. You might be surprised that we also do SEO, but


as I've said before, SEO is not a bad word. Among other things, we work to improve the


content, titles, descriptions, and internal linking to make our pages easier to find.


The Google SEO team is isolated from the search teams, so they also rely on our documentation


to learn about SEO. So, if you're wondering whether you should spend time on SEO, keep


in mind that even Google needs it. Additionally, the search documentation now includes a neat


interactive checklist, which helps you to quickly find relevant content for your situation.


Give it a try and let us know how it works for you. All our documentation has a feedback


link on the bottom, and we appreciate all submissions. I'll add a link in the description


below. Moving over to Search itself. We recently announced two bigger updates in


our ranking algorithms. First, there was the November core update. We call them core updates


because they affect the core of our systems and can result in changes across search and


discovery. Afterwards, we announced the December product


reviews update. This update aims to better promote high-quality product reviews. To give


you a sense of what we'd consider best practices, we have a blog post with updated documentation.


I'll add links to them in the description below. These updates came after mid-November.


It's hard to get the timing of updates like these right. Ultimately, our goal is to highlight


your amazing content as prominently as possible as soon as possible. These kind of updates


are also more about longer-term changes in search, so they tend not to be affected by


quick tweaks of websites. Because of this, I strongly recommend first taking a step back


and reading more about the updates. Wait to see how they actually affect your website,


and then consider whether there's something to improve or to change.


And now, over to a security update. There was recently a big security issue that affected


lots of online services and websites. This issue came from a popular component that's


used across countless systems. Because of the nature of security issues, it's critical


to fix them as quickly as possible or to isolate them so that they can't be exploited. Some


have chosen to take parts of their websites offline to prevent harm while the issue is


being resolved. Last spring, we talked about briefly closing a website. That's also relevant


here. Additionally, I wrote a bit about what you could do should you need to take your


website offline to fix an issue like this. When it comes to SEO, my recommendation is


to keep a static copy of the website online using the same URLs. A static copy allows


you to disable the server-side functionality without affecting the content shown. This


allows users to still find the bulk of your information and help search engines to keep


the website in their indexes. This won't work for all websites, and hopefully you've resolved


this particular issue in the meantime. Nonetheless, it's good to have this kind of setup in your


collection of tools should the need arise. And let's hope that's not all too often.


On a lighter note, the HTTP Archive Project recently launched their Web Almanac for 2021.


They analyzed a large part of the internet to determine the current state of things.


The SEO chapter is over 35 pages long and was written by a number of fantastic people


from the SEO community. It's a fascinating look into the state of websites with regards


to SEO and worth checking out. It's also a fun source of trivia. For example, did you


know that more home pages use H2 headings than H1 headings? I certainly didn't know.


And now over to some smaller updates. Google Search Console recently launched a new graphic


design. It looks really fancy and modern. If you haven't taken a look at Search Console


recently, go check it out. Also, we recently alerted websites of redirect errors in Search


Console. Unfortunately, most of these alerts were from a mistake on our side. If you received


this alert, I recommend checking a sample page with the Inspect URL tool. And if it


looks good, then you should be fine. We've added an annotation in the chart as well.


Sorry about that. On mobile-first indexing, we recently posted


an update. Mobile-first indexing is still ongoing. And because of issues that we've


seen on a small number of websites, we've decided to leave it without a final date for


now. We'll continue to inform sites of problems as needed.


And last but not least, if you're in the mood for a fun SEO quiz in the format of a web


story, I've added a link below. It's quick and easy and made together with folks from


the SEO community. And that's all for now, folks. Thanks for


sticking around until the end of the year with us. It's always useful to me to look


back and compile the highlights. I hope you found it useful and insightful as well. If


you have any feedback or comments, please send it our way in the comments here.


I hope the end of the year is a bit calmer for you all and that you're able to do some


things with family and friends nearby despite the situation.


Personally, I'm not always a big fan of the holidays. It seems to me that we should


work to make the whole year good, not just a few weeks at the end. Either way, I wish


you all a great end of year and a particularly fantastic next year.


If you subscribe here, I'm sure we'll meet again next year, perhaps in another episode


The latest in Google Search for site owners

Hi, I'm John Mueller, a search advocate from Google Switzerland.


Today, we're going to share the latest on Google Search,


focusing on new APIs to better understand your site in Google Search


and ways that you can diagnose indexing of embedded videos for Search.


This session is recommended for developers of websites


wanting to make the most out of the modern opportunities


in Google Search.


Before we start, let's take a step back.


Google Search is the reason we're here together in this session.


Did you know that over 15% of all queries submitted every day


on Google Search are completely new?


We've been tracking this metric for many years now,


and it's surprising to even those involved that it's been so stable.


My takeaway is that every day, people are looking for something new


and unique.


Every day, there are chances for new websites to be found.


It's not too late for you to get started.


However, if you're already working on websites,


that also means that even if your website is doing well now,


it's still worth monitoring how users find your site


and looking at ways to make your website even better.


And the opportunity is not just limited to new searches.


Year over year, Google has sent more and more traffic


to websites on the open web.


You can be a part of this too,


helping to make websites that are easily findable


and that get traffic through Google Search.


So let's dive right in.


Google Search Console is the primary tool from us


for understanding how a site is doing in Search.


It's available to all owners of websites.


It includes reports on the site's status,


its performance, and provides settings and diagnostics tools.


There's a lot already available on Search Console,


so we'll focus on just a small part.


There are links to more information in the description.


The most important part is verifying ownership of a website.


Without this, it's not possible to use Search Console.


We recommend verifying on the domain name level,


as it gives you the most options.


If you're making a website for others to use,


make it as easy as possible for them


to verify their websites.


There's an API for that.


If you're using an existing content management system


or building on a hosted platform,


this may already be implemented.


It can take a couple of days for data


to start appearing after verification.


This is why we recommend it as a early first step.


Are you verified?


All right, let's check out the new APIs.


The first API on our list is the Search Analytics API.


This maps to the performance report in Search Console


and gives you information


on how your pages performed in Search.


New in this API is support for Google Discover


and Google News.


This is interesting for developers


since you can find creative ways to display


and add value on top of the data.


For example, while Search Console interface


shows only 1000 rows,


you could potentially show more


or add a layer of advanced analysis and data visualization.


As an aside, note that Google Analytics


and Search Analytics in Search Console are different things.


Roughly speaking, Search Console and its APIs


cover everything in Google Search,


leading up to a user going to a website.


Google Analytics, on the other hand,


looks at everything that happens afterwards


once a user is on the website.


The measurements are slightly different too.


So while trends are often the same,


the exact numbers won't match.


With the Search Analytics API,


you can request information about clicks,


impressions, ranking position,


and search queries for the whole website or for parts of it.


The data is anonymized


according to Google's high internal standards


and can be safely stored on your end.


This allows you to create useful dashboards


within your websites for the content creators.


These dashboards help them to understand


the current situation and to work out ways to improve.


If you track the data over time,


you can also collect insights


over stable and periodic trends.


How might that look in practice?


Google Site Kit is an open source plugin for WordPress


that integrates the Search Analytics API among others.


At a glance, in the owner's dashboard,


it can show how traffic from search has developed over time


and use that to give you tips on how to improve.


Site Kit is now being used on over 2 million websites,


proof that people find the integration of data


in their CMS useful.


If you're using WordPress, I'd recommend giving it a shot.


If you're working on a CMS for others,


I'd recommend trying it out for inspiration.


It's open source, so you can also check out the code.


We're already working with a few platforms


to build similar tools for their users


with the same APIs as Site Kit,


and we're looking for even more CMS partners to join.


Please get in touch with us if you're interested.


For example, eCQ, an e-commerce platform from Japan,


has made use of the Search Analytics API


to create a custom plugin for their users.


The report shows clicks and impressions


plus average ranking for top keywords and pages.


The plugin now comes pre-installed


for new eCQ-based sites.


If you're looking for further inspiration


of how to make use of the search APIs,


we recommend taking a look at Search Console Insights.


This is an easy-to-use content analytics tool


tailored for smaller creators.


It provides an intuitive UI with insights such as


what are the most common search queries leading to the site.


This helps creators to track their content's performance


and inspire them with ideas for how they can improve.


And something users seem to appreciate a lot,


it motivates by celebrating achievements and progress.


The metrics are easy to fetch from the API,


so you too can add motivational milestones to your site.


Shifting gears, let's move on to the other new API,


the URL Inspection API.


With this new API, developers can check the indexing data


for a specific URL on their website.


This API maps to the URL inspection tool in Search Console,


which is shown here.


The API response includes, among other things,


the current indexing status, any structured data detected,


and its mobile usability status.


The index status includes whether the URL is known


to Google systems, if it's been crawled, indexed,


and what the canonical URL is.


For example, a page can have a declared preferred URL


or preferred canonical URL,


but sometimes Google won't choose it.


Through the API, you can test both URLs


and quickly check the difference.


This makes it possible to regularly check a critical sample


of your site's pages for their availability in search.


Keep in mind that Google doesn't guarantee indexing


of all pages.


That said, it's easier to check


for potential technical issues when you know


that some pages have dropped from indexing.


We've seen amazing integrations of this API


in the brief time it has been live so far.


Here's one example.


The Screaming Frog SEO Crawler is a tool that runs locally


and can crawl your website locally to analyze it,


giving you insight into how pages are currently linked.


This tool has integrated the URL inspection API


to make it easy to check a sample of your pages


for their indexing status,


allowing you to export it to a spreadsheet


for further analysis.


You could use the API in a similar way for manual checks


or implement it for automatic periodic checks


to catch issues early on.


Another neat implementation


is the Lost Google Impressions Index Check from Dave Smart.


This tool combines the search analytics tool


with the URL inspection API.


In short, it looks for pages that have seen a drop


in impressions in Search Console,


and then checks those with the URL inspection API


to display their status.


This is a neat way to combine the two APIs.


If you're building a website,


you could combine the APIs in a similar way


to automatically inform the operator of potential trouble


before it becomes a lasting problem.


And now over to Dick Love for a video segment on videos


in Search Console.


Thanks, John.


Hi, I'm Dick LaCoyne,


a web ecosystem consultant from Google London.


There's no arguing that video


is an important content format on the web.


It is therefore not surprising that more and more users


appreciate finding links to videos as answers in search.


With that, many websites want to highlight


not only their textual content,


but also their videos in the search results.


People often wonder how videos are indexed


and appear on search.


Google discovers videos on the web


just like any other webpage.


The first step is indexing the landing page


where the video appears.


Then, Google needs to recognize


that there's a video prominently located on the page.


Finally, Google needs to be able to extract key information


about the video, like thumbnail, title,


and other metadata like duration.


Sites can provide this easily


through structured data or other methods.


Worth noting that video indexing does not rely


on where and how you host your videos.


You can host them yourself


or use most of the popular video hosting platforms


and services.


To make video indexing easier to track and diagnose,


we will soon be launching a new set of reports and tools


in Search Console.


Let's take a quick look.


The Video Page Indexing report


will show a summary of all the index pages


our systems found with a video on them


while crawling and indexing your website.


At a glance, you'll be able to see


in how many video landing pages


a video was indexed or not indexed.


Recognized reasons are grouped with a trend line


and counts of the affected videos.


For example, which videos are missing a thumbnail URL?


Reasons with the largest impact are ranked on top.


Click on one of the rows to get more details,


such as affected video pages' URLs.


You will be able to download the list of examples


and double-check them.


With this, you could narrow down the details


and more easily understand what is happening


and how to resolve issues.


After updating the website,


when you're fairly confident that the issue is resolved,


you can go back to the Video Indexing report,


go to that specific issue type,


and use the Validate Fix button to inform Google.


This will initiate the recrawling of known URLs


affected by the issue, and as the pages are reprocessed,


you'll be notified if everything is resolved


or if there are remaining issues.


Note that it can take some time to go through all the URLs.


You can also check the Video Indexing status,


which John mentioned earlier.


To get there, just enter the URL of the video landing page


into the top of Search Console.


This will first show you the current status of that URL,


as well as the video indexing status of the page.


It will inform you whether we detect a video on the page


and if so, did we manage to index it.


If a detected video was not indexed,


it will list the reasons preventing the video from being indexed.


Please note that Google indexes only one video per page,


even if there are multiple videos on the page.


To summarize, with the new tools, you will be able to


see how many video landing pages Google discovered


and in how many of them it has.


And in how many of them a video was indexed.


Examine reasons for unindexed videos in video landing pages.


Use the list of affected video pages' URLs to debug and fix issues.


Validate fix to initiate recrawling of known URLs affected by the issue.


And check the video indexing status of a specific video


using the URL inspection tool.


I hope this helps streamline the publishing of videos on your site,


bringing you more users through search.


Alright, one last update.


Last year we mentioned the page experience ranking change.


The update included combining a set of signals


that measure how users experience a page.


We call them Core Web Vitals,


and they measure speed, interactivity, and stability.


There are other talks this I.O. that discuss Core Web Vitals in more detail,


and we recommend checking them out.


For the page experience update, we started off with mobile,


and just recently we rolled out the ranking change on desktop search as well.


We've been following along how sites have improved with these metrics,


and you can head to the page experience report on Search Console


to better understand how your site is doing.


We're excited to share that in Q4 2021 alone,


we saved our users over 1,000 years of time waiting for pages to load


due to the page experience program.


That's an amazing result, and a reminder that the web is both extremely popular


and that there's still a lot to achieve in making it truly fantastic.


We're looking forward to working together with you all


to continue to move the web forward.


And that's it for the updates from Google Search.


For more information about any of these topics,


check out the Search Central Developer Documentation.


If there's anything on your mind that you'd like to find out more about,


check out the Google Search Central Help Community.


In the forums there, you can meet like-minded folks


who can often help you by answering questions around websites and Google Search.


And if you'd like to stay in the loop with us,


make sure to subscribe to the Google Search Central YouTube channel.


English Google SEO office-hours from April 1, 2022

Thank you.


All right, welcome, everyone, to today's Google Search Central


SEO Office Hours Hangout.


My name is John Mueller.


I'm a search advocate here at Google in Switzerland.


And part of what we do are these Office Hour sessions


where people can jump in and ask their questions


around their websites.


And we can try to find some answers.


I have a bunch of things submitted


on YouTube, which we can go through.


But it also looks like we have a ton of people raising hands.


So let's get started there.


Let's see, Isabel, you're up first.


Hello, good morning, everybody.


My question is about the crawling of our website.


We have different number from the crawling of the search


console in our server log.


For instance, we have three times the number


of the crawling from Google in our server.


And in search console, we have one of the three bar.


Could be possible.


Maybe we have something wrong or we don't


even indicate the Google bot because the number


are different.


I think the numbers would always be different just because


of the way that the in search console,


we report on all crawls that go through the infrastructure


of Google bot.


But that also includes other types of requests.


So for example, I think the ad spot also


uses the Google bot infrastructure,


those kind of things.


And they have different user agents.


So if you look at your server logs


and only look at the Google bot user agent


that we use for web search, those numbers


will never match what we show in search console.


But we have more in our server log than in Google search


console.


OK, if you have more in your server logs, then to me,


that would sound like either you have multiple sites combined


in the server logs or you're also


counting requests by other people who


use the same user agent.


So the user agent isn't something


that is locked and only limited to Google bot.


Anyone can say, I am Google bot, but even if they're not,


Google bot.


So there is one way to double check


that with the IP address.


And I think we have that in our Help Center,


how to kind of double check that it's really a Google bot.


SPEAKER 2


OK.


Thank you.


SPEAKER 1


Hey, John.


I have a question in mind.


We have a website.


And from last three to four months,


we have been working on Google Web Stories.


It was going very well till last month, fifth of March, actually.


We were having some around 400 to 500 real-time users coming


from Google Discover on our Web Stories.


But suddenly, we saw an instant drop in our visitors


from Google Discover.


And our search console is not even showing any errors.


What could be possible reason for that?


I don't think there needs to be any specific reason for that.


Because especially with Discover,


it's something that we would consider


to be additional traffic to a website.


And it's something that can change very quickly.


And anecdotally, I've seen that from, or I've


heard that from sites in these office hours,


that sometimes they get a lot of traffic from Discover.


And then suddenly, it goes away.


And then it comes back again.


So it doesn't necessarily mean that you're doing anything


technically wrong.


It might just be that in Discover,


things have slightly changed.


And then suddenly, you get more traffic.


Or suddenly, you get less traffic.


We do have a bunch of policies that


apply to content that we show in Google Discover.


And I would double check those just


to make sure that you're not accidentally touching


on any of those areas.


That includes things, I don't know, offhand.


But I think something around the lines of click-baity content,


for example, those kind of things.


But I would double check those guidelines


to make sure that you're all in line there.


But even if everything is in line with the guidelines,


it can be that suddenly, you get a lot of traffic from Discover.


And then suddenly, you get a lot less traffic.


SPEAKER 2


We had really changing part of our content or what we call,


we didn't try anything new over there.


Everything was as we had done before.


But we saw an instant drop.


Yeah.


Not even that it was less and less.


Instantly, there were no visitors.


And anecdotally, that's what I hear from people,


that it goes from you get a lot of traffic


and then suddenly goes to almost nothing.


OK.


Sorry, I don't have any kind of better tip in that regard.


I think Discover is something that is worthwhile trying out


and seeing what you can do there.


But it is something, because of its nature,


it's not tied to specific people searching.


So it's a lot harder to work on it


and have it in a persistent state.


Cool.


Ritu.


Hello, John.


Hi.


I'm not hearing you.


I cannot hear you so well.


But maybe it will get better.


Now I'm audible?


A little bit, yeah.


So I have a question related to old domain


to like when we redirect an old domain to new domain.


And this time, like for the backlinks,


the backlinks we are creating for the old domain,


is there, they are auditable.


Like when we audit, when we say, when it will redirect


to new domain, after that, if we'll audit the old domain


backlinks which we created for old domain,


that will be auditable?


I think they would show in Search Console.


I mean, in Search Console, you would


see a sample of the links to the old domain.


A sample of the links to your website.


And if they redirect through another domain,


then I think we would still show that in Search Console.


Sometimes I think we show that in between states,


that it's like you have a link through this other website.


OK.


In the option like link.


But after the direction is associated,


then we redirect to a new domain.


Like we can view for the old domain also.


Sure.


No.


I mean, sometimes sites change domains.


I would not recommend doing that regularly.


I think every domain move that you make,


it brings challenges and possible problems.


But if you need to change your domain name, that happens.


So one more question, my website, some spammy website


are regularly copying our content.


Like spammy, which have very low domain authority,


that type of websites are copied with the blog content.


So we are doing like a manual for de-listing


those URLs from Google and CRT.


We are just manually submitting the request to Google.


By the form, after that, our URLs


are de-listing from Google and CRT.


But is it the right way to get from these type of activities?


Or we can go for an alternate option for this.


Further, we will not use this type of spammy activities


on our website.


How do you mean alternate?


How do you mean alternate process?


Very spammy, like this is having low authority, toxic backlinks.


We are getting so many toxic backlinks.


Most of the websites are copying our content.


Our whole content is copying on our website.


And then we are de-listing them from Google and CRT.


We are submitting the request to Google.


Then they are manually removing this domain from Google and CRT.


So is it the effective way to get


rid from these type of activities?


Or we can go for any other alternate option or any free


option that is available?


So I think if another site is copying


your copyrighted content, then probably the DMCA form,


I think that you're using is the right way to go there.


Actually, yeah, we have taken the plan also earlier.


It's for a limited time because our plan


is very specific for it.


So that's why we are thinking we should


de-list the URLs manually.


So we are thinking if we get any other option for this.


Is there a premium plans?


I don't think we have any kind of paid plans or anything


like that.


So the DMCA process, if that applies to your case,


that should be something that is available for free.


You can just use it directly in Search Console,


or I don't know, wherever the form is.


So that might be one approach.


The DMCA process is a legal process.


And I can't give you legal advice.


So you might have to check with a lawyer


to see if it's appropriate.


The other thing that you could do if you wanted to


is to use the Disavow Backlinks tool if you're


worried about those links.


For the most part, if it's a random spammy site,


I would not worry about it.


I would not use the Disavow Backlinks tool


because it's just extra work.


SPEAKER 2 There will be no effect of toxic backlinks


on our website.


JOHN MUELLER 1 No, I can't imagine.


No.


SPEAKER 2 That's a wonderful thing.


A website is going through migration process.


So we have followed checklists which


we should consider before migration process.


And we followed, and we worked on it.


And the speed of it, we are worried about that.


Certainly, we will get a traffic loss for the website.


Is there any chances we'll get a traffic loss?


The website will have a traffic loss in small amount or like?


JOHN MUELLER 1 It's always possible.


So with migrations, when you're moving from one domain


to another, there's always a period


of fluctuation in between.


And usually, if you're following the guides that we have,


then it's a minimal fluctuation.


But it can still happen.


SPEAKER 2 Is it enough to have the checklist we are following


like which are available in search


in the land for the container?


Is it enough for it to get rid from traffic loss,


like minimal amount of traffic loss to please?


But enough for it or we should go?


JOHN MUELLER 1 We have a checklist


in the search developer documentation for site moves.


And I would double check that.


SPEAKER 2 Thank you so much, sir.


Are you on?


John, I'm sorry to interrupt.


Can I offer Ritu another suggestion here about the DMCA?


And much like you, I'm not offering legal advice.


But there is another path, another remedy


that you can take, which is you can find out who the host is.


There's a site that I believe is called whoishostingthis.com.


You can find who the host is.


And they generally have a department


that you can reach out to with an email address,


such as legal at whatever the name is or abuse at.


They have these departments.


And you can reach out to them and say


that someone is infringing on your content,


but you need to give them backup documentation.


And generally, they will not ignore this.


There's an area of law called Safe Harbor,


in which that means that hosts can't moderate everything


that they're hosting.


But if they're told enough times about infringements


and you give them legitimate documentation,


they're almost bound to take it down.


The problem is that sometimes becomes


a game of whack-a-mole, where people change hosts.


But it takes time.


And eventually, these people, if they


are infringing on your content, they'll give up


and they'll stop doing it.


So thank you so much for your response.


Can you share the link with the on-check box for this?


Like, which you create?


It would be good.


Cool.


Yeah.


That definitely also makes sense.


Let's see.


Joseph.


Yes, hello, John.


Hi.


We have a content publishing website since 2009.


And we experienced a bad migration


in 2020, where we encountered a huge drop in organic traffic.


So the question here is that we had a lot of broken links.


So we used the 301 redirect to redirect these broken links


to the original articles.


But what we did in robots.txt, we


disallowed these links so that the crawling budget won't


be gone on crawling these 404 pages.


So the main thing here, if we fix all these redirects,


if we redirect it to the same article with the proper name,


can we remove these links from the robots.txt?


And how much time does it take to actually be


considered by Google?


So if the page is blocked in the robots.txt,


we wouldn't be able to see the redirect.


So if you set up a redirect, you would


need to remove that block in the robots.txt.


With regards to the time that takes,


there is no specific time, because we don't crawl


all pages with the same speed.


So some pages we may pick up within a few hours.


And other pages might take several months to be recrawled.


So that's, I think, kind of tricky.


The other thing I think worth mentioning here


is if this is from a migration that is two years back now,


then I don't think you would get much value out


of just making those 404 links kind of show content now.


I can't imagine that that would be the reason why


the website would be getting significantly less traffic,


mostly because it's, I mean, unless these pages are


the most important pages of your website.


But then you would have noticed that.


But if these are just generic pages on a bigger website,


then I can't imagine that the overall traffic to a website


would drop, because they were no longer available.


SPEAKER 2 OK.


Another question about the optimal content length


on a page.


You know we have encountered many blog posts that talk


about, let's say we need to have around 100 or 1,000 words


per page.


So what's the optimal content length?


JOHN MUELLER I don't think there is one.


Some pages are very short.


Some pages are very long.


It kind of depends on the amount of information


that you want to give users.


SPEAKER 2 There is this term propagating now,


the thin content.


Is it applicable by Google or not?


JOHN MUELLER Usually that applies more


to the overall website.


So it's not so much that one page


doesn't have enough content.


It's more that the website overall is


very light on actual information.


So I wouldn't use the word count as a way


to recognize that.


I think sometimes the word count is useful for you


to look at a larger website overall


and to try to find areas where maybe you


could be doing better.


But I wouldn't use it as a metric


to guide the specific things that you do on the website.


SPEAKER 2 OK.


OK, thank you so much.


JOHN MUELLER Sure.


Rob.


SPEAKER 3 Hi, John, thanks for the time.


My question pertains to a crawling question pertaining


to discovered not indexed.


We run a two-sided marketplace since 2013


that's fairly well established.


We have about 70,000 pages, and about 70% of those


are generally in the index.


And then there's kind of this budget


that crawls the new pages that get created.


And we see movement on that so that old pages go out


and new pages come on.


At the same time, we're also writing blog entries


from our editorial team.


And to get those to the top of the queue,


we always use this request indexing on those


so they'll go quicker.


We add them to the site map as well,


but we find that we write them and then


we want them to get on to Google as quick as possible.


As we've been growing over the last year


and we have more content on our site,


we've seen that that sometimes doesn't work as well


for the new blog entries.


And they also sit in this discovered not


indexed queue for a longer time.


Is there anything we can do to like internal links


or something?


Is it content-based, or do we just


have to live with the fact that some of our blogs


might not make it into the index?


Yeah, I think overall, it's kind of normal


that we don't index everything on a website.


So that can happen to kind of the entries


you have on the site and also the blog posts on the site.


It's not tied to specific kind of content.


I think using the inspect URL tool to submit them


to indexing is fine.


It definitely doesn't cause any problems.


But I would also try to find ways


to make those pages kind of as clear as possible


that you care about them.


So essentially, with internal linking


is a good way to do that, to really make sure


that from your home page, you're saying,


here are the five new blog posts.


And you link to them directly so that it's easy for Googlebot


when we crawl and index your home page to see,


oh, there's something new, and it's linked from the home page.


So maybe it's important.


Maybe we should go off and look at it.


OK, so if it's linked from the home page,


it's more likely that Google sees it as important


than if we just add it, and it kind of gets


added on a subblog page.


Yeah, definitely.


OK, that helps.


Yeah, thank you.


Making it as obvious as possible for us to figure out.


OK, to see that.


There's also, usually, if you have a blog section


on your site, you also have RSS feeds.


And if you have that set up, I would also submit those


to Google and in Search Console, just


because RSS feeds tend to focus more on the newer content.


And that kind of helps us to pick those up


a little bit faster.


So we use them similar to sitemap files,


but sometimes RSS feeds are a bit easier for us to pick up.


OK, that's a good hint.


I can implement that on the Google Search Console site.


Cool.


Cool, thanks for your time.


Sure.


Rohan.


All right.


Hey, John, thank you so much for taking on the questionnaire.


So I'm one of the moderators at Reddit.


And ever since GPT-3-based AI writing tools


started to get advertised, our community


is having a debate over whether or not to use them.


Although our stance is mostly against it,


but we are trying, or maybe I should


say we are struggling to see what is Google's official


position on the same.


Someone had posted on Reddit if they


should be using these AI content writing tools, to which you


responded no, but you had no further explanation to it.


And then you had also posted some cryptic tweets about it.


So I'm just trying to understand more


that how does Google react to websites


hosting AI-written content?


And what is your suggestion for all of us?


Yeah, so for us, these would essentially


still fall into the category of automatically generated


content, which is something that we've


had in the Webmaster Guidelines since almost the beginning,


I think.


And people have been automatically generating


content, and we're trying to figure out


automatically generating content in lots of different ways.


And for us, if you're using machine learning tools


to generate your content, it's essentially the same


as if you're just shuffling words around, or looking up


synonyms, or doing the translation tricks


that people used to do, those kind of things.


My suspicion is that maybe the quality of content


is a little bit better than the really old-school tools,


but for us, it's still automatically generated content.


And that means for us, it's still


against the Webmaster Guidelines.


So we would consider that to be spam.


So that's-


Just a quick follow-up on that.


Are you saying that Google is able to understand


the difference between human and AI content?


I can't claim that.


But I mean, for us, if we see that something is automatically


generated, then the web spam team can definitely


take action on that.


And I don't know how the future will evolve there,


but I imagine, like with any of these other technologies,


there will be a little bit of a cat and mouse game,


where sometimes people do something,


and they get away with it, and then the web spam team catches


up and solves that issue on a broader scale.


But from our recommendation, we still


see it as automatically generated content.


I think, I don't know, over time,


maybe this is something that will evolve in that it will


become more of a tool for people,


kind of like you would use machine translation as a basis


for creating a translated version of a website,


but you still essentially work through it manually.


And maybe over time, these AI tools


will evolve in that direction that you use them


to be more efficient in your writing,


or to make sure that you're writing in a proper way,


kind of like the distilling and the grammar checking tools,


which are also based on machine learning.


But I don't know what the future brings there.


SPEAKER 2


I mean, currently, it's all against the Webmaster


guidelines.


So from our point of view, if we were


to run across something like that,


if the Web Fan team were to see it, they would see it as spam.


SPEAKER 3


Thank you so much.


All right, Viola.


SPEAKER 4


Yes, good morning.


I would like to ask you, does using an HTML tag,


such as pan or class, into an H1 can affect my website


from a SEO point of view?


I don't think so.


I mean, my understanding is that we would still


see that as a heading.


And as long as it's a valid heading,


we would be able to use that.


I don't know from a technically valid HTML point of view


if that's still the correct way to do a heading.


But from our point of view, we would probably


just see that as a heading.


So it's not a problem if I want to make animation for my H1.


I use the span class because we think


that our website go down in the ranking for this reason


and others, reality.


So I don't know.


Maybe it's better to have a clean H1


without anything inside.


SPEAKER 3


I think.


I can't imagine that a website would drop invisibility because


of that.


SPEAKER 4


OK.


And my second question is, does a low-raising mobile results


on Google page speed, like LCP, FID,


might have affected our website rank


after the introduction of the new algorithm last summer?


Because we were like the fourth around my city, OK,


if I check a web agency or a keyword that we.


So after the introduction of this algorithm


and going on Google Search Console,


we find out that these parameters like LCP,


FID for mobile has a bad rating like 48.


Not for desktop, but it's 90.


So it's OK.


So it could be the problem of our.


SPEAKER 3


Could be.


It's hard to say just based on that.


So I think there's maybe two things to watch out for.


The number that you gave me sounds like the page speed


insight score that is generated, I think, on desktop and mobile.


Kind of that number from 0 to 100, I think.


SPEAKER 4


Yeah.


We don't use that in search for the rankings.


We use the Core Web Vitals, where there is LCP, FID,


and COS, I think.


And those are based on, or the metrics that we use


are based on what users actually see.


So if you go into Search Console,


there's the Core Web Vitals report.


And that should show you those numbers


if it's within good or bad, kind of in those ranges.


But if I go on Google Search Console on Core Web Vitals,


it said to me that the data from the last 90 days


are not enough for this type of device.


OK.


Then in that case, it's not due to that.


So we have to have enough data that we can collect from users


to be able to understand the status of the Core Web


Vitals for the site.


But especially for smaller sites,


we might not have enough data.


And then we would not use that as a factor there.


So even if the page speed insight score is bad,


that isn't something that we would use.


We would only use it if we really


have data from users that tell us that it's actually


slow in practice.


So I would use that score as a way


to kind of prepare for when you have more traffic


and have those numbers.


But it wouldn't be the reason why your website would drop.


OK.


So we have to find the reason.


It's another way.


I understand.


Thank you very much.


Cool.


Sure.


Let me go through some of the submitted questions.


And I have more time afterwards to go


through all of the people with the raised hands as well here.


So stick around.


Let's see.


The first question I have here is,


does it make a difference if a navigational link is


visible on desktop but hidden on mobile?


Can eventually non-visible navigational links


be considered less relevant as visible ones?


So I suspect by hidden on mobile,


it means it's not removed on mobile, but rather just not


visible directly.


And as long as the link is within the HTML of the page,


for us, that's fine.


For crawling, we can still pass signals to those links.


All of that is fine.


If, on the other hand, the link is not even


in the HTML on mobile and we crawl the site


with mobile-first indexing, then we


would not see that link at all.


So that's, I think, the important distinction


to think about there.


You can check this in Search Console with the Inspect URL


tool to try to fetch that page and to see if, in the HTML,


the link is actually still there.


If the link is there, then that should be fine.


We have some shortcuts on our website.


So these are some German shortcuts like IDR or UA


or ZBSP.


Oh, it's so awkward to read these German shortcuts


in English.


Is this readable for Google, or should we


avoid shortcuts on our website?


So from a practical point of view,


if this is something that you're trying to rank for,


then I would make it as clear as possible


what you're trying to rank for.


But these are essentially just shortcuts


that you would use in writing on a normal page.


And the content that you want to rank for


is essentially not the shortcuts, but kind of like


what's around the shortcuts.


And from that point of view, I would not worry about this.


If this is normal language usage, then it is what it is.


It is what users expect.


They can read it.


They can understand it.


And that's essentially fine from our point of view.


We're seeing competitors showing up in search results


with aggregate rating and high-priced, low-priced, rich


results used on e-commerce product category pages.


Based on the documentation, it looks like this is not


an approved use case.


So I wanted to check and verify if I'm understanding


the documentation correctly and if this is something that we


should be working on as well.


Yeah, and unfortunately, not everyone implements things


the way that we have it documented,


whether that's on purpose that they're doing things in ways


that we don't want them to do or whether it's accidentally just


implemented incorrectly.


It's sometimes hard to tell.


But if you're looking at the documentation


and it's clear to you how you should be doing it,


then I would try to do it that way and not kind of the way


that we say not to use it.


So especially for category pages,


I think our guidance is still that you should not


be using this kind of structured data


there because it's not the same product.


It's a bunch of different products.


So I would try to avoid that.


We recently started a chat tool as a help service.


The button is a small bubble in the bottom left corner


on mobile.


It covers a bit of content because the bubble


is an overlay.


Will we have a ranking problem because of a usability problem?


Should we have an additional Close button?


The bubble is visible on all pages,


also when users change pages.


So I don't know about the usability side.


I can't really give you advice there.


But with regards to kind of search's general ranking


guidelines there, I think there are two aspects that


could come into play.


And it's something where you probably


have to make a judgment call on your side.


On the one hand, there is the intrusive interstitial


guidelines that we have, where if you


have an interstitial on your pages that


is intrusive for users, then that's something


that we would recommend avoiding.


That's a part of the page experience ranking factor.


And it's something where we don't


have a fixed number of pixels or anything like that.


Which we would say would be intrusive.


And my guess is if you have a chat bubble in the corner,


then that would not be considered


intrusive by your users.


The other aspect is around the Core Web Vitals.


So in particular, I think the LCP and maybe the content


layout shift.


So the time it takes to load the page


and if the content shifts around while that page is loading.


Depending on how you have implemented this chat bubble


in the corner, that might be something


that would be playing a role.


And that's something which probably you


can test, where you turn that on and off


and you try it out in your browser


to see what is the effect there.


The effect that you see in your browser


is a different effect than users might see,


but it gives you a bit of guidance.


So in particular, for Core Web Vitals,


we use the metrics that users see,


which we call field data in the Chrome User Experience Report.


And if you test it yourself, we would


consider that to be lab data, which


might be slightly different than what an average user would see.


Primarily, this is due to maybe the different connections


that users have or different devices, the capabilities, how


fast they are, how much RAM they have, those kind of differences.


But usually, if you turn it on and off,


you will quickly see, is there an actual difference or not?


And if there is indifference, then you


have to make a judgment call.


Is this something I want to worry about or not?


Or maybe it's something that you just track for a while


to double check.


So those are the two primary things that come into play.


Another one that we've seen in the past, which


is kind of a weird edge case, specifically


around these chat things that sometimes run


with JavaScript in the corner, is that oftentimes they


will use the page title as a way to signal that actually there's


a chat message waiting for you.


It'll add something like a 1 to the page title


if some chat operator is waiting for you to kind of chat


with them, essentially.


And if you use JavaScript to change the page title,


then that is something that we could pick up


when we render the page.


And we have seen cases where suddenly all pages of a website


have a 1 attached to the title, which comes


from one of these chat tools.


So that's something to watch out for and maybe turn off


if you have a chance to kind of adjust that there.


Let's see.


In Search Console, we have search appearance filter


that shows AMP articles that appear in search.


That's all fine.


But the URLs that appear under AMP article filter


are non-AMP URLs.


The Search Console show the canonical for those URLs,


or is this a reporting issue?


So in general, in Search Console,


we do try to show the canonical URLs in the performance report.


It's not 100% perfect because there are certain kinds of URLs


that we report on slightly differently.


But we do try to show, for the most part, the canonical URL.


So I would not be surprised if you


see the canonical URL in the general performance


report on AMP.


I believe there's also a separate AMP report, which


you can double check.


But I'm not sure if that's there or not.


I don't know.


Confused right now.


But that might also be one place to check.


But in any case, I would not see that as kind


of an issue on your side.


If we're showing the canonical URLs there,


that's kind of the way we wanted to do that in Search Console.


And again, it's not 100% consistent


because some types of search appearances,


we show the way that we show them.


Sometimes they also include the hash in the URL


if we're kind of including a link


to a specific section of a page.


So it's, I would say, to a large part canonical,


but not 100% sure.


Let's see, question about crawling.


I recently redesigned my website and changed


the way I list my blog posts and other pages from pages 1, 2,


3, 4 to a View More button.


Can Google still crawl the ones that are not


shown on the main blog page?


What is the best practice?


If not, let's say those pages are not important when


it comes to search and traffic.


Would the whole site as a whole be


affected when it comes to how relevant it


is for the topic for Google?


So on the one hand, it depends a bit


on how you have that implemented.


The View More button could be implemented


as a button that does something with JavaScript.


And those kind of buttons, we would not


be able to crawl through and actually see more content


there.


On the other hand, you could also


implement a View More button essentially


as a link to kind of page 2 of those results,


or from page 2 to page 3.


And if it's implemented as a link,


we would follow it as a link, even


if it doesn't have a label that says page 2 on it.


So that's, I think, the first thing to double check.


Is it actually something that can be crawled or not?


And with regards to if it can't be crawled,


then usually what would happen here


is we would focus primarily on the blog posts that


would be linked directly from those pages.


And I mean, it's something where we probably


would keep the old blog posts in our index


because we've seen them and indexed them at some point.


But we will probably focus on the ones that are currently


there.


One way you can help to mitigate this


is if you cross-link your blog posts as well.


So sometimes that is done with category pages or kind


of these tag pages that people add.


Sometimes blogs have a mechanism for linking


to related blog posts.


And all of those kind of mechanisms


add more internal linking to a site.


And that make it possible that even if we initially just


see the first page of the results from your blog,


we would still be able to crawl to the rest of your website.


And one way you can double check this is to use a local crawler.


There are various third-party crawling tools available.


And if you crawl your website and you see that, oh, it only


picks up five blog posts, then probably those


are the five blog posts that are findable.


On the other hand, if it goes through those five blog posts


and then finds a bunch more and a bunch more,


then you can be pretty sure that Googlebot


will be able to crawl the rest of the site as well.


To what degree does Google honor the robots.txt?


I'm working on a new version of my website that's currently


blocked with robots.file.


And I intend to use robots.txt to block


indexing of some URLs that are important for usability


but not for search engines.


So I want to understand if that's OK.


That's perfectly fine.


So when we recognize disallow entries in a robots.txt file,


we will absolutely follow those.


The only kind of situation I've seen where that did not work


is where we were not able to process the robots.txt file


properly.


But if we can process the robots.txt file properly,


if it's properly formatted, then we


will absolutely stick to that when it comes to crawling.


Another caveat there is usually we


update the robots.txt files maybe once a day,


depending on the website.


So if you change your robots.txt file now,


it might take a day until it takes effect.


With regards to blocking, crawling,


so you mentioned blocking indexing.


But essentially, robots.txt file would block crawling.


So if you blocked crawling of pages


that are important for usability but not for search engines,


usually that's fine.


What would happen or could happen


is that we would index the URL without the content.


So if you do a site query for those specific URLs,


you would still see it.


But if the content is on your crawlable pages,


then for any normal query that people


do when they search for a specific term on your pages,


we will be able to focus on the pages that are actually


indexed and crawled and show those in the search results.


So from that point of view, that's all fine.


Let's see.


For example, fireworks is one of the products and services


that Google considers dangerous and that you should avoid


in your ads and destinations.


Do such terms also affect the ranking of business websites


that legally offers such products?


So from a Google search point of view,


I'm not aware of a list of products


that we would consider to be problematic.


I do believe on the Google Ad side,


there are certain products where the ads team, for whatever


policy reason, doesn't want to allow advertising for.


But that's completely separate from Google Search.


And at least from what I'm aware of,


if you mention these things on your website,


they can appear in the normal search results.


There's nothing really blocking that.


And you definitely see that if you just


try to search for fireworks.


You will find sites that sell you fireworks.


Let's see.


We're about to launch a new e-commerce site,


and we're debating on how many pages we should initially


go live with.


Since it's a new domain, I'm worried a bit


that Google will only index a small portion of the website


at first.


What would be the best approach here?


So I think we have this covered in our e-commerce


documentation, actually.


We looked at this with a variety of teams,


and I think everyone had a different idea of which


approach to take.


And I think we have maybe three options or so covered


in the documentation.


So I would double check that.


It depends a little bit on what you want to achieve


and how that should happen.


Also, with regards to e-commerce sites,


if you're trying to get these products into Google Merchant


Center for Google Shopping, I think it's so-called Google


Shopping, then you might have different considerations


than if you're just launching a website on its own.


But the documentation that we have for e-commerce sites,


I would definitely check that out.


Let's see.


There's just one question I want to grab quickly


before I switch over to you folks again,


because you're so patient.


Thank you.


And it's a long question, but I'll just take the first part


to make it a bit easier.


And so it's a food blogger, and the first question


is Google said that there's a maximum of 16 words


that you can use in your alt text.


And the question is, does Google read the rest of my alt text?


And what does this mean for usability?


And I think the important part here


is we don't have any guidelines with regards


to how long your alt text can be.


So from a Google search point of view,


you can put a lot of things in the alt text for an image


if that's relevant for that particular image.


When it comes to the alt text, we primarily


use that to better understand the image.


So if someone is searching for, I don't know,


in Google Images for something that kind of matches


the alt text, then we can use that to understand


that your image is relevant for that alt text


on that specific page.


That's kind of the primary use case of the alt text.


We do also use the alt text as a part of the page.


But to me, that's usually something


that is already visible on the page anyway,


so it's less something that is critical to the page itself.


So I would really use it as something


that applies to the image.


And I would use it for usability reasons and for Google Images


to better understand that specific image.


And I think what might also be worth mentioning


is when it comes to Google Images,


you don't necessarily need to describe exactly what is


in the image, but rather kind of like what this image means


for your particular page.


So if you have a picture of a beach,


you could use an alt text and say, oh, this is a beach.


But you could also say, this is the beach


in front of our hotel.


Or this is the beach that we took a photo of when we


were doing a chemical cleanup.


And kind of those intents are very different.


And people would be searching in different ways in Google Images


to find more information there.


And kind of giving that extra context


always makes sense, in my opinion.


OK, lots of questions left.


I'll try to add some comments as replies there as well.


But maybe we'll switch over to some live questions.


And I have a bit more time afterwards, too,


if any of you want to stick around.


Let's see.


Shun, I think you're up next.


Hi, John, I have a question that will be a little bit similar to the one you said earlier, but it's regarding HTML and JavaScript, the classic one.


Let's say I have an HTML with some parts which is hidden by CSS, just right now.


And when a user first land on a page that is hidden for some reason, UI reason to simplify the UI.


And that hidden contents can be only seen when a user click the button, and then JavaScript runs.


The JavaScript click event runs, and JavaScript change the status of the CSS.


And then a user see the contents.


So my question is, it looks a little bit crazy for me, because since the Google can never run any JavaScript event.


So I wonder if the contents which is hidden by CSS when a user first land on a page can be the target of the Google evaluation or not.


It can still be indexed.


So that's something.


If it's in the HTML itself, in the DOM, when the page is loaded, then we can use that for indexing.


If it's something that needs a JavaScript event to then fetch something from the server


and then display that, then that's not something that we would recognize.


But if it's in the DOM, if it's in the HTML, and it just goes from being hidden to visible, that's perfectly fine.


OK, so is the variation would be the same as the one that is not hidden?


Or?


Probably.


I mean, it's always hard to compare how things will rank in the end.


But my assumption is that it would be pretty much the same.


I think it's also something from a user point of view you might want to watch out for.


And that's more kind of like when someone goes to your web page after it's being shown in search.


And that is essentially that if you're promising the user something,


it's a good idea to show the user that when they go to your web page.


So we apply that when it comes to things like intrusive interstitials or too many ads on a page.


If they go to your page, they should be able to find what they were looking for.


And if this is additional content that you're providing,


which is not the primary reason why they're going to your page, then that's fine.


That's kind of like a usability way to give more functionality to a page.


However, if the primary content is blocked like this,


then that's something where I would expect the users to be a little bit unhappy


if they go there and they don't realize, oh, this is how I get that piece of information.


OK, so what would the case that only when we see the contents to the user from the PC


and never can see in the contents from the smartphone?


Actually, the element itself is embedded on HTML, but hidden.


And the user can never have a chance to undo the hidden.


I don't think we would separate that out.


Because sometimes that's also just a usability mechanism that sites use,


where you have essentially a responsive design.


And within the responsive design setup for certain screen sizes,


you hide something like the sidebar, and from our point of view, that's fine.


OK, thank you.


Sure.


Cool, OK.


Joy.


I have two questions.


I hope we won't take up so much time.


So the first is, does a portion of content


It's really hard to hear you.


Sorry.


Can you perhaps speak closer to your microphone?


Is that better?


Yes, perfect.


Sorry about that.


I have two questions that I hope won't take too much time.


So does the portion of content created by a publisher matter?


And I mean that in the sense of affiliate, or maybe even sponsored content.


Context is, there's a Digiday newsletter that went out today


that mentioned that publishers were concerned that if you have,


let's say, 40% of your traffic or content as commerce or affiliate,


your website will become or considered by Google a deals website.


And then your authority may be dinged a little bit.


Is there such a thing that's happening in the ranking systems


algorithmically?


I don't think we would have any threshold like that.


Partially because it's really hard to determine a threshold like that.


You can't, for example, just take the number of pages


and say, this is this type of website because it has 50% pages


like that.


Because the pages can be visible in very different ways.


Sometimes you have a lot of pages that nobody sees.


And it wouldn't make sense to judge a website based on something


that essentially doesn't get shown to users.


And I guess this may be like a part B to that.


How much does it matter if a publisher is outsourcing content


for scalability reasons versus having content created


by staff or staff writers?


I don't think for the most part that we would differentiate.


It's more about the quality of the content overall.


So that's something where if you outsource the content


and then you get good content back,


then you publish that good content.


So from that point of view, I wouldn't


say that outsourced content versus in-house content


is kind of different by definition


when it comes to the overall quality.


How would you even know?


I don't know.


Yeah.


I think there are ways that Google would pick that up,


especially if you label that.


I think that's pretty easy to pick up.


I contest that.


You're talking about Google understanding an employment


contract at that point.


I've got a staff member sitting in my office full time


or one sitting at home being paid by the end of the day.


One sitting at home being paid by the hour.


I don't see how you'd ever know who'd written anything.


Could be wrong.


I have been before.


I don't think, yeah.


I mean, it would be different if you're aggregating content


from other sites.


That's something which we could pick up on.


But if it's really just someone in-house or someone


from an agency writing the content for you,


it's the content that you're publishing.


Thank you.


Appreciate it.


Cool.


OK.


Let me take a break here and pause the recording.


It's been good having you all here.


Thank you all for joining.


Thanks for submitting so many questions.


I have a bit more time afterwards


so we can go through the millions of people


with raised hands as well.


And we can see what we end up with.


Thanks for joining.


If you're watching this on YouTube,


you're welcome to join one of the next Office Hour Hangouts.


We do these about weekly.


Usually I announce them a couple of days ahead of time


in the community section.


You can drop your questions there,


or you can watch out for the link


and join us live if you'd like.


All right.


JavaScript SEO office hours, December 9th, 2020

Hello, and welcome to the JavaScript SEO Office Hours.


Today, December 9, 2020, like, I don't know.


Today has been the longest month of the year,


or the longest year of the month.


I'm not sure.


Great to have you all here.


We will go through some of the submitted questions


from YouTube, and then I'll hand over the words to the audience.


If you have been to one of these Office Hours beforehand,


or if you're watching the recording and wonder what this


is and how you can participate every two weeks,


we or I am posting a thread on the Community


tab of our YouTube channel where you can submit questions.


And I also then, if you click on the sort in the comments,


you can click on the sort by newest first,


and then you see me also posting the Hangout


link to these Hangouts if you want


to join the live recordings.


We have a few questions today.


One comes from Rafael, who asks, facing a big problem


with PageSpeed Insights and Google AdSense.


Pages with AdSense are battling the metrics, so yellow or red.


The pages without are green and yellow.


So is there any way to delay the AdSense JavaScript


in the plugin called WP Rocket?


I don't know if there is a specific option for this.


I know that this is hiding the issue from PageSpeed metrics.


However, I think if you have a way to insert a delayed,


that also makes it a little better for the user


because the website becomes interactive and visible


and the content is there.


And then you load, hopefully, then you


load the AdSense code.


That should be a better user experience.


And if it works, that's great.


But for AdSense, I would ask the AdSense folks


because I'm not that familiar with the AdSense code base


or the way that their stuff works.


So that's that from my side.


And I have no suggestions to work around this issue.


I would bring it up with the AdSense support


because I think it's important that also our AdSense product


makes good on the promise of good user experience.


So that's that.


But I'm not in the AdSense team.


I can't really speak for them.


Ricardo is asking about the intersection observer.


He says, from what I understand, and correct me if I'm wrong,


Googlebot renders the page using a very tall viewport.


How tall is that, by the way?


It's a good question.


For this reason, the suggestion for the lazy loading


of the images is to take the advantage


of the intersection observer, among other things.


But what if my page is really tall, much taller


than the viewport used by Googlebot,


everything not included in the viewport


and therefore is not yielded, is ignored by Googlebot?


So that's a really good question.


And the reason why, and I know that Asaf, who


is also on the call, has a question about the viewport


as well.


The reason why I don't want to speak too much


about the viewport is that that's an implementation


detail that can change at any point in time


without reference.


And you should make your website work in a way that allows


access to all content without having to be


on a very specific viewport.


Now, that being said, regarding how tall it is,


it is as tall as it needs to be within certain limits.


Now, I know that's a fantastic response.


But what we do is, and again, that's


an implementation detail that can, at any point in time,


change.


The way that we deal with things is


we don't scroll because that's surprisingly


expensive and glitchy.


What we do instead is we expand the viewport.


And when we see that there's new content being loaded,


we expand the viewport further.


We can do that quite a while at some point due to memory


restraints or constraints.


We might not do it any further.


So I would recommend making sure that you have a way


to either split the content up so that you can access it


via a specific URL or making sure


that the individual bits and pieces that you care about


are available under different URLs


and are submitted through the site map


or use the Intersection Observer.


But don't expect everything to be in the page


unless it is a reasonable or reasonably small amount.


So I would say, if you need, let's say, a million pixels,


then you're probably looking at something


where eventually we would cut off.


I picked a million pixels arbitrarily.


I'm not saying we can't go further than one million


pixels.


I'm also not saying we are going to one million pixels.


What I'm saying is there is a certain amount of wiggle room


where the Intersection Observer will still work.


And I think we might actually fire


all Intersection Observers unless we see that it stops


creating new code.


But I can guarantee that that's the case.


And I am not sure what the limitations are,


where the heuristics kick in.


So again, as long as these items are just basically links


to other pages that have the actual content, that's


not a problem because then you can submit these individually


through site maps, for instance, or offer a paginated version


of the Infinite Scroll.


But Infinite Scroll is definitely


a challenging and interesting use case.


Normally, Intersection Observer should get you pretty far.


So that's that.


Which guides me gently into Arsa's question.


I know you have a question about the desktop crawling viewport,


don't you?


Right, yeah.


So he has a site with three column layout.


And one of the columns is triggered only


when the viewport is at least 1,200 pixels wide.


You haven't seen it being rendered either


on the screenshot or the code itself.


What's the threshold for getting the content rendered?


I guess the threshold is 1024 pixels,


if that's the correct dimension.


You think it's aligned with most desktop cases.


1024 is not really a desktop size, more a tablet size


these days.


Yeah.


So as I said, I don't actually know the dimensions


because I don't care.


And it shouldn't matter as much.


I know that there is an option, hypothetically, we could even


do what we do for vertical layouts.


In horizontal, we can expand horizontally.


But as far as I'm aware, Googlebot


doesn't make use of that.


What's the default width of the viewport?


It should actually be, I think, the default starting width


and height is 10,000 pixels in each directions.


So I'm surprised that you seem to be seeing 1,024 pixels.


That's a very specific number.


And I'm not sure where that comes from.


So basically, we ran around 20 tests.


And we hit at the 1024.


And it broke the left column.


And you could see the rendered HTML included the content only


when you were broader than 1,024.


Right.


That's interesting because it should be broader.


But generally, we also want to prevent having the 1,024


because we don't want to show it for tablet.


An interesting question there is why?


So if it's a matter of not showing it or showing it


differently, so if it's a proper responsive design,


then that shouldn't be a problem.


Then it should always be in the DOM somewhere.


Is that the case?


Or is it only being loaded into the DOM


if the screen size has a certain size?


Or the viewport has a certain size?


OK.


So if you stretch it and reach the Chrome browser,


then you reach the 1,200.


So it's showing up.


But if you reduce it.


But when you say showing up, does that


mean it loads additional content at that moment?


Right.


Well, what's the use case here?


Why is this content not available to someone


on a smaller screen device?


Because we want to differentiate between tablet users


and desktop users.


We don't want to have this column on tablet


because it looks like two men, like two people from the world.


I understand what you mean.


It looks too busy.


It looks too full.


Too busy.


Interesting.


The thing that I'm surprised by is, though, that it's 1,024.


That's a very odd number that I wouldn't have expected.


And yeah, in a high report, 1,024 as well.


And it is quite arbitrary.


Yeah, as far as I'm aware, the default number.


I would have to double check what we're actually


using in indexing because it's a configuration that


goes through WRS.


And I'm not exactly sure what is the configuration.


But again, it's also an implementation detail.


And the question really is, if this content is a mobile device,


if this content is important for you


or important enough for you so that Google needs to see it,


how can you include the content in a way that doesn't


make the design too busy?


And there's lots of ways of doing that, right?


So basically, we did have the functionality


that we'll take this unit and embed it


in the shrink version.


So we're talking about the author bio.


So.


OK, I see.


Yeah.


Yeah, so we do want to have to get it for all by Google.


But we have some kind of solution.


I'm just wondering what is the threshold.


Seems to be 1,024, even though I would not rely on that.


As I said, this can change any time in either direction


because we are not guaranteeing this.


There's a reason.


This is one of the cases where there


is a gap in the documentation.


And the gap in the documentation has a reason.


The reason is that you shouldn't rely on it,


and you can't rely on it.


And the second question that I wrote there


is, is that the case for desktop viewport, like 1,024?


So I think this one, this is the.


Seems to be, which surprises me because I


know that at least for vertical, we do expand.


I'm not 100% sure if we expand for horizontal.


I don't think we do.


So you would normally see taller viewports


as in more height of the viewport,


depending on how large or how tall your content is.


That should generally work.


Not 100% sure what's happening with height.


I'm pretty sure that is fixed.


And I'm not sure what it is fixed to.


Probably 1,024.


If you say that that's what your test concludes,


I have no reason to doubt that.


Yeah, like after 20 tests, we reach that number, right?


I wouldn't be surprised if that's what's happening.


I'm actually trying to search the source code right now


to find that specific part.


Ooh, what's happening out there?


See if I can find the, ah, no, I clicked on the wrong button,


and now I have the ugly version again.


Damn it.


The new interface is fascinating.


Let's put it that way.


And it does no longer have the old files,


which is unfortunate because that was useful.


I am pretty sure.


Oh, hold on.


Actually, I can try it here.


Aha.


I can try it by actually just passing in the request


through the rendering system, and then I'll


see what comes out.


But 1,024 is a good possibility.


You also have the question with a no archive tag inserted


by helmet.


That should be fine.


That should be picked up.


If it's not, then I would argue that that's


maybe a glitch in the cache.


And then that's a problem because the cache is not


really maintained anymore.


Again, the other interesting thing.


Oh, so the no archive, if I remember correctly,


is pretty much just so that you are not


getting into the downtime cache thing like view page and cache.


So it should be fine.


If it isn't, if you see that it behaves differently,


then that's a good possibility that the way that the cache


feature picks it up happens in an earlier


stage in the pipeline, which is a bit of a tricky thing


because the cache feature itself is actually not


actively maintained anymore.


It just is there because it kind of works,


and it would be a shame to stop supporting it.


Probably you're not rendering the page.


It's possible.


I mean, we're always rendering the page.


What's possible is that the cache service kicks in right


after crawling, which would then basically mean that we are not


getting the rendered version.


We are rendering the page.


We're just not getting the rendered version for the cache.


Or the cache actually pulls out data


before the rendering happens, which


is a bit unfortunate if that's a problem.


The AMP team, regarding the AMP HTML tag,


they say that they don't rely on JavaScript.


And you need to have to.


Yeah.


Yeah, so maybe with no archive is the same.


That is very much possible.


But I would be surprised because I


know that the bit that parses meta tags and AMP is not


a meta tag.


The meta tags in non-AMP pages are parsed


before and after rendering.


The question is, when does the cache build its entry?


When does the cache get populated?


It is possible that the cache populates immediately


with a fetch reply from the crawler.


So immediately after crawling, it pulls itself a copy.


It is also possible that it actually only pulls itself


a copy once things get into the index.


I could see that being reasonable as well.


And that would basically mean that you would not


see problems with the JavaScript injected variation of this.


But again, it is possible that we are pulling it


earlier in the process.


And then you would probably see that it's not


picking this one up.


And this is actually really tricky to debug


because it might also just be race conditions,


because a lot of things happen in parallel.


So sometimes we might see the rendered version.


Sometimes we might not.


That's something that we see with the cache in general.


Sometimes we see the rendered version in the cache.


Most of the time, we don't.


And I have the feeling that's because the cache tries


to extract information as early as possible from the document.


And that's very likely to end up being before rendering.


So I wouldn't rely on the no archive tag being


inserted from JavaScript.


Generally, I would always try to get the meta tags consistent


before you need JavaScript, or at least leave them out


if you can, and only add them with JavaScript


if you can't make them consistent between the server


sent version and the JavaScript rendered version.


Excuse me.


AUDIENCE MEMBER 1.


Thank you.


So currently, our main caller is desktop.


So we did have this tag on the road, shame on desktop.


But when we move to mobile first,


don't have a solution yet.


But the


should be fine.


Oh, my.


Awesome publisher and there, you know.


Right.


Yeah.


OK, I see where this is going.


All right, OK, I understand that.


Data marketplace thing is broken.


I can't actually access the output from Raffia right now.


That's unfortunate.


Yeah, so I would test it.


But I think you have a 50-50 chance.


I think it's a race condition kind of situation.


Got it.


Thank you very much for both of them.


Doing my best, sorry.


All right, do we have any other questions?


We have a few more minutes before I


got to head out for today.


All right, there's no further questions.


I'd like to thank everyone who joined.


Today's recording has been a huge pleasure.


I wish you all a lovely, lovely time.


Stay safe, stay healthy.


The next office hours is going to be in two weeks.


I'll get this video updated, uploaded to the channel


as soon as possible.


And then I'll put the thread for the fortnightly next edition


of the JavaScript SEO Office Hours into the YouTube channel.


Thanks a lot.


Have a lovely evening or a lovely morning, afternoon,


whatever it is where you are.


Has been a pleasure.


Search Console for Developers - Google Search Console Training (from home)

Hi, I'm Daniel Weisberg, Search Advocate at Google.


And today I'll talk about how to use Search Console if you're a developer.


Since the tool provides a lot of information about search optimization,


developers may think it's not useful to them.


But I beg to differ.


In this video, I'll talk about the most useful Search Console reports


to help developers build websites that are healthy, findable,


and optimized for Google Search.


In summary, use the Index Coverage Report


to understand site-wide search indexing issues.


Use the URL Inspection Tool to debug page-level search indexing issues.


Use the Security Issues Report to find and fix issues affecting your site.


And use the Core Web Vitals Report to make sure your website


provides a great page experience to your users.


Google Search Console


The first thing that is really important for you to know


is whether Google can find and crawl your pages.


Small bleaches can have a massive effect when it comes to Google bot


being able to read websites.


For example, sometimes we see companies accidentally adding no index tags


to entire websites, or blocking the content from being crawled


by an error on their robots.txt file.


These issues can be easily uncovered using the Index Coverage Report.


When you open the report, the first page you see is the summary page.


The default view shows indexing errors on your website.


But you can click to show valid with warnings, valid, and excluded pages.


In addition, you will find a checkbox to add to the main chart


the number of impressions your pages got on search.


Here's what each status means with some examples.


Errors prevent pages from being indexed.


Pages with errors won't appear in Google,


which can mean a loss of traffic to your website.


For example, your page might be returning a 404 or a 500 level error.


Additionally, you might get an error if you submitted a page through a sitemap,


but it contains a no index directive.


All these cases would prevent the page from appearing on search results.


Valid with warnings are pages that may or may not be shown on Google,


depending on the issue.


But we think there is a problem you should look into.


For example, Google might find pages that are indexed,


though blocked by robots.txt.


This is marked as a warning because it's not clear


if you intended to block the page from search results.


If you do want to block the page,


robots.txt is not the best way to avoid being indexed.


To do so, you should either use the no index directive


or request authentication to see the page.


Valid pages have been indexed and can be shown on Google Search,


so good job.


Excluded pages were not indexed and won't appear in Google,


but either we think that is your intention


or we think it's the right thing to do.


For example, the page has the no index directive, your choice,


or the page is a duplicate of another page, Google's choice.


You can watch the index coverage episode in this series


to understand more about the issues affecting your site


and learn how to validate a fix you have implemented.


To debug an issue with a specific page,


for example, a page Google is showing an error in the coverage report,


you should use the Inspect URL tool.


You can use it to learn the current index status of your pages,


to test the live URL, to ask Google to crawl a specific page,


and to view detailed information about the page's loaded resources


and other information.


You can access the tool from the sidebar,


and you'll also see a little magnifying glass next to URLs in some reports.


For example, if you drill down to a URL from the index coverage report,


you can click to inspect it.


Once the page displays the results,


you will see three different sections,


all of them presenting information from Google's last crawl,


or crawl attempt.


If you recently made changes to the page,


you might want to check if they're working as intended


by clicking Test Live URL


and comparing the live version to the indexed one.


In the presence on Google Card,


you'll get a verdict on whether or not the URL can appear


in Google Search results.


There are two important options available for developers in this card.


First, if you made a change to the page


and want to request Google to re-index it,


use Request Indexing.


Second, you can click View Crawl Page


to check the HTML version that Google indexed


and more information on the HTTP response and loaded resources.


In the coverage section, you'll learn where the page was discovered,


such as a sitemap or referring page,


when was the last crawl and by which user agent,


and whether the page is included in the Google index


or another version of it was chosen as the canonical.


In the enhancement section,


you'll find any structured data details,


along with AMP and mobile usability warnings and errors.


For example, if your page is not marked up properly with structured data,


the inspection will return an error


detailing the missing or wrong values.


You can watch the Inspect URL episode in this series


to learn how to use the tool to debug and fix any issues you find.


Search Console also includes two reports


that will help you optimize your site's health,


security issues and Core Web Vitals.


The Search Console security issues report shows warnings


when Google finds that your site might have been hacked


or used in ways that could potentially harm a visitor or their device.


For example, a hacker might inject malicious code in your pages


to redirect your users to another site


or to automatically create pages on your site


with nonsensical sentences filled with keywords.


These are examples of website hacking.


An attacker might also trick users into doing something dangerous,


such as revealing confidential information


or downloading malicious software.


That's called social engineering.


When you log into Search Console,


you'll already be notified in the overview page


if you have security issues on your site.


Clicking the alert will lead you to the security issues report,


where you'll find a list of all security issues Google found in your website.


In the report, you'll find more details about the type of threat,


a sample of pages affected by it,


and a process for you to inform Google when you fix the issues.


I recorded an episode about the security issues report


with Aurora Morales, my colleague from the Trust and Safety team.


Check it out for more details.


Lastly, the Core Web Vitals report shows how your pages perform


based on real-world usage data, sometimes called field data.


The report is based on three metrics.


LCP, or Largest Contentful Paint,


is the amount of time it takes to render the largest content element


visible in the viewport,


starting from when the user requests the URL.


This is important because it tells the reader


that the URL is actually loading.


FID, or First Input Delay,


is the time from when a user first interacts with your page,


when they click the link or tap the button,


to the time when the browser responds to that interaction.


This is important on pages where the user needs to do something,


because this is when the page has become interactive.


CLS, or Cumulative Layout Shift,


is the amount that the page layout shifts during the loading phase.


The score is rated from zero to one,


where zero means no shifting and one means the most shifting.


This is important because having elements shift


while a user is trying to interact with the page is very annoying.


I'm sure you will agree.


Log into Search Console and navigate to the Core Web Vitals report.


You'll see that the report is broken down by mobile and desktop.


Open one of them to see an aggregate report with more details.


By default, the chart shows trends for pages with poor performance,


but you can click on Need Improvement and Good to check their trends too.


Be aware that if a page does not have a minimum amount of reporting data


for any of these metrics, it is omitted from the report,


so you probably won't see all your pages.


Click an issue in the table to drill down.


In this report, you'll find more details about the issue,


a chart showing trends, and a table with sample URLs.


Check the links in the description to find out more about the Core Web Vitals report.


You might also like to check out tools such as Lighthouse


before you deploy changes to production.


With that, I'll end this video.


It's too long already, and even if you drank coffee in the beginning,


the effect is probably starting to die away.


To recap, use the Index Coverage report


to understand site-wide search indexing issues.


Use the URL inspection tool to debug page-level search indexing issues.


Use the Security Issues report to find and fix threats affecting your site.


And use the Core Web Vitals report


to make sure your website provides a great page experience to your users.


Don't forget to subscribe to the Google Webmasters YouTube channel


to watch our upcoming Search Console videos.


Stay tuned.


How to improve Cumulative Layout Shift for a better page experience

So you know that thing when you start to read a website when all of a sudden the page just


kind of jumps like hundreds or thousands of pixels and you have no idea where you were?


Or when you go to tap on a button and the button just has a pop-up that pops up right


where your finger is leaving you desperately smashing that back button.


Well, these things are called layout shifts and layouts just like this are terrible.


But with the metrics that make a page experience, it's finally a lot easier to make these lamentable


layouts less shifty and more nifty.


Let's stick around as we check out yet another one of these metrics, cumulative layout shift.


When we're talking about cumulative layout shift, or CLS if you're as easily tongue-tied


as I am, what we're talking about is how stable a page is, or rather how predictable a page


is to use.


All the visible parts of a page and how they fit together make up what a browser thinks


of as a layout.


Images, text, video, all of it.


Now sometimes when the contents of a page changes, like when an ad is inserted, the


widget loads, or an image changes size, stuff that's already visible on the page can end


up needing to be shifted around for everything to fit.


Every time that happens, well, that's a layout shift.


Cumulative layout shift is a way to look at how much, as in what percentage, of the visible


parts of a page experience these layout shifts.


For example, here we have a simple blog article.


There's a headline, a hero image, and text.


On a slower connection, the text shows up right away, but the image takes a bit more


time to appear.


Eventually, the image will be downloaded, but before those pictures' pixels can be painted,


some changes might need to occur.


As far as the browser is concerned, everything above the image is fine.


Nothing needs to change.


But in order for the image to show up where and how it was intended, everything below


it has to shift down to make room for it.


So the text of the article gets pushed down half the visible amount of the page in order


to make room for the image.


That means 50% of what we can see has to be shifted just for the image to show up.


That will give us a CLS of 0.5, as in 50%.


So a page's CLS score is basically how much the visual parts of a page change.


There is a few caveats to this, however.


Number one, there can only be one.


Earlier we said that our page had a CLS of 0.5.


That's true, but only if nothing else ever shifts on the page.


Or at least if I exit the page before anything else shifts.


If, however, later on an ad loads and shoves everything down, our CLS could shoot way up.


In this case, literally everything has moved.


That means our CLS is now one.


Every time someone visits the site, the browser will continually track CLS for the entire


time that they use it.


Once they navigate away or close the tab, the browser will report the largest CLS value


found.


That one number gets collected with all the other visitors to that URL and generates the


CLS value for that page's web vitals.


Number two, sometimes change is a good thing.


If pages never changed, they wouldn't be that useful, and CLS certainly wouldn't want that


to happen.


Layout shifts that are triggered by used interactions, things like tapping, clicking, or typing,


are given a 500 millisecond grace period to perform any layout shifts they need to best


respond to that user.


After those 500 milliseconds, a new CLS session window starts.


From millisecond 501 onward, any content shift that occurs gets added up and potentially


used for a final CLS score.


That session window will stay open for as long as there are visible layouts being shifted.


Any additional shifts are added together.


For example, another page on our site has a similar layout, a headline, and body text.


This time, it has two smaller images.


Just like before, they're slow to load, so our content shifts once they do.


Unlike before, the first image only shifts a small amount, 5%, so now our CLS would be


But then the second image loads several hundred milliseconds later.


It also needs a little bit of room, so the contents get pushed down even further.


It shifts the visible amount 2.5%.


Since it happened so close to the last layout shifts, they are accumulated into one single


value, 7.5%, or 0.075.


This session window will stay open until more than one second has passed since the last


layout shift, or until five seconds have passed since the creation of this session window.


Any future layout shift gets counted as a separate layout shift event and not added


to the previous window.


Number three, not all interactions are free.


User interactions like scroll or mouse move don't count as the kind of events that give


you that 500 millisecond grace period.


This makes sense.


I don't think a user would really expect the layout of a page to shift while they're scrolling.


Number four, not all changes are bad.


You can actually move content on the page all you want via CSS animations and transforms.


This is because when you set a CSS attribute like transform, the element gets moved to


its own layer.


This means that its position isn't impacting the layout of any other part of the page.


It's like floating on top of everything else.


And since nothing else is being shifted, it won't count towards your CLS.


Finally, number five, what you can't see can't hurt you.


You may have noticed that I've repeatedly emphasized that CLS is only for the visible


elements of the page.


That's because as far as CLS is concerned, if you can't see it, it doesn't matter if


it's moving.


Like all the page experience, CLS is about making sure that people have the best user


experience possible.


So if you need to move something around or lazy load in content, well, go for it.


If it isn't visible to the user or shifting what is visible to the user, then your CLS


will not be affected.


The key thing to remember is that a good CLS score means that what your user sees is stable


and predictable.


It's not jumping all around.


So now we know what CLS is and that it's represented by a number between zero and one.


But what should that value be?


In a perfect world, zero.


I mean, there's always never a need for a layout shift to occur.


We can almost always prevent them.


In fact, we're going to get into specifics of just how you can do that real soon.


In the real world though, we all have jobs and our sites are really balancing tons of


different concerns.


So if you can't hit zero, then a great number to aim for is 75% or more of the views a page


has has a CLS of 0.1 or less.


If you're below that, you're doing great.


But anything above it, well, stick around and we'll see if we can lower it.


I know that was a ton of information, but I promise now you know it all.


I mean, that's what CLS is.


It's great to get that taken care of.


But now you may be asking, how do I figure out what my CLS score is?


Like all the Core Web Vitals, CLS is what actual users are experiencing when using your


site.


We call this information field data.


As a result, you can only really actually rely on the user measurements that come from


those real world users.


Either via your own analytics or the ones you have access to inside of the Core Web


Vitals report section of the Search Console.


If you haven't already, you will need to create a Search Console account, but I highly recommend


it.


See, you'll have some invaluable information in there to how your page is performing with