Online shop SEO

How we measure progress in shop SEO

We report indicators that can be attributed to the work on visibility. We do not promise specific positions, because they depend on competitors and on Google’s decisions. We show changes in four areas, the same way every month.

Keywords in the top 10

We track a set of keywords agreed at the start: general category keywords, keywords with brands and attributes, and selected product keywords. The report shows how many of them are in the top ten results and how that number changes over time.

Category visibility

We group Search Console data by page type: categories, subcategories, products, guides. You can see which groups gain impressions and which lose them, and for which keywords.

Indexing status

We measure the number of indexed categories and products, the number of URLs excluded from the index and the reasons for exclusion. After the filters and duplicates are tidied up, the number of URLs in the index should move closer to the number of pages that are meant to be there.

Presence in AI answers

We repeat the set of customer questions in ChatGPT, Gemini, Perplexity and Claude. We report how often the shop is named, in what context and which pages are cited.

How to read the results

Google takes changes into account after it recrawls and reprocesses the page. With a large number of URLs this can take longer, but crawl frequency and server performance also matter. We therefore base the assessment on several consecutive reports. A single month can mislead. We record the starting position before the first implementations, so that comparisons have a reference point. When a shop needs a one-off diagnosis before work is planned, we provide it as part of an SEO and GEO audit.

How online shop SEO differs from SEO for a company website

A shop with a broad range can have thousands of product and category pages, plus extra URLs generated by filters, variants and internal search. That is why SEO for a shop starts with the question of which URLs should be in Google’s index at all, and only then moves on to keywords.

The second difference is content. A shop has no single article that collects the rankings. High-value keywords land on category pages, and keywords for a specific model land on product pages. Each of these page types has a different job, a different search intent and different ways of being optimised.

The third difference is change. The range moves, products disappear, new variants appear, and the shop platform generates URLs by its own rules. Without agreed rules, problems build up in the background: duplicates, empty categories, URLs with no content. SEO for a shop is therefore an ongoing check on these processes and needs a regular return to the data.

• Category pages answer general searches, for example “women’s trekking boots”.
• Product pages answer searches for a specific model, variant or catalogue number.
• Supporting content, such as guides and comparisons, answers questions asked before the buying decision.

How to build a category structure that matches searches

A shop’s category tree is sometimes organised around the warehouse, the purchasing department or a wholesaler’s catalogue. Customers type different words into Google than the ones in the stock system. The first step is therefore to collect the keywords people use to search for products and match them to the existing categories.

One keyword, one page

For each important keyword we choose one page that should answer it. When two categories, or a category and a filter, answer the same search intent, we check whether this makes it harder to send the customer to the right page. We find such cases in Search Console data: the same keyword appears on several URLs and none of them holds a stable position.

Missing categories

A common case: customers search for products by brand, size, material or use, and the shop has only a filter that has no URL of its own in the index. We then create a dedicated category page, or set up the filter so that its URL is indexed. The decision depends on whether the keyword has real search volume and whether the range holds enough products for the page to make sense.

Depth and names

Deeply nested categories can be harder to discover, especially when few internal links lead to them. We aim to make important categories reachable from the main menu or from a parent category. Category names should be the customer’s everyday words. Internal abbreviations and trade names from the wholesaler stay in the system.

Empty and nearly empty categories

An empty category does not help people looking for products, and we assess a category with one product separately, depending on the query and the page content. For such pages we choose one of three solutions: fill out the range, merge the category with a related one, or keep it out of the index until it is filled. The choice depends on whether the category has a future in your offer.

Filters, sorting, pagination and faceted navigation

Faceted navigation is the set of filters a customer uses to narrow a product list: colour, size, price, brand. When filters store their state in URL parameters or the path, their combinations can create a very large number of URLs, including pages with similar content. The scale depends on the number of filters, their values and the implementation. Crawling unnecessary combinations can delay the discovery of more important pages. Google may also treat some of these URLs as duplicates and choose a different canonical version for them.

Which filter URLs to index

Our rule: a filter URL deserves indexing when it answers a search people really type and has enough products. For example, “grey corner sofas” may be such a search. The combination “sofas, colour grey, price 1200 to 1800, sorted cheapest first” is not.

• Filters that match real searches get a fixed, readable URL, with their own title, heading and description.
• The remaining combinations are kept out of the index or out of crawling.
• Sorting, list views and session parameters should not create separate indexed pages.

Canonical, noindex and robots.txt: what each is for

These three mechanisms work differently and do not replace one another.

• rel=canonical tells Google the preferred URL among similar pages. It is a hint, not a command: Google can ignore it when the pages differ in content. The filter URL is still crawled.
• noindex asks for the page not to be included in the index. The crawler still has to load the page to see the directive, so it does not save crawl budget in the first place.
• A robots.txt block stops the crawler from entering the URL. It saves crawling, but a blocked page passes on no signals, and Google will see neither noindex nor a canonical on it. A URL with external links can still appear in the index without a description.

The choice depends on the goal. When several URLs show the same or very similar content, we point to the main version with a redirect or a canonical. Google advises against using noindex to choose the main version, so we use noindex for pages that should stay available to customers but should not appear in results. When the aim is to limit crawler traffic across millions of combinations, we use a robots.txt block for parameter patterns that are not in the index.

Pagination

Google no longer uses rel=prev and rel=next, so every page of a list must make sense on its own. The rules we implement:

• Each list page has its own URL and a canonical pointing to itself. Google treats the following pages of a list as separate pages and advises against using the first one as the canonical page.
• Links to further pages are ordinary links in the code. A button run by a script is not enough for the crawler.
• Where more products load as the user scrolls, a version with numbered URLs must exist, because the crawler does not scroll the list.
• The title and description of a category, with its SEO text, go only on the first page of the list.

How we check the effects

We compare the number of URLs crawled, indexed and present in the sitemap. The Page indexing report in Search Console shows the reasons for exclusion from the index. We compare the URLs in the index with the list of pages that should be there: categories, products, guides and agreed filter pages. Only an analysis of specific URLs shows whether unnecessary combinations remain in the index.

Product pages: descriptions, variants and unavailable products

Product description

A good product page answers the questions a customer would ask a sales assistant: what it is made of, what it is for, what size it is, how it differs from a similar model, what comes in the box. We present the information so it can be scanned quickly: a short description, a list of parameters in a clear table, and a separate description of uses. The title contains the product name and the feature that distinguishes the variant. A list of keywords separated by commas is not a title.

There is no point in writing individual descriptions for every item in the catalogue. We start with products customers actually search for on Google and with those with the highest margin or turnover. The rest get carefully prepared data and descriptions completed from a template.

Variants: colour, size, capacity

Variants can be separate pages or options on a single page. Both approaches work as long as they are implemented consistently.

• One page with a choice of options collects signals in one URL. It works when variants differ mainly in colour or size. Each variant still has a URL that identifies it, for example with a colour parameter.
• Separate variant pages make sense when people search for them separately, for example different capacities or versions with different specifications. Each then gets a unique title, description and data.
• When variants are options on one product page, we set its main URL as canonical. With separate variant pages, we set canonicals according to their content and the implementation.

Unavailable, discontinued and removed products

The URL of a product that leaves your range holds history: links, visits from search, saved bookmarks. What to do with it depends on the situation.

• Temporarily out of stock: the page stays, with clear information about availability. In the structured data, availability is marked to match the actual state, and the customer can sign up for a notification or see similar products.
• Discontinued, with a successor or a close equivalent: a 301 redirect to the successor’s URL. The redirect must lead to a page with a similar meaning.
• Discontinued, with no equivalent: a redirect to the parent category if the category is a sensible substitute, or a 404 or 410 status when there is no such page. Redirecting removed products in bulk to an unrelated home page may be treated by Google as a soft 404, and the customer lands on a page they were not looking for.
• Seasonal product: the page stays all year, to keep its history and return to searches in the next season.

We record these rules in a document for your shop team, so that anyone who discontinues a product knows what to do with the URL.

Content on category pages

Category pages can answer general queries about groups of products. Yet some categories consist only of a product grid and a name, with no text. Google judges what such a page is about from the product names, so good text helps match it to searches.

What category text should contain

• A short introduction above the product list, showing the buyer they are in the right place.
• A description of how to choose: which criteria to use when picking products from this category, how the types differ, what to look out for.
• Answers to customers’ most common questions, based on conversations with your customer service and on data from the internal search.
• Links to subcategories, related categories and guides.

Where to put the text

Longer text should not push products below the first screen. We place a short introduction above the list and the longer text below the product list. Both parts must be visible to the crawler in the page code, even if expanding the text is handled by a script on the user’s side.

What to avoid

We do not copy the same text into many categories with only the name swapped. We do not stuff keywords into the footer or into hidden blocks. The text should help the customer choose, and its length follows from how much there is to say about the category. A category with a few products does not need several thousand characters.

The page title and the description in search results also need work: the title contains the category name and an element that sets your shop apart, and the description says in one sentence what the customer will find in the category.

Duplicate content in a shop

Duplication in a shop has several sources, and each needs a different solution.

Manufacturer descriptions

A manufacturer or wholesaler often supplies the same descriptions and photos to many shops. Such a description does not make the offer stand out on its own, and Google also assesses the rest of the page. This is not a penalty. It means a page with someone else’s description is one of many and finds it hard to stand out. The solution is to add your own content: a description of uses, notes from the shop’s experience, a comparison of variants, answers to customer questions, your own photos or extra shots.

The same product in several categories

A product assigned to several categories can have several URLs, for example with different category paths in the address. We set one main URL. The others either do not exist or point to it as the canonical. Internal links in all categories then lead to the main URL, so signals do not spread across copies.

Other sources

• URL versions with and without a trailing slash, with and without www, and with tracking parameters.
• Internal search result pages that the crawler can reach.
• Print versions, comparison pages and wish lists.
• Regional, currency or untranslated language versions with the same main content.

We detect these cases by comparing a crawl of the site with indexing data. For each group of duplicates we decide which URL stays, and set up a redirect or a canonical.

Product structured data and breadcrumbs

Structured data is markup in the page code that describes its content in a form machines understand. For a shop, two types matter most: Product and BreadcrumbList. The recommended format is JSON-LD.

Product

The Product markup describes a product: its name, images, description, identifiers, brand, and an offer with price, currency and availability. The rules we keep to:

• The data in the markup must match what the user sees on the page. The price and availability in the code are the ones shown on the page.
• Ratings and reviews are marked up only when they are genuine customer reviews visible on the page.
• Identifiers such as GTIN or the manufacturer’s part number are filled in wherever we have them, because they help match the product to data about it in other sources.
• For variants, each variant has data matching its own price and availability.

Correct markup lets Google show the price, availability and ratings next to a result. Whether these elements appear is Google’s decision. We validate the data in the Rich Results Test and check the reports in Search Console.

Breadcrumbs

The BreadcrumbList markup reflects the path: home page, category, subcategory, product. Breadcrumbs help the customer and the crawler understand where the page sits in the site, and Google can show them in results instead of the URL. The path should be consistent: a product in several categories shows one path, matching the main URL.

Data that shops often leave out

• Organization markup with the name, logo and company profiles, which helps Google recognise the shop and tell it apart from other organisations.
• Returns and shipping policies in the offer data, where the platform allows it.

Internal linking in a shop

Internal links tell the crawler which pages are important and how they relate to each other. In a shop the menu does most of this work, but the menu rarely does enough.

Menu and parent categories

The main menu should lead to the categories with the greatest search potential, not to all of them in turn. We assess a large menu by whether it helps customers and crawlers find the important categories. We link subcategories from the parent category with ordinary links in the code.

Related products and categories

Sections such as “similar products”, “bought together” and “from the same series” give product pages links to related URLs. They make it easier to find products that no main-level category links to. Pages with no internal links at all, known as orphans, are detected in a crawl and compared with the sitemap.

Links from content

Guides, comparisons and category descriptions link to the products and categories mentioned in the text. The anchor describes where the link leads, for example “women’s trekking boots” instead of “click here”.

Breadcrumbs and filter links

Breadcrumbs add links to parent categories on every product page. Filter links that are not meant to reach the index should not look to the crawler like ordinary links to important pages. How they are handled depends on the platform and on the indexing rules set earlier.

What to check

• The number of clicks from the home page to important categories and products.
• Links pointing to redirected or removed URLs.
• Product pages with no incoming links from a category.
• Categories reached only through the menu.

Shop performance and Core Web Vitals

Core Web Vitals are three measures of how a page feels to use: the time to render the largest content element (LCP), the speed of response to a click, tap or key press (INP) and layout stability (CLS). Good results are at most 2.5 s, 200 ms and 0.1 respectively, for 75% of visits. In Search Console the data comes from real visits by Chrome users. In a shop all three are easy to make worse.

Typical sources of problems

• Product images. Large files in the wrong format delay LCP. Sizing images to the space they fill, using modern formats and lazy-loading images below the first screen all help. We load the main image above the fold immediately.
• Third-party scripts. Analytics tools, review widgets, chats, consent banners and marketing plugins load the browser and worsen INP. We review them for what is really needed.
• Elements that shift the layout. Banners, promotion bars and pop-ups that appear after loading push the content around and worsen CLS. We reserve space for them in the layout.
• Filters and lists. Refreshing a list after a filter is chosen, when overloaded with scripts, slows the page’s response.
• Server response. Slow generation of category pages with many products, a missing cache or overloaded hosting delays everything that happens afterwards.

How we measure

We use field data from the Core Web Vitals report in Search Console and lab tools that point to specific elements. We assess page types separately: categories, products, the basket. Results for the home page say nothing about a product page. We write tasks for the developer so that they know which element to fix and on which page.

Shop platforms and SEO options

The shop platform determines which URLs the shop creates, how it handles filters and variants, whether it lets you edit titles and descriptions, what structured data it generates and how fast it runs. We assess a platform by the tasks a specific shop needs. First we check which of them can be done on the current setup.

What we check on every platform

• Whether you can edit the titles, descriptions and headings of categories, products and filters.
• Whether filter and sorting URLs can be controlled: indexing, canonical, noindex.
• How the platform handles duplicated URLs, for example a product in several categories.
• What structured data it generates by default and whether it can be corrected.
• Whether the sitemap updates automatically and includes only URLs meant for the index.
• Whether redirects can be added one by one and in bulk.
• Which scripts and plugins it loads by default and how much they weigh on the page.

When the platform becomes a limit

Only when high-impact tasks cannot be carried out despite a developer’s work do we consider changing the solution. We prepare such a decision on the basis of a list of specific limitations and their effect on visibility. If a change is justified, the process is described in the guide to site migration.

Showing products on Google through Merchant Center

Google Merchant Center is the tool where a shop submits data about its products. Based on that data, products can appear in results in the Shopping tab and in other places on Google. Showing products in these places does not require paying per click. It is a separate visibility channel alongside the standard search results, where we optimise category and product pages.

Where Google gets product data

The data can be submitted in a product feed or provided in structured data on product pages. A feed gives full control over what reaches Google, while structured data lets Google read the information directly from the page. In both cases the data must match what the customer sees on arrival: price, availability, product condition.

What we check

• Consistency of price and availability between the feed and the product page.
• Completeness of attributes: title, description, image, brand, product identifier.
• The quality of product titles: name, brand and distinguishing features, instead of a generic name.
• Error messages and warnings in the Merchant Center account.
• Whether the site carries the shop information and returns policy that Google requires.

Setting up advertising accounts and budgets is a separate area and is not part of SEO.

Visibility of products and your shop in AI assistants

Customers increasingly ask AI assistants for recommendations: which product to choose, how two models differ, where to buy a given type of product. The answers are put together from information the assistant finds in sources and remembers about brands. We test this in four assistants: ChatGPT, Gemini, Perplexity and Claude.

What affects whether your shop is named

• Category and product content. Assistants cite pages that contain concrete answers: parameters, comparisons, uses. A page with only a product grid gives them little to quote.
• Product data. Consistent names, identifiers, prices and availability make it easier to match a product to a question.
• Reviews and external mentions. Comparisons, rankings, forums and review sites are sources that assistants readily use. What is said about a shop outside its own website can be a source for how an assistant describes it.
• Access for crawlers. Rules in robots.txt and server protections can block assistants’ bots. We check whether the blocks are intended.
• Guides and supporting content. Pre-purchase questions are where an assistant chooses which products to recommend.

How we measure AI visibility

We build a set of customer questions from real search keywords, put them to the assistants and check: whether the shop is named, next to which competitors, in what words it is described and which pages are cited. From this data we calculate AI share of voice, meaning your shop’s share of the answers compared with competitors. We repeat the measurement every month, so the change over time is visible. More about the service itself is in the sections on AI SEO and GEO and AI visibility monitoring.

Shop migration with visibility under control

Changing platform, domain or URL structure can put a shop’s visibility at risk. When the domain or URL structure changes, a migration can cover thousands of product and category pages that have inbound links and existing visibility in Google. A mistake in redirects or indexing can lower visibility, and recovery time depends on the type of mistake and on Google reprocessing the pages.

Rules that apply to a shop migration

• Before the launch we list all URLs of the old shop: categories, products, content pages, URLs with external links.
• Each important URL has a designated equivalent on the new site and a 301 redirect.
• The new shop is tested before going live: indexing, canonicals, structured data, sitemap, performance.
• The test version must not reach the index before launch, and after launch it must carry none of the blocks from the testing period.
• After launch we check the indexing status and errors in Search Console, and for a domain change we use the Change of Address tool.

A detailed description of the stages, from the inventory to monitoring after launch, is in the guide to site migration. If you are planning a platform change, it is worth contacting us before choosing a contractor, because a smooth migration depends on how the platform handles URLs and redirects.