As the Search Relations team at Google, we're here to help webmasters be successful with their websites in Google Search. We write on this blog, create and maintain the Google Search documentation, produce videos on our YouTube channel - and now we're making a Search Off The Record podcast, too!
In the podcast, John, Gary and Martin from our team are talking about a variety of topics and give a glimpse behind the scenes of Google Search.
In this podcast, we discuss things that are on our minds, like:
updates in Google Search
background on recent announcements
news from the SEO and web developer communities
stories from the past
things we're working on
food and drinks
random things from the top of our heads
puns, jokes and more
Check out the first few episodes and subscribe to the podcast on a podcast platform of your choice (such as Google Podcasts, Apple Podcasts, Spotify, Overcast, Castbox, and many more) to be the first to know when new episodes come out! New episodes come out every few weeks.
Mobile-first indexing has been an ongoing effort of Google for several years. We've enabled mobile-first indexing for most currently crawled sites, and enabled it by default for all the new sites. Our initial plan was to enable mobile-first indexing for all sites in Search in September 2020. We realize that in these uncertain times, it's not always easy to focus on work as otherwise, so we've decided to extend the timeframe to the end of March 2021. At that time, we're planning on switching our indexing over to mobile-first indexing.
For the sites that are not yet ready for mobile-first indexing, we’ve already mentioned some issues blocking your sites in previous blog posts. Now that we’ve done more testing and evaluation, we have seen a few more issues that are worth mentioning to better prepare your sites.
In mobile-first indexing, we will only get the information of your site from the mobile version, so make sure Googlebot can see the full content and all resources there. Here are some things to pay attention to:
You should use the same robots meta tags on the mobile version as those on the desktop version. If you use a different one on the mobile version (such as noindex or nofollow), Google may fail to index or follow links on your page when your site is enabled for mobile-first indexing.
noindex
nofollow
Lazy-loading is more common on mobile than on desktop, especially for loading images and videos. We recommend following lazy-loading best practices. In particular, avoid lazy-loading your primary content based on user interactions (like swiping, clicking, or typing), because Googlebot won't trigger these user interactions.
For example, if your page has 10 primary images on the desktop version, and the mobile version only has 2 of them, with the other 8 images loaded from the server only when the user clicks the “+” button:
+
(Caption: desktop version with 10 thumbnails / mobile version with 2 thumbnails)
In this case, Googlebot won’t click the button to load the 8 images, so Google won't see those images. The result is that they won't be indexed or shown in Google Images. Follow Google's lazy-loading best practices, and lazy load content automatically based on its visibility in the viewport.
Some resources have different URLs on the mobile version from those on the desktop version, sometimes they are served on different hosts. If you want Google to crawl your URLs, make sure you're not disallowing crawling of them with your robots.txt file.
For example, blocking the URLs of .css files will prevent Googlebot from rendering your pages correctly, which can harm the ranking of your pages in Search. Similarly, blocking the URLs of images will make these images disappear from Google Images.
.css
If your mobile version has less content than your desktop version, you should consider updating your mobile version so that its primary content (the content you want to rank with, or the reason for users to come to your site) is equivalent. Only the content shown on the mobile version will be used for indexing and ranking in Search. If it’s your intention that the mobile version has less content than the desktop version, your site may lose some traffic when Google enables mobile-first indexing for your site, since Google won't be able to get the full information anymore.
Use the same clear and meaningful headings on your mobile version as on the desktop version. Missing meaningful headings may negatively affect your page's visibility in Search, because we might not be able to fully understand the page.
For example, if your desktop version has the following tag for the heading of the page:
<h1>Photos of cute puppies on a blanket</h1>
Your mobile version should also use the same heading tag with the same words for it, rather than using headings like:
<h1>Photos</h1> (not clear and meaningful)
<h1>Photos</h1>
<div>Photos of cute puppies on a blanket</div> (not using a heading tag)
<div>Photos of cute puppies on a blanket</div>
Make sure the images and videos on your mobile version follow image best practices and video best practices. In particular, we recommend that you perform the following checks:
Don’t use images that are too small or have a low resolution on the mobile version. Small or low-quality images might not be selected for inclusion in Google Images, or shown as favorably when indexed.
For example, if your page has 10 primary images on the desktop version, and they are normal, good quality images. On the mobile version, a bad practice is to use very small thumbnails for these images to make them all fit in the smaller screen:
(Caption: desktop version with normal thumbnails / mobile version tiny thumbnails)
In this case, these thumbnails may be considered “low quality” by Google because they are too small and in a low resolution.
As previously mentioned, remember that using less-meaningful alt attributes might negatively affect how your images are shown in Google Images.
For example, a good practice is like the following:
<img src="dogs.jpg" alt="A photo of cute puppies on a blanket"> (meaningful alt text)
<img src="dogs.jpg" alt="A photo of cute puppies on a blanket">
While bad practices are like the following:
<img src="dogs.jpg" alt> (empty alt text)
<img src="dogs.jpg" alt>
<img src="dogs.jpg" alt="Photo"> (alt text not meaningful)
<img src="dogs.jpg" alt="Photo">
If your site uses different image URLs for the desktop and mobile version, you may see a temporary traffic loss from Google Images while your site transitions to mobile-first indexing. This is because the image URLs on the mobile version are new to the Google indexing system, and it takes some time for the new image URLs to be understood appropriately. To minimize a temporary traffic loss from search, review whether you can retain the image URLs used by desktop.
If your desktop version uses schema.org's VideoObject structured data to describe videos, make sure the mobile version also includes the VideoObject, with equivalent information provided. Otherwise our video indexing systems may have trouble getting enough information about your videos, resulting in them not being shown as visibly in Search.
VideoObject structured data
VideoObject
Make sure to position videos and images in an easy to find location on the mobile version of your pages. Videos or images not placed well could affect user experience on mobile devices, making it possible that Google would not show these as visibly in search.
For example, assume you have a video embedded in your content in an easy to find location on desktop:
On mobile, you place an ad near the top of the page which takes up a large part of the page. This can result your video being moved off the page, requiring users to scroll down a lot to find the video:
(Caption: video on mobile is much less visible to users)
In this case, the page might not be deemed a useful video landing page by our algorithms, resulting in the video not being shown in Search.
You can find more information and more best practices in our developer guide for mobile-first indexing.
Mobile-first indexing has come a long way. It's great to see how the web has evolved from desktop to mobile, and how webmasters have helped to allow crawling and indexing to match how users interact with the web! We appreciate all your work over the years, which has helped to make this transition fairly smooth. We’ll continue to monitor and evaluate these changes carefully. If you have any questions, please drop by our Webmaster forums or our public events.
We get lots of questions every day - in our Webmaster office hours, at conferences, in the webmaster forum and on Twitter. One of the more frequent themes among these questions are links and especially those generated through JavaScript.
In our Webmaster Conference Lightning Talks video series, we recently addressed the most frequently asked questions on Links and JavaScript:
Note: This video has subtitles in many languages available, too.
During the live premiere, we also had a Q&A session with a few additional questions from the community and decided to publish those questions and our answers along with some other frequently asked questions around the topic of links and JavaScript.
Googlebot parses the HTML of a page, looking for links to discover the URLs of related pages to crawl. To discover these pages, you need to make your links actual HTML links, as described in the webmaster guidelines on links.
Googlebot extracts the URLs from the href attribute of your links and then enqueues them for crawling. This means that the URL needs to be resolvable or simply put: The URL should work when put into the address bar of a browser. See the webmaster guidelines on links for more information.
As long as these links fulfill the criteria as per our webmaster guidelines and outlined above, yes.
When Googlebot renders a page, it executes JavaScript and then discovers the links generated from JavaScript, too. It's worth mentioning that link discovery can happen twice: Before and after JavaScript executed, so having your links in the initial server response allows Googlebot to discover your links a bit faster.
Fragment URLs, also known as "hash URLs", are technically fine, but might not work the way you expect with Googlebot.
Fragments are supposed to be used to address a piece of content within the page and when used for this purpose, fragments are absolutely fine.
Sometimes developers decide to use fragments with JavaScript to load different content than what is on the page without the fragment. That is not what fragments are meant for and won't work with Googlebot. See the JavaScript SEO guide on how the History API can be used instead.
The AJAX crawling scheme has long been deprecated. Do not rely on it for your pages.
The recommendation for this is to use the History API and migrate your web apps to URLs that do not rely on fragments to load different content.
This post was inspired by the first installment of the Webmaster Conference Lightning Talks, but make sure to subscribe to our YouTube channel for more videos to come! We definitely recommend joining the premieres on YouTube to participate in the live chat and Q&A session for each episode!
If you are interested to see more Webmaster Conference Lightning Talks, check out the video Google Monetized Policies and subscribe to our channel to stay tuned for the next one!
Join the webmaster community in the upcoming video premieres and in the YouTube comments!
Enter your email address:
Delivered by FeedBurner
