A site can “have a mobile version” in 3 different ways. It may be a responsive site that reshapes itself, a separate mobile site with its own URL, or a desktop page that merely shrinks and hopes for the best. That last one is common.
Before you judge anything, define the target. If you are trying to answer how to check if a website has a contact page, you look for one kind of signal; here, you are checking screen behavior, navigation, and device handling. Different question, different evidence. Simple, but people mix them up.
A mobile version should do more than “open” on a phone. It should fit smaller screens, keep text readable, and preserve the main task without pinching and zooming. A hamburger menu alone does not prove much. Nor does a tiny desktop layout.
1. Define what “mobile version” means for your check
Start with one decision: are you looking for a separate mobile site, a responsive layout, or a mobile-specific experience such as an app prompt or a simplified menu? That single choice changes what you inspect first.
A separate mobile site often uses a different subdomain, such as m.example.com, or a distinct path. A responsive layout usually keeps the same URL and changes the page with CSS. A mobile-specific experience may still live on the same page, but it shows different navigation, fewer columns, or a prompt to install an app. Those are not the same thing.
If the site is old, the mobile version may be obvious. If it is newer, the mobile version may be hidden in the design rather than a separate address. Watch for that.
One practical clue: a site that changes only font size is not much of a mobile version. A site that changes its menu, spacing, media blocks, and form layout is doing real work.
2. Inspect the site from a desktop browser without switching devices
Open the page in a regular desktop browser first. Then narrow the window slowly, not in one jump. Watch what changes at 1200 pixels, then 1024, then 768. These numbers matter because many layouts break at those points.
Look for behavior, not style alone. Does the top navigation collapse into one menu? Do sidebars move under the main content? Does a large image become smaller without pushing the text off-screen? Those are signs that the site was built to adapt.
A site can pretend to be mobile-friendly by shrinking everything. That is not enough. The user still needs readable paragraphs, tappable buttons, and forms that do not need sideways scrolling.
Open a page with a long form. If labels overlap at a smaller width, the mobile version is weak. If fields stack neatly and the submit button stays visible, the mobile version is probably planned well.
For a quick cross-check, you can also compare structure with another page on the same domain, such as how to check if a website handles shipping policy content. Sites often keep policy pages more rigid than product pages, and the difference can reveal whether responsive rules were applied site-wide or only on the homepage.
3. Check the page source and CSS for mobile-related setup
View the source or open the developer tools. Search for the viewport meta tag. If you see width=device-width and a sensible initial scale, that is a strong signal that the site was built with mobile screens in mind.
Then inspect the CSS files. Responsive code usually includes media queries with breakpoints such as 768px, 1024px, or 480px. You do not need to read every line. One or two well-placed breakpoints can tell you a lot.
Look for mobile-focused assets too. An image file may have smaller versions for low-bandwidth screens. A navigation script may load only when the screen is narrow. A font may switch weight for readability. Those details matter because they show intent, not accident.
If the source uses fixed widths everywhere, be skeptical. Fixed layouts can still open on a phone, but that does not mean the site has a mobile version. It may simply be a desktop page squeezed into a smaller box.
Here is the point many people miss: source code can reveal mobile support even when the visual page looks plain. A clean page is not always simple under the hood. A messy page is not always broken.
4. Compare behavior at common mobile widths
Test a few standard widths in your browser. Try 375 pixels, 390 pixels, and 414 pixels for modern phones, then 768 pixels for a tablet-sized view. That range exposes most layout problems quickly.
At 375 pixels, check whether the content stays within the screen. At 390 pixels, check whether buttons are large enough for a thumb. At 414 pixels, look for empty side space or clipped banners. Those are small clues, but they add up.
A good mobile version reorganizes itself cleanly. A weak one simply gets smaller. There is a real difference between “fits” and “works.”
Try the same page in portrait and landscape. Sometimes the page behaves well in one orientation and becomes awkward in the other. A gallery may lock images too tightly, or a table may become unreadable. Tables are especially telling.
If a page includes a comparison table, turn the width down and watch the result. A proper mobile version may stack rows or allow horizontal scrolling in a controlled way. A poor one cuts off the last column. That is the kind of thing users notice fast.
5. Look for separate mobile URLs or device redirects
Older sites sometimes send phones to another address. You may see m.example.com, mobile.example.com, or a URL that includes /mobile/ or /amp/. Check the browser bar carefully after loading the page on a phone or in a narrow emulation window.
Device redirects can happen silently. A desktop user sees one page, while a phone user lands somewhere else. That can indicate a dedicated mobile version, but it can also mean the site has a legacy setup that was never modernized.
Pay attention to redirects that happen before the page fully loads. A quick jump from one domain to another often means the server is detecting device type. If the redirect ends at a stripped-down page, the site may have been built for older phones, not modern responsive screens.
Be careful with assumptions. A mobile-looking URL does not always mean the site is better on phones. Sometimes it means the site is older, slower, and harder to maintain.
One easy clue is consistency. If only the homepage redirects and inner pages do not, the mobile version is probably incomplete.
6. Test whether the site changes by user agent
Open developer tools and switch the user agent to a phone profile. Then reload the page. If the content changes, the site is serving different HTML or CSS to mobile devices.
This matters because some sites hide their mobile version behind device detection. On a desktop browser, they may show a full layout; on a phone user agent, they may show a narrower menu, different images, or even different text blocks. You cannot see that by resizing alone.
Try at least two user agents: one modern iPhone profile and one Android profile. If the site behaves differently between them, note the exact difference. A change in navigation is meaningful. A change in analytics scripts is not enough.
If the page breaks only under one user agent, the mobile version may have been patched for specific devices instead of built well. That is a maintenance smell. It can also create odd bugs that appear only on certain phones.
For a separate check on site structure, you can compare it to how to check if a website handles terms of service pages. Legal pages are often less responsive than product pages, so they are useful for spotting partial mobile support.
7. Check public web archives and search snippets for past mobile variants
Public archives can show whether a mobile version existed before. Search the site in the Wayback Machine or another archive and inspect snapshots from several years, not just one. A 2018 mobile page can tell a story that a 2026 homepage hides.
Archived URLs may reveal old mobile subdomains, device-specific redirects, or separate templates. Search snippets can help too. If indexed results show a mobile path or AMP page, that suggests the site once exposed a mobile version publicly.
Do not overread one snapshot. Archives can miss stylesheets, scripts, or images. Still, if three different snapshots show a phone-specific URL pattern, that is strong evidence.
You can also compare cached text around a page title. If search results once displayed a short mobile title and now show a long desktop title, the site likely changed its presentation over time.
There is a practical reason to check archives: some sites remove a mobile version without cleaning old links. Users arrive from search or bookmarks and land on dead mobile paths. That is the sort of problem that stays hidden until someone tests it.
8. Decide what kind of mobile support the site actually has
By this point, you should be able to name the result in one sentence. Say whether the site is responsive, uses a separate mobile version, or has little to no mobile optimization. That sentence should be backed by 3 concrete observations, not a guess.
A responsive site usually keeps one URL, shows clear breakpoints, and adapts navigation at smaller widths. A separate mobile version usually uses a distinct URL or user-agent redirect. A weak mobile setup usually scales the desktop design down, cuts off content, or leaves forms hard to use.
If you need a quick reporting template, use this order: URL pattern, layout behavior, and source-code evidence. Three items. No more needed for a basic report.
For example: “The site is responsive. It keeps the same URL, uses a viewport tag, and shifts the sidebar under the main content at 390 pixels.” That is clear, short, and testable.
If you need to document an older site for reference, keep the note precise. Mention the exact mobile path, the device behavior, and the width where the layout changes. A vague line like “works on phone” helps nobody.
One last check: if the site only offers a mobile menu but still hides key content behind tiny links, that is not a strong mobile version. It is just a mobile menu. Those are different.
