What technical SEO means for a store
Technical SEO is everything that decides whether search engines can find, read and sensibly file your pages. It has nothing to do with how good your writing is. A store with excellent product pages and a technical fault that hides them from Google gets no traffic from them.
Stores have a harder version of this problem than most sites. A blog has a few hundred pages that stay put. A store has thousands of pages that change daily: products appear, sell out and return, and filters create new URLs every time someone ticks a box. Every one of those is a chance for something to go wrong quietly.
This page covers the technical layer. If you want the full list of checks, our ecommerce SEO audit page shows how an audit works, and the ecommerce SEO checklist gives the broader list. Here we explain the ideas behind the biggest items so that you can judge advice you are given.
The order to work in
Technical problems are not equal. Fixing a minor one while a major one stands is wasted effort, so the order matters.
First, can search engines reach and index the pages that matter? If key pages are blocked, noindexed or unreachable, nothing else counts. This is the base of the pyramid below.
Second, are duplicates under control? Stores generate duplicates by design. Variants, filters, sorting and tracking parameters all create near-identical pages. Search engines have to guess which one matters, and sometimes guess wrong.
Third, is the store fast enough on a phone? Speed affects both ranking and whether a visitor stays. The theme, images and add-ons are the usual causes.
Fourth, is the data machine-readable? Structured data tells search engines and AI assistants the price, availability and rating of a product. It is valuable, and it only helps once the earlier layers are in place.
The sections that follow take these in order.
Crawling and indexing: the base
Crawling is when a search engine visits your pages. Indexing is when it stores them so they can appear in results. A page can be crawled and not indexed, and that is common on stores.
Four things control this.
The sitemap. A file listing the URLs you want indexed. Most platforms generate it automatically. Check that it lists real, live product and category pages and not redirected, deleted or filtered URLs. Our glossary entry on the XML sitemap explains the format.
The robots file. It tells crawlers which areas to stay out of, such as the cart and checkout. A single wrong line can block an entire section, so after any theme change or migration, read it.
The noindex tag. A page with this tag asks to be left out of results. It is correct for internal search results and thank-you pages. It is a disaster on a category page, and it sometimes gets left on after a staging site goes live. See the glossary on noindex.
Redirects and errors. Deleted products that return an error, and chains of redirects that pass through several steps, waste crawl time and lose visitors.
Google Search Console reports which pages are indexed and why others are not. Start there.
Faceted navigation: filters that multiply pages
Faceted navigation is the set of filters on a category page: size, color, brand, price range. They help shoppers. They can also cause a serious technical problem.
Each combination of filters can create a separate URL. A category with five filters, each with several options, can produce thousands of URLs that show nearly the same products in a different order. Search engines can spend their time crawling those instead of your real pages, and they may index junk pages that compete with each other.
The choices come down to deciding which filtered pages deserve to exist in search.
- Pages with real search demand, such as "red running shoes", are worth keeping crawlable, with their own title and a line of useful text.
- Pages with no demand, such as a category sorted by price with three filters applied, should be kept out of the index or kept from being crawled.
The tools for this are canonical tags, noindex and robots rules, and the right choice depends on the platform. The principle is the same everywhere: let search engines see the pages a buyer would search for, and steer them away from the rest.
For very large catalogs this becomes a question of budget and governance. That topic is covered on our page about enterprise ecommerce SEO.
Canonicals and variants
A canonical tag tells search engines which URL is the main version of a page when several show the same content. The glossary entry on the canonical URL covers the mechanics.
In a store, canonicals matter in three situations.
One product, several paths. If a product can be reached through a collection path and directly, the canonical should point to one agreed version.
Variants. A shirt in six colors might be one page with a selector or six separate URLs. If it is six, decide whether each deserves to rank on its own. If people search for "navy linen shirt", a separate page may earn its keep. If the pages differ only by a swatch, point them to one canonical.
Tracking and sorting parameters. URLs with extra text after a question mark, from campaigns or sorting menus, should point back to the clean version.
A common mistake is a canonical that points to the wrong page, for example every product pointing to the category. That tells search engines to ignore the product. After any template change, open a handful of pages and read the tag.
Pagination and speed
Pagination splits a long category into pages, so page two lists products eleven to twenty, and so on. It exists to keep pages light. The risk is that products on deep pages are hard for crawlers to reach, and "load more" buttons that need a script to work can hide products entirely.
Keep paginated pages reachable through ordinary links. Give each page its own canonical, pointing at itself and not at page one. Make sure the important products are not buried five pages deep with no other link to them.
Speed on a store comes mostly from four sources: large images, a heavy theme, too many apps or plugins and slow third-party scripts. Google's free PageSpeed Insights shows each page's loading performance on a phone and lists the biggest causes. Our page on ecommerce site speed and SEO goes through the fixes in detail.
The best first step is to compress and properly size product images, since they are usually the heaviest item on the page. The second is to remove apps you no longer use. Each one often adds code to every page, even after you stop using it.
Structured data for products
Structured data is a block of code on a page that states facts in a form machines read easily: this is a product, it costs this much, it is in stock, and it has this rating. Search engines use it to show prices and star ratings in results, and AI assistants can use it to read your catalog accurately.
The key fields for a product are the name, description, image, price, currency, availability and, if you have genuine reviews, the rating. Most platforms and themes add some of this automatically. The trouble is that what they add can be incomplete or out of date. A product shown as in stock in the markup when it has sold out is a trust problem.
Check three things. Is the markup present on product pages? Does it match what is visible on the page? Does the tool reading it report errors? Google offers a free Rich Results Test for this.
Our pages on schema markup for ecommerce and the glossary entry on schema markup go deeper into the fields.
Out-of-stock pages and template-level faults
Two areas catch stores out regularly.
Out-of-stock pages. What you do with a product that has sold out depends on whether it is coming back. Deleting the page, redirecting it, keeping it live with a notice and marking it noindex are all valid in different cases. The decision tree is on our page about out-of-stock products and SEO, so we will not repeat it here.
Template faults. Because a store builds thousands of pages from a few templates, one error in a template repeats on every page. A missing title tag pattern, a noindex left in a template, a canonical pointing the wrong way or a heading structure that uses the store name as the main heading on every page can each affect an entire catalog at once.
This is why technical review is worth doing after any theme change, migration or major app install. The cost of checking is small, and the cost of an unnoticed template fault can be months of lost traffic across thousands of pages.
What you can check yourself this week
You do not need to be a developer to find the big problems. Five checks, all with free tools.
- In Google Search Console, open the pages report and read the reasons pages are not indexed.
- Open your sitemap address and confirm it lists current product and category pages.
- Read your robots file at yourstore.com/robots.txt and confirm it does not block product or category folders. See what robots.txt does.
- Run your five best-selling product pages through PageSpeed Insights on mobile.
- View the source of a product page and look for a noindex tag you did not expect.
If these turn up something odd and you are not sure what to do, that is the moment to ask for help. Our guide to who should own the technical fixes on your store sets out whether that is a developer, a specialist or a service, and what each is good for.
Mobile, international and other multiplying factors
Two more things make store technical SEO harder than it first looks.
Mobile first. Google generally uses the mobile version of a page to decide how it ranks. If your phone layout hides content that appears on the desktop, such as a description tucked behind a tab that never loads, the hidden content may count for little. The glossary entry on mobile-first indexing covers the details. Check that product text, images and links on the phone version match the desktop.
Several countries or languages. A store that serves different regions needs to tell search engines which version is for whom, and avoid creating near-copies that compete. This is a specialist topic and a common source of duplicate content. If you sell in more than one country, plan the URL structure before you build, not after.
Both come down to the same principle. A search engine has to be able to see the same useful page that a shopper sees, and has to be told clearly which of several similar pages to prefer.
When technical problems usually appear
Most serious technical faults arrive with a change, not out of nowhere. Knowing the usual triggers tells you when to check.
A new theme or redesign. Titles, headings and structured data often live in the theme. A redesign can drop them without anyone noticing.
A platform move or domain change. Every URL needs a redirect, and every template needs checking.
A new app or plugin. It may add scripts, create URLs or alter titles.
A bulk import. A product upload can create duplicates, blank titles or wrong categories at once.
A staging site going live. A noindex tag meant to keep a test site out of search sometimes goes live with it.
For each of these, build a short check into the process: open ten representative pages, read the title and canonical, check the Search Console pages report a week later, and compare clicks to the same week the month before. Catching a fault in a week instead of a quarter is the single most valuable habit in technical SEO.
How RunOctopus handles this
RunOctopus is a done-for-you service for the content side of search. Its AI, Ollie, researches your business, then writes and publishes pages directly on your own website, with a team planning, writing, reviewing and publishing alongside it. It works with Shopify, WordPress, WooCommerce and Wix.
Nothing to install, approve, upload or schedule. Pages go live on their own, and the first week brings 8 long-form articles, 6 pages and a custom interactive tool for your niche. After that, 175+ pieces of content a month are written, published and linked. Reports show where ChatGPT, Perplexity, Claude and Gemini name your business.
It is not a replacement for a developer when your theme has a deep structural fault. It is the part that keeps new, useful pages going onto a store whose technical basics are sound. The free site read reads your site and shows what Ollie would do. No account, no call.