Ecommerce SEO · Guide

Mobile SEO for Ecommerce Websites: What Store Owners Need to Know

The mobile version is the site. Indexing works from it, so anything hidden on mobile is effectively not on the page at all. Most shops still treat mobile as a reduced version of the real thing. That is now a ranking problem rather than only a usability one.

Updated: July 2026
Written by: Andrew Odgers, Managing Director
Reading time: 10 minutes
Not a second version

The Mobile Version Is The Site

Search engines look at the mobile version of your shop to decide what it contains. Not the desktop version with mobile checked afterwards. The mobile version, as the definitive account of what is on the page.

What that means in practice. One sentence with large consequences.

If something appears on desktop and not on mobile, it does not exist as far as search is concerned. Not diminished. Not weighted lower. Absent.

Why most shops have this backwards. The order things were built in.

Shops were designed on desktop for years, with a mobile version produced afterwards by removing what did not fit. That instinct survives, so the desktop version still feels like the real one while the version that counts is the other.

What it changes about decisions. Every removal becomes a deletion.

Taking something off the mobile layout to make it cleaner is not a presentational decision. It is a decision to remove that content from the page. It should be made with that understood.

The boundary worth stating. This page covers mobile as a search question.

Mobile as a build and conversion question sits in our ecommerce web design guides.

The one most shops fail

Content Parity

Content parity means the mobile version contains everything the desktop version does. Most shops do not have it. Most of them do not know.

The three ways parity gets broken. All of them look reasonable at the time.

Content removed. A block dropped from the mobile layout because it made the page long.

The most damaging and the easiest to spot, since somebody decided to do it.

Content collapsed. Text behind an expander, a tab or a read more control.

This is usually acceptable, provided the text is actually present in the page and merely hidden by styling. Where the content is only fetched once somebody taps, it is not present. That distinction is invisible from looking at the page.

Content shortened. A different, briefer version served to phones.

The shorter version is what counts, so a category page with four hundred words on desktop and eighty on mobile is a page with eighty words.

What this costs a shop specifically. The work you paid for.

Category content is the highest value writing on a shop, per our category page guide. It is also the first thing a designer removes on mobile, because a wall of text above a product grid is exactly what a phone layout should not have. Both parties are right. The resolution is placement rather than removal.

How to check your own shop. Two minutes, no tools.

Open a category page on a phone and read what is there. Then open the same page on a computer. If the phone has less, you have found it. That check is cruder than a proper audit and it finds this fault on a great many shops.

Designed for a screen you do not have

Navigation And Filters On A Phone

Faceted navigation is designed on a wide screen where filters sit permanently beside the products. On a phone that arrangement has nowhere to go. What replaces it is frequently worse than anybody realises.

What usually happens to it. It gets hidden behind a control.

Filters move into a panel that opens when tapped. Reasonable. It means a shopper on a phone has to know the filters exist, decide to look for them and then work through them without seeing the products change.

The commercial consequence. Filtering stops happening.

On a large catalogue, filtering is how somebody finds the right item. A phone visitor who does not filter is scrolling through a long listing instead, which they will not do for long.

The search consequence. Sometimes the links are not there.

Where a filter panel is built so its contents only exist after somebody interacts, the routes it provides may not be visible for indexing. On a shop where filters are a genuine navigation route, that can leave sections harder to reach than anybody intended.

What to look at. Whether the phone version offers the same routes.

Not the same arrangement, which is impossible. The same destinations, reachable. Our structure guide covers which filter routes should exist at all.

Not your phone, on your wifi

Speed On A Mobile Connection

Speed on a phone is a different measurement from speed on a desk. Testing it the way most people do produces a reassuring number that describes nobody's experience.

Why your own phone tells you almost nothing. Three reasons at once.

It is on your own wifi, which is fast. It is probably a recent handset, which is powerful. And it has visited your shop before, so much of the page is already stored on it.

What a real visitor has instead. A mobile connection of unknown quality, a device that may be several years old, no prior visit.

Every one of those makes the same page slower. The three compound rather than adding up.

Why the device matters more than people expect. Phones do work, not just receive pages.

A page arriving quickly still has to be assembled by the device. An older phone takes considerably longer over that than a new one, which is why a page can arrive fast and still feel slow.

How to test it usefully. Simulated conditions rather than your own.

Test on a slower connection and a mid-range device, then look at what real visitors actually experienced rather than at a single laboratory run. Our page speed guide covers that distinction properly.

What usually fixes it. The same things as everywhere else.

Images first, then scripts and applications. Mobile does not have a separate list of causes. It has less capacity to absorb them.

Briefly

Images On Mobile

Images are the largest weight on any shop. A phone is where that costs the most. Our image guide covers the subject in full.

What matters specifically on mobile. Two things.

Whether the phone receives a smaller file. A device with a narrow screen has no use for an image sized for a large monitor. Sending one wastes the visitor's data as well as their time.

Whether deferred images are actually present. Per the image guide, some implementations only place an image once a real person scrolls.

That matters more here, because a phone shows fewer products at once, so more of a category page is below the fold and more of it depends on deferral behaving properly.

The one to check first. The main product image.

It is on screen immediately and it is the thing the visitor came to see, so it should never be deferred.

Small, specific, frequently missed

Structured Data Parity

Markup present on the desktop version and absent from the mobile one is markup that does not count. It is a narrow fault with a disproportionate effect. Almost nobody checks for it.

Why it happens. Two ordinary causes.

A theme generating different templates for different screen sizes, where the markup was added to one of them. Or an application inserting markup that only loads on certain layouts.

Why it matters more on a shop. Because of what the markup describes.

Product markup carries price and availability. Losing it on mobile means losing the description of the things that most affect how a listing appears, on the version that decides what the page contains.

How to check. Test the mobile version specifically.

Most people validate markup once, on a desktop view, then assume it applies everywhere. Checking the same page as a phone would receive it is a separate test and it takes moments.

The rule that still applies. Structured data is an assertion about reality.

Parity means the same accurate markup in both places. It does not mean adding markup to mobile that was never true on desktop. Our structured data guides hold that position throughout.

The right pages, on the right thing

Testing Properly

Most mobile testing is done on the wrong pages, on the wrong device, in the wrong conditions. Fixing all three costs nothing.

Which pages. Not the home page.

It is the most carefully built page on the shop and the least commercially important. Test a busy category page, a typical product page. The basket, since that is where the money is and where the problems are.

Why category pages matter most here. They carry the most on a phone.

A grid of products, filters, pagination and whatever content survives from block two, all in a narrow column. If any page on a shop is going to fail on mobile, it is this one.

On what. A mid-range device on a mobile connection.

Per block four, testing on the newest phone on office wifi describes a visitor you do not have.

What to look at. Four things, in order.

Whether the content is all there per block two. Whether the products can be filtered per block three. Whether it loads acceptably per block four. And whether somebody can actually complete a purchase without frustration.

Who should do it. Somebody who did not build it.

Anybody who worked on the shop knows where everything is, which makes them unable to notice that a control is hard to find.

Five, all common

What Shops Get Wrong

A desktop layout squeezed down. Everything present, everything small.

Text at a size nobody can read, controls too close together to tap accurately. A table of specifications that requires sideways scrolling. Technically it works on a phone. Nobody would choose to use it.

Content collapsed behind tabs. Per block two.

Acceptable where the content is genuinely present and hidden by styling. A real problem where it is only fetched on interaction. The difference is invisible to anybody looking at the page.

The basket hard to reach. Moved to make room, so now nobody can find it.

On a phone the basket needs to be permanently visible. A shop that has hidden it inside a menu has put a step between the customer and the purchase for the sake of the layout.

Forms that fight the keyboard. Fields requiring the wrong keyboard, no autofill. A checkout that scrolls away from what somebody is typing.

This is where mobile purchases are lost. It is invisible to anybody testing with a saved card on their own device.

Interstitials. Anything covering the page on arrival.

Newsletter prompts, cookie banners occupying half a phone screen, application download requests. On a small screen these do not sit alongside the content. They replace it. They arrive before the visitor has seen anything to want.

Ecommerce SEO services

Four hundred words
on desktop. Eighty on mobile.

That is a page with eighty words, because the mobile version is the one that counts. Category content is the highest value writing on a shop and the first thing removed to make a phone layout breathe.

What is included every month:

Technical health and crawl Site structure work Quarterly technical audits Category page content Speed and mobile work Website management AI optimisation Social, two posts a week

£350 per month, one target area. No setup fee, nothing billed separately.

The full guide series

Twenty-two guides.
One subject.

This guide covers mobile. The rest of the series covers the sequence, structure, category and product pages, technical health, measurement and everything a store owner has to decide.

Questions people ask

Mobile on a Shop

Does the mobile version really matter more than desktop?
Search engines look at the mobile version to decide what your shop contains, so it is the definitive account of what is on the page. If something appears on desktop and not on mobile, it does not exist as far as search is concerned. Not diminished, absent. That makes any removal from a mobile layout a decision to remove that content from the page.
How do we know if we have a content parity problem?
Open a category page on a phone and read what is there, then open the same page on a computer. If the phone has less, you have found it. That check takes two minutes, needs no tools, then finds this fault on a great many shops. Parity breaks three ways. Content removed. Content collapsed so it only fetches on tap. A shorter version served to phones.
Is hiding text behind a read more link a problem?
Usually not, provided the text is genuinely present in the page and merely hidden by styling. It becomes a real problem where the content is only fetched once somebody taps, because then it is not present at all. The difference is invisible from looking at the page, which is why it survives on so many shops.
Why is testing on our own phone not good enough?
Three reasons at once. It is on your own wifi, which is fast. It is probably a recent handset, which is powerful. And it has visited your shop before, so much of the page is already stored on it. A real visitor has a connection of unknown quality, a device that may be several years old, no prior visit. Those three compound rather than adding up.
Can structured data be missing on mobile?
Yes. Almost nobody checks. A theme generating different templates for different screen sizes may have markup on only one of them. An application may insert markup that loads on certain layouts. On a shop that means losing price and availability descriptions on the version that decides what the page contains. Validating once on a desktop view and assuming it applies everywhere is the usual cause.
Which pages should we test on mobile?
Not the home page, which is the most carefully built page on the shop and the least commercially important. Test a busy category page, a typical product page and the basket. Category pages matter most, since they carry a product grid, filters, pagination and whatever content survives, all in a narrow column. Have somebody who did not build the shop do it.