An ecommerce crawl can return thousands of warnings before lunch. Missing descriptions. Redirect chains. Canonical differences. Pages three clicks deeper than a chosen limit.
The list may be accurate. It still does not tell a team what to do on Monday morning.
Useful technical SEO work has to establish which findings affect valuable pages, what caused them, how confident we are, and whether fixing them is a better decision than the work already competing for engineering time.
In brief
- An issue report records observations against a rule or expectation.
- A decision-ready recommendation connects an observation to evidence, cause, affected commercial value and a feasible action.
- Tool severity is useful for triage. It does not know the business, catalogue or delivery constraints.
- A long list can create false confidence while important problems remain hidden among low-value warnings.
- The standard to ask for is simple: what decision does this finding change?
Detection is the beginning of the investigation
Crawlers and monitoring systems are very good at repeating checks consistently. They can find patterns across a site that would be impossible to inspect page by page.
They can report that:
- 86,000 URLs have no meta description;
- 14,000 product pages are more than four clicks from the homepage;
- 3.2 million parameter URLs are internally linked;
- two canonical tags appear in the rendered HTML;
- a JavaScript template returns little useful content in the first response.
Those numbers are illustrative. Each observation needs a different line of enquiry.
A missing meta description may have little commercial consequence because Google generates snippets from page content. A deep product set may be deliberate because it contains discontinued stock. A large parameter estate may warrant immediate attention if logs show repeated Googlebot requests and important products are being discovered slowly.
The count cannot make that distinction.
Google makes a similar point in its guidance on third-party SEO tools. Tool data can be helpful, but it does not come from Google’s internal ranking systems and cannot guarantee performance. Google recommends evaluating advice against official guidance and making an informed decision.
Five steps turn a finding into a decision
- 01Observation
What exactly was found?
- 02Validation
Does it survive contact with the live site?
- 03Cause
Which system creates the pattern?
- 04Materiality
What valuable area is affected?
- 05Action
What should the team change and test?
1. Observation
State exactly what was found, where it occurs and how it was measured.
“Some canonical tags are wrong” is too vague. A useful observation identifies the affected template, expected value, actual value and scale. It should be reproducible by somebody who did not run the original crawl.
2. Validation
Confirm that the observation survives contact with the live website.
Check representative URLs in the browser, raw response and rendered HTML. Compare crawler data with server logs, Search Console, analytics, release records or platform configuration where relevant. Rule out authentication, location, personalisation and crawler settings as causes of a false positive.
Google recommends using URL Inspection to check what it received and rendered. That first-party view can confirm whether a robots directive, canonical or rendered element appeared as expected. It still represents a sampled URL and point in time, so estate-wide conclusions need broader evidence.
3. Cause
Find the system creating the pattern.
Fifty thousand affected URLs rarely need fifty thousand edits. The useful unit of work may be one product template, filter rule, routing function, CMS field or deployment process.
Cause also prevents the wrong fix. Adding a line of copy to weak category pages will not repair an internal-linking system that keeps them undiscoverable. Changing canonical tags will not stop a crawler entering an effectively infinite calendar or filter space. Faceted navigation needs a URL policy before individual controls are chosen.
4. Materiality
Establish what the issue puts at risk or prevents the business from gaining.
Relevant questions include:
- Which products, categories, markets or templates are affected?
- Do those areas generate demand, revenue or strategic value?
- Is Google currently crawling, indexing or serving them differently?
- Is the pattern stable, growing or linked to a recent release?
- What happens if nothing changes for three months?
- What other work would be displaced by this fix?
Materiality is often uneven. A defect on the main product template deserves a different response from the same defect on a small set of expired campaign pages.
5. Action
Turn the conclusion into work a team can assess and deliver.
A decision-ready recommendation should state the intended outcome, affected system, proposed change, dependencies, risks and acceptance criteria. It should also record uncertainty. A small controlled test may be the correct next action when the evidence is incomplete.
Google’s own hiring guidance says an SEO audit should give realistic estimates of improvement and the work involved. That requires more than exporting warnings.
Why severity labels are often misleading
Most tools use labels such as error, warning, critical or opportunity. These usually describe the tool’s rule, not the value at stake for this particular business.
The same technical pattern can carry very different priorities:
| Finding | Context | Sensible response |
|---|---|---|
| Missing meta descriptions | Product pages have useful visible content and stable search performance | Low-priority hygiene unless snippets or click behaviour show a material problem |
| Missing meta descriptions | Thousands of location pages contain almost no descriptive content | Investigate page usefulness and duplication rather than filling one field mechanically |
| Canonical mismatch | A print-friendly duplicate points to the main page | Likely expected; validate and document |
| Canonical mismatch | A revenue-driving category template points every page to the parent | High-priority investigation because valuable pages may be consolidated incorrectly |
| Non-indexable URLs | Account, cart and internal-search states | Usually expected |
| Non-indexable URLs | Newly launched product categories intended to acquire search demand | Material release defect if confirmed |
This is why ranking recommendations by a tool’s default severity can send engineering effort towards tidy reports rather than commercial outcomes.
The evidence record should be compact
A compact evidence record is usually enough for a team to judge and implement the work.
A useful record normally contains:
- the observation and how it was reproduced;
- affected templates and estimated scale;
- evidence of search or commercial consequence;
- likely cause and confidence level;
- recommended action and viable alternatives;
- dependencies and implementation risk;
- testable acceptance criteria;
- an owner or decision still required.
An example might read:
Observation: Product-card links on two category templates are absent from the initial and rendered HTML when a customer has not interacted with the page.
Evidence: Reproduced on six representative categories. URL Inspection rendered HTML contains product names but no linked product URLs. Server logs show materially fewer Googlebot requests to products available only through these templates.
Cause: The frontend binds navigation to a JavaScript click handler on a non-link element.
Action: Render each product card as an
<a>element with anhrefin the server response. Preserve the current interaction and tracking. Validate on staging, then monitor product discovery after release.Acceptance: Representative cards expose resolvable product URLs without user interaction, the links remain after rendering, and automated tests cover both templates.
This example is illustrative. It shows the chain from observation to acceptance criteria without claiming a guaranteed traffic result.
Senior judgement is visible in what gets ruled out
Good investigation actively looks for evidence that could disprove the initial theory.
If traffic fell after a deployment, the deployment is a reasonable lead. It is not yet the cause. Search demand may have changed, a competitor may have improved, reporting may be incomplete, or a Google update may have affected the same period.
Google’s traffic-drop guidance recommends separating site-wide changes from groups of pages, comparing clicks and impressions, checking seasonality, reviewing technical reports and considering algorithmic changes. The shape and distribution of the change help narrow the cause.
The same discipline should apply to every audit finding:
- Can we reproduce it independently?
- Is the affected area performing differently from a suitable comparison group?
- Did the timing match a release or catalogue change?
- Does first-party evidence agree with the crawl?
- What evidence would make us lower the priority?
Confidence should rise as independent signals agree. Certainty should not be manufactured to make a recommendation sound stronger.
A prioritised backlog still needs decisions
A scoring model can make trade-offs visible. It cannot remove judgement.
Useful dimensions include:
- affected commercial opportunity;
- downside risk;
- strength of causal evidence;
- breadth and duration of the impact;
- implementation effort and dependencies;
- reversibility and release risk.
Avoid multiplying several guessed numbers into a score that looks scientific. Record the assumptions and let the team see why one item sits above another.
The backlog should also separate three outcomes:
- Act: evidence and materiality justify implementation.
- Test: a bounded experiment or additional measurement is needed.
- Accept: the behaviour is understood and does not justify work now.
“Accept” is a valid outcome. It stops the same warning being rediscovered and debated in every audit.
A backlog that cannot support these decisions is itself one of the warning signs that a complex ecommerce site may need technical investigation.
Questions to ask when reviewing an audit
- Which findings affect our most valuable templates, products or markets?
- What first-party evidence supports the claimed consequence?
- Has the cause been demonstrated or only inferred?
- What was ruled out?
- How confident is the recommendation, and why?
- What happens if we defer it?
- What engineering or operational dependency could change the answer?
- Can the team tell when the work is complete?
- Which warnings have been deliberately accepted?
- What decision does each remaining recommendation enable?
These questions make a shorter audit more demanding, not less thorough.
Frequently asked questions
What is the difference between an SEO crawl and an SEO audit?
A crawl collects website data by following configured rules. An audit investigates what the data means, validates important patterns, establishes likely causes and turns the evidence into prioritised decisions.
Are automated SEO tools reliable?
They can reliably detect many technical patterns when configured well. Their labels and recommendations still need validation against the live implementation, official guidance, first-party data and business context.
How many recommendations should a technical SEO audit contain?
There is no useful standard number. The audit should include every material recommendation that changes a decision or action, without padding the list with accepted behaviour, duplicates or low-value hygiene.
Should every technical SEO issue be fixed?
No. Some findings describe expected behaviour, carry little material risk or cost more to fix than the likely benefit. Record the decision and evidence so the issue does not return without new information.
What makes an SEO recommendation actionable?
It identifies the affected system, explains the intended outcome, proposes a feasible change and includes dependencies, risks and testable acceptance criteria. The team should be able to assess and implement it without guessing what the auditor meant.
How should technical SEO work be prioritised?
Compare commercial opportunity, downside risk, evidence strength, breadth of impact, effort, dependencies and reversibility. Keep assumptions visible and use the result to support a decision rather than treating the score as the decision.