Mobile-First Indexing Checklist for Mobile Parity

Mobile-first indexing means Google primarily crawls, indexes and evaluates the mobile version of your site. The question that matters is therefore no longer whether a page looks fine on a phone, but whether the mobile version carries the same content, metadata and link structure as the desktop one.

This checklist turns "is it mobile friendly?" into "is the mobile version complete?". It first separates the two ideas, then shows how to find gaps in content, metadata, images, navigation and robots rules. Content that only appears after JavaScript runs is a separate topic, covered in our piece on JavaScript SEO and rendering.

What Mobile-First Indexing Means

According to Google's Search Central documentation (Opens in a new tab), mobile-first indexing means Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking. The documentation also says a mobile version is not required to appear in Search, though it is very strongly recommended.

Three practical consequences follow:

• Text, images or links that exist on desktop but not on mobile are, for Google, absent from the page.
• Headings, title and meta description on the mobile version are the values that count for indexing.
• Making the mobile version unreachable through a robots rule, a login wall or a faulty redirect directly affects crawlability.

The documentation speaks of individual sites being enabled for mobile-first indexing and gives no blanket completion date, so do not assume your own status. Check it in Search Console; the URL Inspection tool shows which Googlebot type fetched a page.

One clarification: mobile-first does not mean separate mobile and desktop rankings. There is one index; what changes is whose content enters it. If the mobile version is missing pieces, the index receives a page with missing pieces.

Mobile-Friendly Versus Mobile Parity

"Mobile friendly" usually describes appearance and usability: is the text readable, can buttons be tapped, does the page scroll sideways. "Mobile parity" describes content equality: is the information on the desktop page also on the phone page? The two are independent. A beautiful mobile page that trimmed away the desktop table, the FAQ block or the product specifications may have broken parity.

A simple way to separate them:

• Friendliness question: Can a visitor use this page comfortably on a phone?
• Parity question: Can Google see, on the phone version, everything that is supposed to be indexed on the desktop one?

Imagine a small software company (an example scenario) that removes the technical specification table from its product page on mobile to save space. The page is quick and clean, tap targets are generous. But searched terms such as "integration list" only ever appeared inside that table. The mobile version is visually successful and, from an indexing view, incomplete.

That is why the audit works as two separate passes. The first covers user experience; the second compares mobile and desktop source for content, metadata, links and structured data, which is the focus here.

Responsive, Dynamic Serving and Separate Mobile URLs

Google's documentation describes three configurations. Which one you run decides which checks apply.

1. Responsive design: One URL, one HTML document, with CSS adapting the layout. The documentation calls it the easiest pattern to implement and maintain, and notes that content and metadata are already identical across devices.
2. Dynamic serving: One URL, but different HTML depending on the device. The server reads the user agent, and a Vary header should be sent.
3. Separate mobile URLs: For example an m. subdomain. Different URLs, different HTML and redirects based on the user agent.

The parity advice in the documentation mainly targets dynamic serving and separate URLs; with responsive design both versions are the same source anyway. If you are building a new site, responsive design lowers both maintenance load and the odds of a parity mistake.

Separate mobile URLs come with their own rules:

• The desktop URL is canonical: the mobile page points to it with a canonical link, and the desktop page points to the mobile one with an alternate link carrying a suitable media query.
• Error pages should behave the same on both versions.
• Avoid URL fragments (#) on mobile URLs.
• Do not redirect unrelated desktop pages in bulk to the mobile home page.
• Verify both versions in Search Console, and make hreflang on desktop point to desktop and on mobile point to mobile.

These rules are the price of running two sites at once. If your team cannot keep both versions in sync, moving to responsive design shortens the checklist considerably.

Content That Goes Missing or Hidden on Mobile

The most common parity problem is "simplification" that quietly cuts content. Typical examples:

• Long descriptions shortened or dropped on mobile
• Specifications, comparison tables and FAQ blocks hidden
• Sidebar or footer modules with related content removed
• Reviews and ratings loaded on desktop only

Google asks that the mobile site contain the same primary content as desktop. The same page says accordions and tabs are acceptable for layout, so content may sit in a collapsed panel as long as it is on the page. The trouble starts when content only loads after a click triggers a request, which we look at again in the lazy loading section.

To see whether a section really disappeared, compare the two sources. Copy one sentence from a desktop paragraph and search for it in the mobile source. If it is not there, something was cut.

The decision rule is plain. If a visitor on mobile would also need this information, it belongs on mobile. When space is the issue, collapse instead of delete: accordions, "read more" panels and tabs keep content in the document.

Metadata, Structured Data and Canonical Parity

Metadata parity gets missed precisely because the visible content looks fine. The documentation suggests that titles and meta descriptions be equivalent across versions. For structured data it asks for the same markup on both, and for URLs inside the markup to point to mobile URLs on the mobile site. Breadcrumb, Product and VideoObject are named as examples.

When auditing, look at these:

1. Are title and meta description identical, or does the mobile template output another value?
2. Is the robots meta tag the same on both? The documentation warns that a stray noindex or nofollow on mobile can block crawling and indexing.
3. Are canonicals consistent? With separate URLs, the mobile canonical must point to desktop.
4. Does the structured data exist on mobile, or was it added only to a desktop block of the template?
5. If you use hreflang, do mobile URLs reference mobile alternates?

One more principle for markup: it should match visible content. Adding markup for something a mobile visitor cannot see does not narrow the gap, it widens it.

Run this check once per page type: a fix in one template repairs every page that uses it.

Image, Video and Lazy Load Problems on Mobile

The documentation is clear on images: use the same alt text on both versions, serve good quality images in supported formats, and keep image URLs stable. It also notes that using different image URLs on mobile can cause a temporary loss of image traffic. So swapping every URL for a "small mobile version" puts your position in image search at risk. For the full picture on optimising images, see our image SEO guide.

Video follows a similar pattern: supported formats, stable URLs and video structured data present on both versions, with the video findable on mobile.

When lazy loading becomes a problem

The documentation includes a plain warning: do not lazy-load primary content upon user interaction. Googlebot does not scroll, click or type, so content hiding behind a "load more" button may never be seen. Standard lazy loading that fires near the viewport is usually fine for images; risk begins when body text, links or key images depend on a tap.

A quick image check

• In the mobile source, do img tags carry alt text and a real source, or only a placeholder?
• Do key content images load without any user action?
• Do mobile and desktop use the same image URL?

Mobile Navigation and Internal Link Gaps

Mobile menus get simplified to save room, and the internal link structure can quietly thin out in the process. If hundreds of category pages are reachable from a desktop mega menu but only a few main links remain on mobile, the crawler sees a smaller site. Since Google discovers pages by following links, a link missing on mobile is a link missing from discovery.

What to check:

• Are links in the main menu, footer and related-content blocks the same on both versions?
• Did filter and pagination links turn into a "load more" button on mobile? If so, is there a real link to the next page? Our pagination and category page guide covers the structure.
• Has the breadcrumb been hidden on mobile?
• Do links to key pages open only through a JavaScript event, or are they standard anchors with an href?

When room is tight, place links in a hierarchy (expandable sub-menus) instead of deleting them so the source keeps the links. For the broader logic of planning internal links, read our internal linking strategy article. Here, the point is that mobile must not silently erase part of that plan.

Robots, Resource Access and Mobile Crawlability

The documentation is firm on two points: do not block mobile resource URLs with robots.txt, and in most cases use the same robots.txt rules for both versions. It also wants robots meta tags to match across versions.

Frequent real-world mistakes:

• An m. subdomain whose own robots.txt still blocks everything, left over from development
• A mobile template carrying a rule that blocks CSS or JavaScript folders
• A login wall, cookie overlay or full-screen notice replacing the page body on mobile
• A different HTTP status code returned depending on the user agent

Start with robots.txt itself; how to test it is covered in our robots.txt audit guide. Then use the live test in Search Console's URL Inspection to see how Google processes the page. For separate mobile URLs, the documentation also advises making sure the mobile site can handle a possible increase in crawl rate.

Your sitemap should reflect both versions consistently, too. If you run separate URLs, you can check which URLs belong in it and how they line up with canonicals using the XML sitemap audit checklist.

Mobile Experience Signals

Parity protects the raw material of the index; experience decides whether a visitor stays. The checks here concern look and use.

• Viewport setting: Without a viewport meta tag, a mobile browser shrinks the desktop layout.
• Readable type size: Visitors should read without pinching to zoom.
• Tap targets: Adjacent links and buttons need enough space to avoid mis-taps.
• Horizontal scrolling: Content should fit the screen width; wide tables belong in their own scrollable container.
• Intrusive elements: Pop-ups and ads covering much of the screen make content harder to reach. Google's documentation also advises against ads that take up too much of the top of a mobile page.
• Forms: The right keyboard type, adequate field size and visible labels.

To find usability problems, keep your toolset current. Browser device mode, a real phone and Lighthouse all help, and the live test in URL Inspection shows how Google sees the page.

Making the Audit a Regular Process

Parity bugs often return with a redesign, a new plugin or a theme change. A light but regular routine beats a one-off audit.

1. Page type inventory: List templates such as home, category, product or service, and article.
2. One reference page per template: Choose a representative URL for each.
3. Comparison round: Compare mobile and desktop source for content, metadata, links, images and structured data.
4. Change triggers: Repeat the round after a theme update, a new plugin, a menu change or a development sprint.
5. Log: Record findings, dates and the owner of each fix in a table.

A monthly rhythm suffices for most sites, plus an extra round when a new template ships. These records also answer the familiar question, "something changed, what broke?", quickly.

Sample Template: Mobile and Desktop Parity Check Table

A check table that compares the mobile and desktop versions row by row follows. The findings in it are example values invented for a product page template; replace them with the findings of your own templates.

In this example scenario, the team filling in the table discovers that a theme setting stops the FAQ block from rendering on mobile and that the mobile template outputs empty image alt text. Because neither changed how a visitor saw the page, both went unnoticed for months. Making the invisible visible is the table's job; give every open row a named owner and refill the table in the next round.

Frequently Asked Questions

What does mobile-first indexing mean?

Mobile-first indexing means Google crawls the smartphone version of your site and uses it for indexing and ranking. Content that exists only on the desktop version may not be considered. For that reason, the mobile version needs to carry everything you want indexed, from text and links to metadata and structured data.

How do I know if my site uses mobile-first indexing?

Open the URL Inspection tool in Search Console and check which Googlebot type crawled the page; a smartphone crawler indicates the mobile version is being used. Also review the crawl information in your settings. If you run separate mobile URLs, verify both versions as separate properties.

How do you make a website mobile friendly?

The simplest route is responsive design, which serves the same HTML on every device and is the setup Google recommends. Then confirm that text, images, metadata and links match across versions. Readable type, comfortable tap targets and a layout that needs no sideways scrolling complete the usability side.

Does mobile content have to match desktop?

It does not have to look identical, but the primary content you want indexed must exist on both versions. Google advises that the mobile site contain the same main content as desktop. Using accordions or tabs on mobile is acceptable for layout; removing content from mobile entirely is the real problem.

How do you find mobile usability problems?

Browse key pages in your browser's device mode and test them on a real phone. The live test in Search Console's URL Inspection shows how Google renders the page, and Lighthouse adds further hints. Treat every automated result as a lead to verify by hand, not as a final verdict.

Does lazy loading hurt SEO on mobile?

Not when it is implemented correctly; what matters is that content can load without scrolling, clicking or typing. Google advises against loading primary content only after user interaction, because Googlebot does not perform those actions. Standard lazy loading for below-the-fold images is usually fine.

Conclusion and Next Step

Mobile-first indexing turns the mobile version from a showcase into the primary source for the index. That means pinning down your configuration (responsive, dynamic serving or separate URLs) first, then comparing both versions on content, metadata, images, links and robots rules, and fixing findings template by template. Usability checks belong in their own round.

If the audit turns up thin descriptions, missing FAQ blocks or category intros, the writing services area is where you can order rewrites: pick a product, finish cart and payment, wait for seller approval and the delivery notification, and use the objection route if something goes wrong. Ordering content without knowing what is missing costs time, so fill in the parity table first.