Mobile-first indexing checklist for content sites

A mobile-first indexing checklist makes sure the mobile version of every page has the same content, metadata, structured data and links as the desktop version, and that the Google smartphone crawler can load all of it. Google indexes and ranks the mobile version of your pages, so anything that is missing or blocked on mobile is, in practice, missing from Google.

Google finished moving sites to mobile-first indexing in 2024. Most modern responsive sites are fine by default, but content sites still lose pages to a few common mistakes: trimmed mobile templates, content that only loads on a tap, different meta robots tags, and plugins that behave differently on phones. This mobile SEO checklist is built for blogs and content sites, with the exact tests to run in Search Console.

What does mobile-first indexing mean?

It means Googlebot smartphone is the main crawler for your site. Google fetches and renders the page as a phone would, and that version is what goes into the index and gets ranked, including for people searching on desktop. The desktop crawler still visits occasionally, but its view is not the one that counts.

You can confirm which crawler Google uses for your property in Search Console under Settings, where the indexing crawler is listed. For almost every site it now reads Googlebot smartphone. Google's own mobile-first indexing best practices are the primary reference for everything below.

The mobile-first indexing checklist

Work through each row on a sample of your most important templates: the home page, a category page, a long article and a page with heavy embeds. If a template passes, every page built on it usually does too.

Mobile content parity: the most common failure

Mobile content parity means the phone version carries the same primary content as desktop. Problems usually come from well-meant design decisions: hiding a long comparison table on small screens, dropping the FAQ section to keep the page short, showing fewer related posts, or using a separate, lighter mobile template.

If the content is not in the mobile version, Google will not index it. Putting content inside tabs or accordions on mobile is fine, as long as it is in the HTML when the page loads. Removing it is not. If a table is too wide for a phone, make it scroll sideways inside its container rather than hiding it.

Separate mobile URLs and dynamic serving

Responsive design, where one URL serves the same HTML to every device, is the simplest setup and the one Google recommends. If you still run a separate m. site, each desktop page needs a rel="alternate" pointing to its mobile URL and each mobile page a rel="canonical" pointing back, and the mobile pages need the full content. If you serve different HTML by device on the same URL (dynamic serving), send a Vary: User-Agent header so caches do not mix the versions.

Lazy loading: make sure the Google smartphone crawler can see it

Lazy loading is good for speed, but it is also where content quietly goes missing. Googlebot does not click buttons or scroll the way a person does, so anything that only loads after a user action may never be rendered.

• Use the browser's native loading="lazy" attribute on images below the fold, or a library that uses IntersectionObserver. Both work with Google's rendering.
• Do not lazy-load the main image or the first screen of text. It slows Largest Contentful Paint, and it is the content Google most needs.
• Avoid "Load more" buttons for article text or comments you want indexed. If paginated content matters, give each page its own crawlable URL with normal links.
• Check infinite scroll on category and archive pages. Google needs plain paginated links to reach older posts.

Speed and layout stability are part of the same picture. If your mobile pages feel slow, the Core Web Vitals side is covered in UX signals and SEO: INP, page experience and engagement.

How to check mobile-first indexing in Search Console

Search Console's Mobile Usability report and the standalone Mobile-Friendly Test were retired at the end of 2023, so the checks now run through URL Inspection, the Rich Results Test and Lighthouse. If you have not connected Search Console yet, start with connecting Google Search Console to an auto SEO tool, which covers property setup.

1. In Search Console, open Settings and confirm the indexing crawler is Googlebot smartphone.
2. Paste a key URL into the URL Inspection bar at the top and click Test live URL. This fetches the page with the smartphone crawler right now.
3. Click View tested page. The Screenshot tab shows what Googlebot rendered; the HTML tab shows the rendered source. Search the HTML for a sentence from the bottom of your article and for your FAQ text.
4. Open More info > Page resources and look for anything that could not be loaded. Blocked CSS or JavaScript can change what Google sees.
5. Check the JavaScript console messages in the same panel for errors that could stop content rendering.
6. Run the same URL through the Rich Results Test to confirm your structured data is detected on the mobile render.
7. Open Chrome DevTools, switch on device mode, and run Lighthouse with the mobile setting to catch viewport, tap target and font size issues.
8. Repeat for one page per template, then spot-check a few new articles each month.

Mobile SEO checklist for WordPress content sites

Most WordPress themes are responsive, so parity problems usually come from plugins and theme options rather than the core layout. A few places to look:

• Theme settings that hide sidebars, related posts or table of contents on mobile. Hiding a sidebar is fine; hiding the article's own content is not.
• Page builder "hide on mobile" toggles. Search your key templates for sections set to hidden on mobile and decide whether that content matters.
• Separate AMP or mobile plugins left over from older setups. If one is serving a stripped-down version, check its content and schema match the main page.
• Pop-up and email capture plugins. Set them to trigger on scroll or exit, not on arrival, and keep them small on phones.
• Caching plugins with separate mobile caches. Clear both after template changes, or Google may keep seeing the old mobile version.

If you are about to switch on regular publishing, sort these out first. The WordPress SEO checklist to set before you auto-publish covers permalinks, sitemaps and the other settings worth fixing once, and what to do after launching a new WordPress site covers the content plan that follows.

Images, video and embeds on mobile

Use the same images on mobile as on desktop, with the same descriptive alt text. Do not swap in tiny, low-quality versions for phones; serve responsive sizes through srcset instead, which WordPress does for images inserted in the editor. Keep image URLs stable rather than changing them on every load.

For video and social embeds, make sure the player or embed loads on mobile and is not blocked by a consent tool that Google cannot get past. If an embed carries important information, summarise it in text on the page as well.

Run the checklist once per template, fix what fails, and then spot-check new pages every month. Once your mobile template is sound, the remaining job is publishing useful pages consistently. See how upRanker plans and publishes them, or start with a free scan of your site.