Compare Rendered Mobile and Desktop Content, Not Just Screenshots

A mobile–desktop SEO comparison is not primarily a visual QA exercise. The useful question is whether each renderer receives the same substantive page: the information that answers the query, the links that make other URLs discoverable, and the directives that control indexing.

Google uses a site’s mobile content, crawled with its smartphone agent, for indexing and ranking. Mobile and desktop layouts do not need to be pixel-identical, but Google advises keeping primary content, meaningful headings, metadata and structured data equivalent (Google Search Central).

Compare three page states

For each URL, distinguish among:

1. Initial HTML: the server response before JavaScript runs.
2. Desktop rendered DOM: the document after scripts run in a desktop browser context.
3. Mobile rendered DOM: the document after scripts run with the intended mobile viewport and user agent.

The DOM is the main comparison surface. A screenshot can reveal a blank module or broken layout, but it cannot reliably show whether an internal link has an href, an indexing directive changed or useful text exists in a collapsed section.

Googlebot parses links in the initial HTML response, renders the page, parses the rendered HTML for links again and uses the rendered HTML for indexing (Google’s JavaScript SEO guide). Comparing the initial response with both rendered states helps identify whether a defect begins at the server, in shared JavaScript or only in one device context.

This is separate from a mobile PageSpeed score investigation. Performance matters to users, but a strong score does not prove that mobile Googlebot received the full article, product information or internal-link path.

A repeatable comparison workflow

1. Choose representative URLs

Start with at least one URL from each important template and rendering pattern rather than crawling the entire site immediately:

• homepage and main navigation;
• service or product page;
• article or resource page;
• location page, if applicable;
• category or listing page;
• JavaScript-heavy page with filters, tabs or accordions;
• page containing structured data;
• page with a form, booking link or demo CTA.

Use the same state for both renders: logged out, same locale, same cookie choice and no personalized data. Otherwise, expected personalization can look like a rendering defect.

2. Capture the initial response and both rendered DOMs

In Chrome DevTools, open Network, reload the page and select the main document request. Save its Response content as the initial HTML and inspect its response headers. The DOM will not expose HTTP-level directives such as X-Robots-Tag.

Next, load and inspect the desktop page. Then enable the device toolbar, select a representative mobile device and reload. Reloading matters: a viewport resize can trigger responsive CSS, but a dynamically served site may return different HTML according to the user agent. Responsive sites normally serve the same URL and HTML; dynamic serving uses the same URL but varies the response (Google’s mobile-site guidance). Check the main document request to confirm which response was served.

Chrome calls Device Mode a first-order approximation, not a real phone. Confirm device-specific failures on physical hardware when they depend on the operating system, browser or touch behavior (Chrome DevTools).

After each render, run this in the Console and save the returned object:

(() => {
const clean = value => (value || '').replace(/\s+/g, ' ').trim();
  const text = node => clean(node?.textContent);

  return {
    url: location.href,
    title: document.title,
    description: document.querySelector('meta[name="description" i]')?.content || '',
    canonicals: [...document.querySelectorAll('link[rel="canonical" i]')]
      .map(node => node.href),
    robotsMeta: [...document.querySelectorAll(
      'meta[name="robots" i], meta[name="googlebot" i]'
    )].map(node => ({ name: node.name, content: node.content })),
    headings: [...document.querySelectorAll('h1,h2,h3')]
      .map(node => `${node.tagName}: ${text(node)}`),
    bodyText: text(document.querySelector('main') || document.body),
    links: [...document.querySelectorAll('a[href]')]
      .map(node => ({
        text: text(node) || clean(node.getAttribute('aria-label')),
        href: node.href
      })),
    images: [...document.querySelectorAll('img')]
      .map(node => ({ src: node.currentSrc || node.src, alt: node.alt })),
    structuredData: [...document.querySelectorAll('script[type="application/ld+json"]')]
      .map(node => node.textContent)
  };
})()

The script uses textContent, not innerText, so text already present in a collapsed accordion is not mistaken for absent content. Check visible states separately for user experience. Chrome’s Elements panel shows the DOM and lets you search it by text, selector or XPath (Chrome’s DOM documentation).

3. Diff meaning, discovery and indexing

Normalize whitespace, remove known volatile values and compare text plus sets of destination URLs. Do not require byte-for-byte HTML equality.

Compare	Difference worth investigating
Primary copy	Mobile lacks specifications, service details, prices, locations, evidence or answers available on desktop
Headings	Mobile loses or replaces headings that define the page’s subject
Internal links	Relevant product, service, article or location destinations disappear, or controls do not use crawlable anchors with href attributes
Indexing controls	Robots directives, canonical declarations or HTTP indexing headers differ unexpectedly
Structured data	Mobile markup is missing, materially different or inconsistent with visible mobile content
Images and video	Important media, alt text, captions or stable resource URLs disappear
Conversion paths	A demo, booking, quote or contact destination is absent or changes—a commercial defect even when it is not directly an indexing issue

A hamburger menu can replace desktop navigation, columns can stack and sections can move into tabs or accordions. Google permits different mobile design when the underlying content remains equivalent. The important limit is content loaded only after a click, swipe or typed action: Google says it will not perform those interactions to trigger lazy loading (mobile-first indexing guidance).

Ignore generated class names, timestamps, analytics parameters and test IDs unless they change meaning or behavior. Investigate missing content first; cosmetic DOM differences are usually lower priority.

4. Check what Google renders

A local Chrome test shows what your browser received, not what Google received. For a URL you control, open Search Console’s URL Inspection tool, run Test live URL, then review the tested page’s screenshot, HTML, loaded resources, JavaScript output and HTTP response information. The indexed report separately shows whether the last indexed version was crawled with a mobile or desktop agent (URL Inspection documentation).

Search the rendered HTML for diagnostic items instead of accepting a successful status alone:

• a distinctive sentence from the main answer;
• a key product, service or location link;
• the primary conversion destination;
• canonical and robots directives;
• expected JSON-LD properties.

Review failed or blocked resources and JavaScript exceptions. Google recommends the URL Inspection tool or Rich Results Test for examining the rendered DOM, loaded resources and console output when debugging JavaScript search problems (Google Search Central). A successful live test indicates potential indexability; it does not promise indexing, visibility or rankings.

Use parity as a release check

For a small site, retain the exports and a short defect log. For a larger site, automate the extraction in desktop and mobile browser contexts. Flag unapproved changes to titles, canonicals, robots directives, required copy, internal-link destinations or structured-data types.

Maintain an allowlist for intentional presentation differences, test representative URLs from each template before release, and repeat the Google-render check on production afterward. The objective is not a perfect similarity score. It is evidence that the mobile version preserves the content and crawl paths on which search discovery depends.