Organic performance rarely announces a technical problem neatly. The website still loads. Customers can still buy. Dashboards may show a gradual decline rather than a sudden break.
On a large ecommerce site, a small change to routing, rendering or a shared template can affect thousands of pages. Catalogue growth can also expose weaknesses that caused little harm when the site was smaller.
The following patterns do not prove that technical SEO is the cause. They are signs that a structured investigation may be more useful than another isolated fix.
In brief
- Each warning sign is a lead to investigate, not proof of a technical cause.
- Look for missing valuable pages, concentrated declines, crawl waste and slow discovery.
- Compare raw and rendered pages, then check whether links, redirects, canonicals and sitemaps agree.
- An expanding backlog can also signal that evidence, ownership or decisions are missing.
- Confirm the pattern, scope and commercial exposure before changing the site.
1. Valuable catalogue areas are missing from search
A business may have 500,000 products and see 400,000 excluded URLs in Search Console. That comparison alone says very little. Many URLs should be excluded, including duplicates, expired pages, customer states and filter combinations.
The useful signal is narrower: products or categories that should acquire search demand cannot be found, are being treated as duplicates, or are disappearing from the index.
Start with a defined set of commercially important pages. Check whether Google knows the URL, can crawl it, selected the expected canonical and indexed the current content. Compare the affected set with a stable group on the same site.
Google’s documentation separates discovery, crawling, rendering and indexing. A URL can fail at any one of those stages, so “not indexed” is an outcome rather than a diagnosis.
2. A decline is concentrated around a template, market or release
A site-wide traffic line can hide the shape of a problem. Segmenting the change often provides the first useful lead.
Compare product pages with categories, one country with another, or pages moved in a release with pages left unchanged. Check clicks, impressions, position, indexed coverage and crawl behaviour across suitable periods.
Google’s traffic-drop guidance recommends looking for patterns in the pages affected and considering technical issues, algorithmic changes, seasonality, reporting anomalies and changing demand. A release date is useful evidence, but timing alone does not establish cause.
A gradual decline can also be technical. Google may need to recrawl pages before a misplaced directive, canonical or link change is reflected across the estate.
3. Crawlers spend heavily on URLs with little search value
Filters, sorting, tracking parameters, calendars and internal search can create a very large crawl space. A crawler may find millions of URLs even when the catalogue contains far fewer products.
The strongest evidence comes from server logs. They show which URLs Googlebot actually requested, rather than everything a desktop crawler could reach.
Look for repeated requests to alternate parameter orders, empty results, sort variants, redirects and pages canonicalised elsewhere. Then check whether important products or categories receive less frequent crawling than their value and rate of change would suggest.
Google identifies faceted navigation as a common source of overcrawling. Its guidance warns that excessive faceted URLs can consume computing resources and slow discovery of useful pages.
Read: Faceted navigation: the hidden organic-search cost of ecommerce filters
4. New products and categories are discovered slowly or inconsistently
Catalogue teams may publish new products successfully while search engines find only a portion of them. This often appears during rapid range expansion, marketplace growth or a change to pagination and infinite scroll.
Google primarily discovers ecommerce pages through links. It advises that products should be reachable through crawlable <a href> links because crawlers do not use site-search boxes or trigger every customer interaction. Sitemaps and Merchant Center feeds can help discovery, but they do not repair an inaccessible browse path.
Inspect how a new product moves from publication to an HTML link, sitemap entry, first Googlebot request and indexed page. Compare fast and slow examples to identify the broken stage.
5. The rendered page loses important content, links or signals
A customer’s browser may eventually show a complete page while the server initially returns an empty shell. Search engines can render JavaScript, but rendering introduces another processing stage and another place for implementation errors.
Google explains that it crawls, renders and indexes JavaScript applications in stages. It also recommends server-side or pre-rendering because it benefits users and crawlers, and notes that not every bot can run JavaScript.
Compare the raw response, browser DOM and Google’s rendered HTML. Check product links, main content, titles, robots directives, canonical tags, structured data and meaningful status codes.
Pay particular attention after a headless launch, component rewrite, consent change or JavaScript error. A visual QA pass can miss search-critical elements if the page looks normal after client-side recovery.
6. Canonicals, redirects, sitemaps and internal links disagree
Search engines receive signals from several systems. Problems arise when those systems nominate different URLs.
A category may link to one path, redirect to another, declare a third canonical and appear in the sitemap under a fourth. Each item may have been changed for a sensible local reason. Together they create ambiguity and extra processing.
Google describes redirects and canonicals as strong signals and sitemap inclusion as a weaker one. Internal linking also influences discovery and the site structure Google understands. Consistency helps Google select the version the business intends.
Sample important URL families and trace the full chain. Include locale, case, trailing slash, protocol, pagination, product variants and retired URLs where relevant.
7. The technical SEO backlog grows while decisions remain unclear
A long backlog can signal thorough work. It can also mean that findings are repeatedly added without enough evidence, commercial context or ownership to decide them.
Warning signs include duplicate tickets from successive crawls, default severity labels treated as business priority, recommendations without affected templates, and tickets that cannot pass engineering refinement.
The cost is not limited to unimplemented SEO work. Product and engineering teams spend time interpreting weak requests, while material risks compete with easier hygiene tasks.
Review a sample of open items. For each one, ask what was observed, what value is affected, how the cause was established, what action is proposed and how completion will be tested.
Read: The difference between finding SEO issues and deciding what matters
When these signs do not justify an audit
Normal volatility is not automatically a technical problem. A short-lived fall may reflect seasonality, changing demand, a reporting delay or ordinary movement in search results. A known issue affecting a handful of low-value pages may already have a proportionate fix.
An investigation is most useful when:
- the affected value could be material;
- the pattern spans templates, systems or large URL sets;
- the cause remains uncertain;
- several evidence sources need reconciling;
- a planned change could increase the risk;
- the team needs a prioritised decision, not only more data.
If the problem is already understood and the team only needs implementation capacity, commissioning another audit may add delay.
What a focused investigation should establish
A useful investigation should answer five questions:
- What is happening, and where?
- Which commercial value or future opportunity is affected?
- What is the most likely cause, and what evidence supports it?
- What should change first, considering risk, effort and dependencies?
- How will the team know whether the change worked?
The output should leave the organisation with fewer unresolved decisions, a prioritised implementation plan and tickets that engineering can assess.
Frequently asked questions
What is a technical SEO investigation?
A technical SEO investigation examines how crawling, rendering, indexing, site architecture and platform behaviour affect organic-search performance. It combines website testing with first-party data to establish causes and actions.
How is an investigation different from a website crawl?
A crawl collects URLs and tests them against configured rules. An investigation validates the important patterns, compares evidence sources, determines likely causes and decides which findings justify action.
Does a fall in organic traffic always mean there is a technical problem?
No. Demand, competition, seasonality, search updates, reporting and content changes can all affect performance. Segment the change and test plausible explanations before commissioning technical fixes.
How many excluded pages in Search Console is too many?
There is no useful universal number. Large ecommerce sites often have legitimate excluded URLs. Focus on whether valuable pages are excluded for the expected reasons and whether unwanted URL patterns are growing.
When should server logs be reviewed?
Logs are particularly useful when crawl allocation, URL proliferation or slow discovery is suspected. They show which URLs verified search-engine bots requested and how often, which a desktop crawl cannot establish.
Should an ecommerce site be investigated before a migration?
Yes when the migration may change URLs, architecture, rendering, canonicals, internal links or platform behaviour. Early investigation can establish a baseline and requirements before expensive decisions are fixed in the build.
What access does a technical SEO investigation need?
The exact access depends on the question. Common inputs include read-only Search Console and analytics, crawl data, server logs, platform or CDN configuration, release history, sitemaps and conversations with product and engineering owners.