What is an SEO audit?

An SEO audit examines whether a site can be discovered, crawled, understood and selected for relevant searches. It looks at technical delivery, indexability, internal architecture, page meaning, experience signals and the evidence available in search data. A health score can be a useful summary, but it is not a diagnosis: a score does not tell a team which URL, template or business goal is affected.

The useful output is therefore a set of testable decisions. A redirect issue matters differently on an old campaign page than on a category that drives qualified demand. Good audit work records the affected URL group, the observed evidence, the likely cause, the owner who can change it and the way the change will be checked afterwards. This makes the audit usable by developers, editors and stakeholders rather than only by its author.

• Separate observations from assumptions and proposed fixes.
• Keep crawl data, rendered-page checks and Google data distinguishable.
• Prioritise by user impact, search opportunity, scope and implementation risk.

Crawl and index checks ask whether important pages return the intended status, are internally linked, appear in XML sitemaps where appropriate and can be indexed. They also review canonicals, robots directives, redirects, duplicate URL patterns and JavaScript rendering. Search Console is especially valuable here because it reports Google's view of indexed pages and can help investigate a particular URL; it is not a replacement for crawling the site yourself.

On-page and content review asks whether pages have a distinct purpose, a clear heading hierarchy, useful titles and descriptions, descriptive links, accessible media and enough original information for the query they target. Performance work should distinguish laboratory diagnostics from field data. Core Web Vitals are user-experience metrics, so a single test run can suggest a problem, while aggregated field data is better evidence of what visitors experience.

• Technical: responses, canonicalisation, robots, sitemaps and rendering.
• Structure: navigation, internal links, orphaned pages and URL patterns.
• Content: intent, duplication, headings, metadata and structured data where relevant.
• Measurement: query, landing-page and conversion context from verified analytics tools.

Run a baseline audit before a redesign, migration, CMS change, domain move or major navigation release. These moments alter many technical signals at once, and a pre-change inventory gives the team something concrete to compare after launch. During a migration, test a representative staging environment where possible, then validate the live redirects, canonicals, robots rules and key URLs immediately after release.

For an established site, a recurring cadence is more useful than treating an audit as a one-off event. Weekly monitoring can surface sudden technical changes; a monthly or quarterly review creates room for deeper interpretation. The right frequency depends on release volume, page count and risk. A small brochure site does not need the same monitoring design as a shop whose filters and product availability change daily.

• Before and after major releases or platform changes.
• When organic landing pages, indexed-page patterns or conversions change unexpectedly.
• On a recurring schedule matched to the rate at which the site changes.

Start by defining the site areas and outcomes that matter: lead pages, product collections, documentation, local pages or editorial content. Crawl with a declared scope, note whether JavaScript is rendered, and retain the date, settings and URL count. Compare the crawl with server-side realities and with Search Console reports rather than assuming every crawler finding represents an index problem.

Then segment the findings. A missing description across thousands of paginated URLs is not automatically urgent; a noindex directive on a revenue-critical page may be. Look for repeated template causes, not just individual URLs. For content decisions, inspect the actual search result and the page's job before recommending more text or a different keyword. Evidence should be strong enough that a colleague can reproduce the conclusion.

• Capture samples and affected URL counts, not only labels such as warning or error.
• Check a live URL after every material recommendation.
• Record uncertainty when the audit cannot establish cause from available data.

A practical backlog groups related findings into work packages: repair a redirect rule, update a page template, clarify a canonical policy, improve internal links to a section, or rewrite a small set of high-intent pages. For each package, explain the expected mechanism rather than promising a ranking outcome. For example, repairing an unintended noindex can allow crawling and indexing; it does not guarantee that a page will rank.

Assign an owner and an acceptance check. Development tasks need reproduction steps and a definition of done. Editorial work needs target pages, audience intent and review criteria. After deployment, recrawl the affected URLs, inspect the rendered page and observe relevant Search Console and analytics trends over a sensible period. Keep a change log so later movement is interpreted in context rather than attributed casually to one edit.

• Impact: which users, URLs and business journeys are involved?
• Effort and risk: can the change be safely tested and reversed?
• Verification: what evidence will show that the intended technical state exists?

An audit report should begin with scope, date, environment and limitations. It should show the few decisions that need attention before the complete issue inventory. Link every important recommendation to examples, explain why it matters in plain language and say what would be checked next. This is particularly important when the report is shared outside an SEO team, where a severity label alone can create unnecessary alarm.

AuditLumo supports manual, weekly and monthly recurring audits of up to 500 pages, with 53 audit rules. Teams can bring Google Analytics 4, Search Console and Google Ads context into their workflow, create configurable white-label reports and use a client portal where that fits their process. Those capabilities can organise evidence and communication; they do not remove the need to validate important findings or make a human decision about priority.

• Show an executive summary, evidence, recommended action and verification method.
• Use shareable reporting to align owners, not to disguise uncertainty.
• Review recurring changes against releases, seasonality and measurement limitations.