Define the audit through site structure and the problem
Within an SEO consultancy scope, identify the site's purpose, priority page types and reported issue first. Pre-launch verification, traffic-drop investigation and a routine review do not ask identical questions. Templates, languages, variants and access conditions matter alongside URL count. Crawling every address is not the same as understanding every behaviour.
Review the sitemap, platform, planned changes and available access. Choose representative examples and record exclusions. A large store may require separate treatment of products, categories and filter states. Restricted experiences such as account or payment journeys need explicit review conditions. The aim is not an undefined promise to check everything, but a clear explanation of which question is answered using which evidence. That makes the findings easier to assess and the next implementation scope more realistic.
Read crawler output alongside live behaviour and source data
A traffic-drop investigation especially needs timing and change history. Crawl output, Search Console information and appropriate server logs answer different questions. Validate a tool warning against live examples. Missing access or incomplete historical data should not be disguised as a definitive diagnosis.
Each finding needs an example URL, observed condition, affected group and proposed next check. If a canonical mismatch appears, establish whether it concerns one page or a shared template. Understand the reach of the evidence before generalising. A technical issue and traffic movement occurring at the same time do not independently prove causation. Record plausible alternatives and the evidence required to distinguish them.
Observation
What does a tool or live review actually show? Attach the relevant response, example or screenshot to the finding.
Interpretation
How might the behaviour affect a useful page? Keep plausible alternative explanations visible.
Verification
Which additional data or test will strengthen the diagnosis? Record unknowns as follow-up work.
FROM READING TO A NEXT STEP
Turn technical warnings into actionable decisions
Share the website, priority page type and technical issue your team needs to resolve.
Keep crawling and indexing controls distinct
On an ecommerce site, products, categories, filters and account pages perform different search roles. Do not recommend a broad robots rule before confirming intended visibility. Robots.txt, noindex, canonical signals, redirects and sitemaps are different control areas. For instance, a crawler needs access to the content to observe a noindex directive, so those rules require coordinated review.
Compare addresses discovered through internal links, included in the sitemap and declared as canonical. Look for accidental publication of draft or obsolete paths. Empty results, status codes and redirect chains should also be evaluated through the customer experience. Checking that a tag exists is insufficient; verify the response and intended behaviour. Removing an indexing restriction does not guarantee a ranking, since information value and search relevance remain separate considerations.
Inspect real output for JavaScript and template problems
Where JavaScript SEO review is needed, compare initial HTML, rendered output and interaction behaviour. When do headings, main content and links become available? Can a resource error or delayed API leave a significant section empty? A technology name alone does not establish that SEO is good or bad.
An illustrative category template that loads products only after a particular interaction needs review of discovery and access. Different data conditions can produce different output from one template. A successful desktop page can still have a mobile issue. Give developers a repeatable scenario: the URL, conditions, expected behaviour and observation. Assess architectural implications with engineering. An audit should not independently prescribe a complete rewrite merely because the underlying framework is unfamiliar or a tool produced an unexplained warning.
Interpret performance findings through page and user conditions
Work with the web application team to distinguish laboratory tests from actual user data. Network, device and content conditions influence the experience. One score can hide different problems such as image loading, delayed interaction or layout movement. Removing a useful customer feature merely to improve a test score may not solve the underlying journey.
Identify the affected component, resource and template. For an illustrative large image, dimensions, format and loading behaviour may need review while preserving its design purpose. A recommendation should describe implementation risk and validation needs. Technical acceptance and commercial results are separate measures. Do not assume a performance correction will create a fixed sales increase. Review it as part of the customer experience and the site's defined measurement, with uncertainties recorded rather than converted into a persuasive promise.
Turn audit findings into developer tasks and acceptance checks
For SEO implementation support, each important finding needs an owner, proposed action and acceptance criteria. Delivering a report does not mean the issue has been fixed. Prioritise using business relevance, evidence strength, effort and dependencies. Small edits, shared-template changes and migrations carry different risks.
Audit, implementation and post-release verification may be separate scopes. Explain which stage is included in the proposal. Record data sources, coverage, limitations and unresolved questions at handover. New releases or additional markets can require another assessment. The documentation should make that follow-up understandable to the customer instead of leaving a static report whose conclusions are assumed to remain valid indefinitely.
Prioritised work
Separate significant constraints, implementation tasks and follow-up checks with their rationale.
Usable tickets
Provide example URLs, reproduction steps, expected behaviour and acceptance conditions.
Closing verification
Inspect production behaviour after release; do not mark unobservable outcomes as proven.
BEFORE YOU DECIDE
Frequently asked questions
Can an automated SEO report replace an audit?
Tool output is a useful input, but does not independently establish context, impact and implementation decisions. A warning may reflect intended behaviour. An audit validates examples, identifies the affected scope and turns findings into work the team can understand and verify.
Which access is required?
Review website access, Search Console and measurement data according to the problem. Server logs or a test environment are not equally necessary in every engagement. Use appropriate permissions. State clearly how unavailable data limits the diagnosis rather than making assumptions about it.
Are all fixes included after the audit?
Audit and implementation may be separate deliverables. The proposal should specify included technical and editorial work. Some tasks belong with existing developers; others need additional delivery capacity. Agree verification and maintenance responsibilities at the outset so a report does not imply unlimited implementation.
Does crawl access guarantee indexing?
No. Access, indexing and ranking are different considerations. A technical review examines controllable obstacles, while information usefulness and search intent also matter. It should not promise automatic indexing or positions merely because the page can be requested by a crawler.
How often should a technical audit be performed?
A platform change, migration, major template revision or unexplained performance shift may justify a broader review. Routine monitoring can be narrower. Choose a plan according to change frequency and sensitive components instead of applying one fixed schedule to every site.
What should we bring to the first conversation?
Share priority URLs and page types, examples of the issue, change history and infrastructure details. Existing reports are useful too. These inputs help define the appropriate crawl, rendering, performance and implementation scope before commissioning a much wider review.
LET’S DEFINE THE SCOPE
Turn technical warnings into actionable decisions
Share the website, priority page type and technical issue your team needs to resolve.
Discuss audit scope