A mobile page can look different while using exactly the same HTML as desktop. It can also receive different HTML from the server. Those architectures need different checks when a category link or product description disappears on a phone.
Responsive design adapts the layout using CSS and viewport conditions. Dynamic serving changes the response, often using information about the requesting client. A separate mobile URL is another architecture again.
Separate viewport from response
Open the page in Chrome’s device toolbar and change the viewport width. Watch how columns, menus, and images adapt. Then inspect the request and returned HTML.
Changing the width does not always change the user-agent string. Changing the user-agent string does not necessarily reproduce a real phone’s browser capabilities. Record both when a server chooses output based on the request.
A responsive page commonly includes:
<meta name="viewport" content="width=device-width, initial-scale=1">
This supports the intended mobile viewport behaviour. It does not by itself make a fixed-width table or navigation component responsive.
Compare useful content, not identical pixels
Choose representative templates: homepage, category, detail page, and an article if the site has one. Compare the main text, product or listing information, navigation destinations, and relevant metadata.
A mobile accordion can contain the same useful content in a more compact interface. A description omitted entirely from the mobile output is a different finding. Inspect the DOM and interaction before deciding which case applies.
For e-commerce SEO, compare category descriptions, product details, variant controls, and pagination. For classifieds and marketplaces, include location routes, listing cards, and contact controls that change between devices.
Check links and indexing signals
Confirm that mobile navigation uses working destinations. Review canonical and robots output on the received version. If language versions exist, verify that the mobile response retains the intended alternate references.
Google’s mobile-first indexing guidance is relevant when differences affect the content Google receives. Do not infer parity just because both versions return 200.
Validate the current rendered version
Use user-agent testing for a controlled response comparison. For an indexing investigation, compare the available rendered output in URL Inspection with the browser’s output. Keep the stored crawl date separate from the date of a live browser test.
If the difference appears only after JavaScript runs, investigate the relevant component and its data requests. If the difference is already present in the document response, focus on server-side serving and cache behaviour first.
Recheck after shared component changes
Retest narrow and wide layouts with the same content examples. Include long titles, empty result sets, and a populated collection so the component is exercised beyond the simplest case.
In a technical SEO audit, this becomes a page-type comparison with exact missing elements and response conditions. The development ticket should say what must remain available on mobile and how to verify it, rather than simply asking for “mobile optimisation.”