An SEO audit template is a repeatable record for turning search evidence into a prioritized, owned, and verifiable change queue. It should not end with a generic score. A useful audit tells a team what was observed, why it matters, what to change, who owns it, how success will be tested, and when to check again.
The short answer
Use one audit record per issue, and require these eight fields:
Scope — site, section, template, or URL set.
Observation — the measured fact, with a source and timestamp.
Diagnosis — the likely mechanism, separated from the observation.
Impact — what discovery, crawling, indexing, ranking, or conversion path is affected.
Recommendation — the smallest coherent change.
Owner and due date — one accountable owner, not a department.
Acceptance criteria — what must be true immediately after the change.
Verification — how and when the team will confirm the search outcome.
The full template below covers crawlability, indexing, canonicalization, content, internal links, structured data, page experience, authority signals, AI-search extractability, and measurement. It also makes human review and agent execution explicit.
Copy this SEO audit template
Duplicate the following block for every audit issue. Keep observations factual; put interpretation in Diagnosis.
Issue record
Issue ID:
Audit date:
Auditor:
Status: Open / Accepted / In progress / Ready to verify / Verified / Won't fix
Priority: P0 / P1 / P2 / P3
Scope:
Affected URLs or pattern:
Search intent or query cluster:
Observation
What is true now? Include the source, timestamp, environment, sample size, and exact URL examples.
Evidence
Crawl or inspection source:
Search Console or analytics source:
Screenshot, export, or query:
Baseline metric:
Confidence: High / Medium / Low
Diagnosis
What mechanism probably explains the observation? State alternatives if the evidence is incomplete.
Impact
Discovery:
Crawl:
Indexing:
Ranking:
User experience:
Conversion:
AI answer visibility:
Recommendation
Describe the smallest coherent intervention. Name the page template, component, metadata field, redirect, content section, or internal-link rule that changes.
Owner:
Approver:
Due date:
Dependencies:
Risk and rollback:
Acceptance criteria
Immediate technical state:
Content state:
Link state:
Rendering state:
Measurement state:
Verification plan
Check immediately after release:
Recheck after crawl:
Recheck after enough traffic:
Success threshold:
If the result is inconclusive:
Audit summary
Objective:
Property and environment:
Audit window:
Primary conversion:
Priority query clusters:
Crawl sources used:
Search and analytics sources used:
Known data limitations:
Issue counts
P0:
P1:
P2:
P3:
Top three changes
1.
2.
3.
Items deliberately not recommended
Document attractive but unsupported ideas. This prevents them from reappearing as if they were approved work.
Next verification date:
Before the audit: define the contract
An audit becomes noisy when everyone silently uses a different definition of success. Before crawling the site, write a one-page audit contract.
Define the property
State the exact hostnames, protocols, subdomains, locales, and environments in scope. Decide whether PDFs, media URLs, parameterized pages, app routes, and archived content are included. An audit of a marketing site is not automatically an audit of a documentation subdomain or a public knowledge base.
Define the business path
Name the journey the site is meant to support:
query or AI prompt;
landing page;
next useful page;
conversion or activation event;
retained outcome.
This matters because a technically perfect page can still be a poor result for the query. The audit must connect technical health to useful discovery and action.
Define evidence freshness
Record when each source was collected. A live HTTP response, yesterday's crawl, a Search Console report, and a search-engine cache can describe different states. Do not collapse them into a single word such as “indexed.”
Separate baseline from target
A baseline is what is measured now. A target is a decision. For example, “LCP is 3.1 seconds at the 75th percentile on mobile” is evidence; “bring LCP under 2.5 seconds” is an acceptance target aligned with current Core Web Vitals guidance. Preserve both.
Phase 1: crawlability and discovery
Start by asking whether a crawler can discover and fetch the pages that should exist.
Host and protocol checks
Check that HTTP and alternate hostnames resolve to the preferred HTTPS host. Record redirect chains, loops, mixed protocol links, inconsistent trailing-slash behavior, and unexpected status codes. A redirect is a routing instruction; it is not proof that the destination is indexable or useful.
robots.txt
Review robots rules by user agent and path. Confirm the file returns successfully and does not block critical HTML, CSS, JavaScript, images, or rendering dependencies. Also identify URLs that are crawlable but should be removed, consolidated, or protected by access control.
Robots rules control crawling behavior. They are not a reliable way to remove an already known URL from search, and they are not an authorization system.
XML sitemaps
Check that every sitemap:
uses absolute, canonical URLs;
contains URLs the site actually wants indexed;
excludes redirects, errors, duplicates, and private resources;
stays within protocol limits;
is referenced from robots.txt or submitted through the relevant search tooling;
reflects the currently published inventory.
Google's current guidance limits a single sitemap to 50 MB uncompressed or 50,000 URLs. Larger properties should split files and use a sitemap index. Treat sitemap inclusion as a discovery signal, not a ranking guarantee.
Internal discovery
Identify important pages that are missing from navigation, hubs, related-reading modules, breadcrumbs, or contextual links. A URL present only in a sitemap is technically discoverable but may still be structurally orphaned.
Evidence to capture
crawl source and user agent;
timestamp;
discovered URL count;
status-code distribution;
redirect chains;
orphan candidates;
sitemap-only URLs;
pages blocked by robots;
depth from an indexable hub.
Phase 2: indexing and canonicalization
Crawlability asks whether a bot can fetch a URL. Indexability asks whether the page is eligible and intended to appear. Search-engine selection is a later outcome, not an audit checkbox.
Indexing directives
Inspect HTML meta robots and relevant HTTP headers. Flag accidental noindex, conflicting directives, and directives that differ between rendered HTML and initial response. For non-HTML resources, HTTP headers may carry the instruction.
Canonical signals
For each indexable page, compare:
declared canonical;
final response URL;
sitemap URL;
internal-link target;
language or regional annotations;
structured-data URL references;
Open Graph URL where present.
Google describes redirects and rel=canonical as strong canonicalization signals, while sitemap inclusion is weaker. Signals can be combined, but they should agree. A self-referencing canonical is useful only when it names the real preferred public URL.
Duplicate and near-duplicate groups
Group duplicates by cause rather than counting them as unrelated errors:
protocol or hostname variants;
trailing slash or case;
tracking parameters;
sort and filter parameters;
pagination;
print or export views;
migrated slugs;
repeated templates with little unique value;
copied drafts or archived versions.
Choose a treatment deliberately: redirect, canonicalize, merge, improve, noindex, or retain as distinct. Do not canonicalize two pages merely because they share a topic; the preferred page should be a valid substitute for the duplicate.
Published-resource mapping
For systems that publish workspace documents, preserve a typed mapping between the editable resource and its public representation. Internal document URLs should never leak into the frozen public body or Related Reading.
A robust record contains:
canonical resource type;
canonical resource ID;
public slug;
public URL;
publish site ID;
published-resource ID;
frozen-at timestamp.
That mapping lets the publishing layer resolve links after slugs change without making the editor guess a production URL.
Phase 3: URL and rendering integrity
A URL should be stable, legible, and consistently rendered.
URL structure
Prefer descriptive path segments and consistent casing. Avoid exposing internal IDs when a durable slug can represent the content. If a slug changes, verify the redirect, canonical, internal links, sitemap, and external campaign links together.
Server response and rendered page
For each important template, capture:
initial and final status codes;
response headers;
server-rendered title, description, canonical, and robots;
rendered title, canonical, headings, body, links, and images;
structured data before and after client execution;
desktop and mobile screenshots.
A successful editor save is not evidence that the public page contains the change. Read the destination.
Mobile and crop behavior
Review cards and hero images at the actual production aspect ratios. Ensure titles remain legible, focal content is not cropped, and gradients or masks do not reduce contrast. Decorative overlays should not cover meaningful diagram labels.
Phase 4: on-page content and intent
Technical eligibility cannot compensate for a page that does not satisfy the query.
Intent match
For every priority page, state the dominant intent:
learn a concept;
compare options;
complete a task;
evaluate a product;
find a template;
troubleshoot a problem.
Then inspect whether the page answers that job early. A template query should expose a usable template near the beginning, not after a long history lesson.
Direct answer and passage quality
Add a concise answer that can stand alone when quoted. The paragraph should name the entity, answer the question, and include the boundary or condition that prevents misinterpretation.
For AI answer engines, useful passages tend to have:
an explicit question or descriptive heading;
a direct answer;
named entities and definitions;
specific steps, fields, or thresholds;
qualifications close to the claim;
a source for time-sensitive facts;
no dependence on an unseen previous paragraph.
This is not a guarantee of citation. It makes the page easier to understand, extract, and verify.
Original value
Record what the page contributes beyond a summary of existing results:
first-party data;
an operational template;
a decision framework;
expert examples;
a tested workflow;
a comparison with explicit criteria;
original visuals that explain the mechanism.
Google's helpful-content guidance recommends creating people-first material rather than content primarily designed to manipulate rankings. There is no preferred word count. Use the length needed to complete the task.
Title, heading, and description
Check that the title names the primary topic and differentiator; one clear H1 represents the page; headings describe their sections; the description accurately previews the page; and repeated templates do not create duplicate titles.
Do not rewrite titles only to force exact-match repetition. Clarity and truthful differentiation matter more than density.
Claim review
For every quantified, comparative, legal, security, pricing, or current-product claim, add a source and date. Distinguish first-party product facts from independent evidence. Remove claims that the source does not support.
Phase 5: information architecture and internal links
Internal linking is both a discovery system and a product journey.
Build topic clusters
For each pillar, list:
the broad concept page;
task and template pages;
comparison pages;
use-case pages;
troubleshooting pages;
conversion pages.
Every cluster page should have a reason to link upward, sideways, and forward. Related Reading alone is not enough when a contextual link would clarify a step.
Audit anchor and target quality
For every important link, ask:
does the anchor describe the destination?
is the target the final public URL?
is the target canonical and indexable?
is the relationship useful at this point in the reader's task?
is the link present in rendered HTML?
does the destination link back or continue the journey?
Avoid generic anchors such as “click here.” Also avoid stuffing anchors with repeated keywords.
Detect orphan and duplicate-link failures
Export pages with no qualifying internal inlinks. Separately identify links that resolve to old drafts, redirects, or non-canonical copies. These are different problems: one is missing graph structure, the other is incorrect identity.
Prioritize the change queue
A long issue list is not a roadmap. Score changes with transparent inputs.
A practical model is:
Priority score = Impact × Reach × Confidence ÷ Effort
Use a small scale such as 1–5 and show the inputs. Do not present the result as scientific precision.
Impact: expected effect on discovery, eligible inventory, visibility, user task completion, or risk.
Reach: number and importance of affected URLs or query clusters.
Confidence: evidence quality and strength of the causal mechanism.
Effort: implementation, review, migration, release, and verification cost.
P0: stop harmful states
Use P0 for incidents such as the public site being unavailable, a release blocking the entire intended inventory, accidental noindex on critical templates, widespread canonicalization to the wrong host, or private content being exposed. P0 is not “the CEO cares about this keyword.”
P1: repair high-value eligibility and identity
Examples include broken publishing routes, stale sitemaps across a priority section, canonical conflicts, severe internal-link misresolution, or important pages that cannot be discovered.
P2: improve relevance and journeys
Examples include missing direct answers, weak comparison criteria, thin template value, poor topic-cluster links, or page-experience work on high-opportunity templates.
P3: monitor or batch
Use P3 for low-reach cleanup, uncertain hypotheses, and changes that can safely wait for a larger template batch.
Phase 6: performance and page experience
Use field data when available and lab data to diagnose.
Current Core Web Vitals guidance defines good experience at the 75th percentile as:
LCP: 2.5 seconds or less;
INP: 200 milliseconds or less;
CLS: 0.1 or less.
Segment mobile and desktop. Also record sample coverage and data freshness. A lab run is useful for reproducing a problem, but it is not a substitute for field experience.
Performance audit record
Capture:
page template and representative URLs;
device and connection profile;
field-data window;
LCP element;
long interactions contributing to INP;
layout-shift sources;
image dimensions and loading behavior;
font loading;
third-party scripts;
cache and compression behavior.
Prioritize the bottleneck that changes the user experience. Do not spend a sprint shaving negligible bytes while the main content image is unbounded or a third-party script blocks interaction.
Phase 7: structured data and entity clarity
Structured data should accurately describe visible page content.
Check syntax, required and recommended properties, URL identity, dates, authorship, organization details, breadcrumbs, and consistency with the rendered page. Do not add a schema type merely because it may produce a rich result.
For GEO/AEO readiness, also inspect whether the page clearly identifies:
the product, organization, or concept;
relationships between entities;
who produced the content;
when it was published and updated;
the scope and limitations of claims;
sources behind time-sensitive statements.
Entity clarity helps machines interpret the page, but it does not replace evidence or authority.
Phase 8: authority and external signals
A technical audit should note off-site dependencies without inventing a link-building campaign.
Review external links pointing to redirects or removed pages, unlinked brand mentions worth evaluating, inconsistent product naming, third-party profiles with stale URLs, important citations lost during migrations, and referral sources that should land on a better canonical page.
Evaluate relevance and editorial legitimacy. A large number of low-quality links is not inherently an opportunity.
Phase 9: measurement and search visibility
An audit is incomplete when it cannot tell whether the change worked.
Baseline by query cluster
Record, where available:
indexed and eligible URLs;
impressions, clicks, click-through rate, and average position;
landing-page sessions;
conversions or product activations;
branded versus non-branded split;
AI-answer mentions or citations for a fixed prompt set.
Do not combine different date windows without labeling them. Preserve zero baselines. “No data” and “zero observed results” are different states.
Verification windows
Use three checkpoints:
Release verification: immediately confirm responses, directives, links, markup, images, and sitemap state.
Crawl/index verification: check after the search engine has had an opportunity to recrawl. Google notes that crawling can take days to weeks and that an indexing request does not guarantee inclusion.
Outcome verification: evaluate visibility and conversion only after enough representative data exists.
A change can pass release verification and still fail to produce a search outcome. Preserve that distinction.
The reusable audit record in practice
Example: stale sitemap after a slug migration
Issue ID: TECH-014
Priority: P1
Scope: public knowledge site
Affected URLs: migrated article slugs
Observation
The live sitemap contains old slugs that return redirects. The new canonical pages are publicly reachable, but several are absent from the sitemap. The evidence is a live sitemap fetch, response checks for both URL sets, and rendered canonical inspection.
Diagnosis
The publishing operation updated resource routes, but the sitemap cache was not invalidated from the same canonical inventory.
Impact
Discovery signals conflict. Crawlers spend requests on redirected URLs, and newly canonical URLs receive weaker sitemap support.
Recommendation
Generate the sitemap from the current published-resource inventory and invalidate its cache when a publish, unpublish, slug, canonical-resource, or site-status mutation commits.
Owner
Publish platform engineer.
Acceptance criteria
every intended public article appears exactly once;
every sitemap URL returns 200;
every sitemap URL matches its rendered canonical;
old slugs are absent;
cache headers match the site's freshness contract;
unrelated published resources remain present.
Verification
read back the production sitemap;
sample and then automate status/canonical checks;
verify the sitemap count against the published inventory;
repeat after a controlled slug change;
monitor search reporting after recrawl.
This record is useful because it distinguishes the live observation, the likely invalidation mechanism, the implementation contract, and the later search outcome.
Human and AI roles in the audit
Agents can collect evidence quickly, normalize URL sets, detect patterns, draft issue records, and rerun deterministic checks. Humans should retain judgment over scope, business impact, risky changes, claim quality, prioritization, and release authority.
Agent-ready inputs
Give the agent:
exact property and environment;
allowed crawl boundaries;
canonical public inventory;
priority query clusters;
relevant analytics sources;
comparison window;
output schema;
evidence citation rules;
write permissions;
stop conditions.
Agent-ready outputs
Require one issue per record, evidence URL or artifact, timestamp, observation separate from diagnosis, affected pattern and samples, confidence, proposed acceptance test, and unresolved questions.
Stop conditions
The agent should stop and escalate when credentials are missing, a crawl crosses an authorization boundary, production mutation would be required, evidence sources conflict, or a recommendation would remove or redirect high-value inventory without an approved mapping.
SEO audit cadence
Weekly
Review publish failures, crawl errors, redirect anomalies, sitemap drift, accidental directive changes, priority-page rendering, and unresolved P0/P1 issues.
Monthly
Review query-cluster visibility, internal links, content decay, competitor changes, Core Web Vitals trends, AI prompt observations, and verification outcomes from completed changes.
Quarterly
Revisit information architecture, template quality, canonical policies, structured data, international targeting, measurement definitions, and the relationship between organic discovery and activation.
After every migration or publishing change
Run an event-driven audit. A calendar is not enough for identity-changing work such as slug migrations, domain moves, rendering changes, CMS migrations, or new publishing modes.
Common audit mistakes
Reporting a score without evidence
A proprietary score may help sort a crawl, but it cannot replace issue-level facts and acceptance tests.
Treating “not indexed” as one diagnosis
A page may be undiscovered, blocked, noindexed, duplicated, canonicalized elsewhere, low value, recently changed, or simply not selected. Record what the evidence can establish.
Using a sitemap as the source of truth
The sitemap should be generated from the canonical published inventory. If teams hand-edit it independently, it becomes another drifting database.
Auditing only the editor
The public response, rendered page, public metadata, internal links, images, canonical, and sitemap are the destination. A successful internal save proves only that the save request succeeded.
Recommending content volume before cluster design
More isolated pages create more maintenance. Define the pillar, supporting tasks, comparisons, templates, and internal links first.
Treating AI visibility as a decorative add-on
If AI answer visibility matters, define a fixed prompt set, capture observed responses with dates, and audit whether pages provide quotable, sourced, entity-clear passages. Do not claim visibility without observations.
Blindly requesting reindexing
Requesting recrawl can be useful after important changes, but it is not a repair. Fix the page and signals first, then request or wait for recrawl and verify later.
Final audit checklist
Crawl and discovery
Preferred host and HTTPS routing are consistent.
robots.txt is reachable and understood.
Critical resources can render.
Sitemaps contain only intended canonical URLs.
Important pages have qualifying internal links.
Crawl evidence is timestamped.
Indexing and identity
Indexing directives are intentional.
Canonical, sitemap, internal links, and final URL agree.
Duplicate groups have an explicit treatment.
Slug changes have redirects and link updates.
Editable resources map to public resources by typed ID.
Content and intent
The page answers the dominant intent early.
Direct answers stand alone.
Original value is identifiable.
Current claims are sourced.
Titles, headings, and descriptions are distinct and truthful.
Images explain content and have useful alt text.
Experience and markup
Mobile and desktop render without overflow.
Meaningful image content survives card crops.
Core Web Vitals are reviewed with the correct data type.
Structured data matches visible content.
Page templates preserve metadata in rendered HTML.
Delivery and verification
Every issue has an owner and due date.
Acceptance criteria describe the destination.
Release readback is complete.
Crawl/index verification is scheduled.
Outcome measurement has a suitable window.
Completed work records evidence, not only status.
Frequently asked questions
What is an SEO audit template?
An SEO audit template is a structured format for recording search issues, evidence, diagnoses, recommended changes, ownership, acceptance criteria, and verification. It turns an audit from a one-time report into an operating system for improvement.
What should an SEO audit include?
It should include crawlability, indexing, canonicalization, URL integrity, rendering, content and intent, internal links, performance, structured data, authority signals, measurement, prioritization, ownership, and post-change verification.
How often should you run an SEO audit?
Use weekly health checks, monthly performance reviews, quarterly structural reviews, and event-driven audits after migrations, publishing changes, large template releases, or canonical policy changes.
Can AI perform an SEO audit?
AI agents can gather and normalize evidence, detect repeatable patterns, draft issue records, and run verification checks. Humans should approve scope, priority, risky changes, and unsupported diagnoses. The agent needs explicit property boundaries, sources, output schema, and stop conditions.
Is an SEO score enough?
No. A score may summarize a tool's model, but it does not show the business impact, causal mechanism, owner, acceptance test, or outcome. Keep the underlying evidence and issue records.
How long does implementation take to show results?
Technical release verification is immediate. Search-engine crawling and indexing may take days to weeks, and an indexing request is not a guarantee. Ranking and conversion evaluation require a separate window with enough data.
Should every page be indexed?
No. Index pages that provide distinct public value and fit the site's discovery strategy. Consolidate, redirect, protect, or exclude duplicates, internal utilities, empty states, and content without a public search job.
What is the difference between an SEO audit and an SEO content audit?
A technical SEO audit focuses on discovery, crawling, indexing, identity, rendering, markup, and experience. A content audit focuses on intent, accuracy, usefulness, originality, decay, overlap, and journeys. A complete audit connects both.
Final model
A strong SEO audit is a closed loop:
Observe → diagnose → prioritize → assign → change → verify the destination → wait for crawl → measure the outcome.
The template is successful when another person or agent can understand the evidence, reproduce the check, implement the intended change, and prove what happened without relying on the original auditor's memory.