Direct answer
An SEO and AEO audit asks three questions: Can search systems access the page? Does the page answer a real search need? Can you measure what happened after the fix? Inspect the rendered page first, confirm response and site behavior with a bounded crawl, then use Search Console, field performance, analytics, and live results for outcomes the page cannot prove.
What an SEO and AEO audit should cover
An SEO audit is often described as a technical checklist: titles, canonicals, status codes, sitemaps, structured data, page speed, and links. Those checks matter, but they are only part of the decision. A page can be perfectly crawlable and still fail because it answers the wrong question, buries the useful information, repeats generic claims, or gives the reader no reason to trust it.
An answer-engine optimization audit adds a sharper content question: can a person or system identify the answer, understand its conditions, and connect important claims to evidence? It looks for direct responses under descriptive headings, clear definitions, comparison criteria, scannable steps, source attribution, authorship, dates where freshness matters, and enough surrounding context to avoid a misleading extract.
SEO foundation
Discovery, crawlability, indexability, canonicalization, rendering, page experience, relevance, internal links, and the broader signals that help a search engine find and evaluate a page.
AEO focus
Answer clarity, extractable structure, explicit entities and definitions, evidence placement, attribution, useful formats, and the completeness needed to answer a question without stripping away essential conditions.
These are not competing disciplines. AEO without SEO can produce an excellent answer that is difficult to discover. SEO without answer quality can produce an indexable page that does not satisfy the reader. Google’s guidance for AI search features says the familiar SEO requirements still apply and that no special AI file or new markup is required for eligibility. The same page must be discoverable, understandable, useful, and trustworthy.
The evidence ladder: keep three kinds of proof separate
An audit becomes unreliable when an observation is presented as a conclusion it cannot support. A rendered document can show that a canonical element exists, but it cannot prove the server always returns the expected status. A crawler can show that a URL is linked and returns 200, but it cannot prove Google chose that canonical. Search Console can show impressions and clicks, but it cannot tell you whether a particular sentence caused the change.
The StrictSEO evidence ladder puts every finding at the lowest layer that can actually prove it. Move upward only when the decision requires more evidence.
| Layer | What it can show | What it cannot prove | Typical sources |
|---|---|---|---|
| 1. Page and rendered evidence | Rendered title, canonical, robots directives, headings, visible answers, links, images, JSON-LD, authorship, source labels, layout clues, and local browser timings. | Complete crawl coverage, server behavior outside the captured response, field performance, rankings, backlinks, traffic, or selection by a search or answer engine. | StrictSEO extension, public analyzer, browser DevTools, manual review. |
| 2. Crawl and server evidence | Status codes, headers, redirects, robots rules, sitemap discovery, crawl paths, depth, inlinks, broken destinations, template repetition, and controlled Lighthouse lab results. | Google’s indexed state, real-user experience, query demand, clicks, conversions, external authority, or AI citations. | StrictSEO Browser, server logs, crawler exports, Lighthouse. |
| 3. Search and external evidence | Queries, impressions, clicks, indexed/canonical reports, field Core Web Vitals, conversions, backlinks, live SERP formats, brand mentions, and observed answer-engine citations. | A single causal explanation without an appropriate test or enough time; external systems and demand can change independently of the page. | Search Console, analytics, CrUX or field RUM, backlink indexes, server logs, manual result research. |
Write findings as “the rendered page shows,” “the crawl observed,” or “Search Console reports.” That small wording choice makes the evidence auditable and prevents a local heuristic from becoming a false ranking claim.
Before you start: define the decision
A site-wide audit without a decision usually produces a long spreadsheet and a short attention span. Start by naming the business or editorial outcome. Examples include improving non-brand discovery for a service, recovering an important template after a migration, increasing qualified visits to a product page, or making a reference guide easier to cite and reuse.
Choose a small representative set before crawling everything: the homepage, one high-value conversion page, one strong search landing page, one weak page with impressions, and one representative template. Record the primary audience, the task each page should complete, and the query families that describe that task. If Search Console data exists, use actual page-query pairs instead of brainstorming keywords from memory.
Create a baseline you can revisit
- Record the canonical URL, page purpose, intended reader, and the action that indicates success.
- Export recent clicks, impressions, click-through rate, and average position for the page and its main query groups. Compare like periods and note seasonality.
- Capture field Core Web Vitals where sufficient data exists. Keep field data separate from a Lighthouse lab run.
- Save the current title, description, H1, opening answer, last meaningful update, internal inlinks, and conversion baseline.
- Note releases, migrations, campaigns, or demand changes that could affect the measurement window.
The baseline prevents a later rise or decline from being credited to the audit simply because the page changed at roughly the same time.
A seven-step SEO and AEO audit workflow
The steps are ordered to resolve access and intent before polish. Complete them on the representative pages first. Expand the crawl only after you know which patterns deserve site-wide investigation.
Confirm access, indexability, and canonical intent
Begin with conditions that can make every later improvement irrelevant. Inspect the final rendered URL, title, meta robots directive, canonical element, language, viewport, and HTTPS state. Then check the response status, redirect chain, X-Robots-Tag headers, robots.txt rules, and sitemap entry.
A canonical is a hint, not permission to leave conflicting signals. The preferred URL should return a successful response, receive internal links, appear consistently in metadata and sitemaps, and avoid redirecting elsewhere. Robots.txt controls crawling; it does not protect sensitive content. If a page should stay out of search, use an appropriate index control on a crawlable response and verify the result in the search platform.
- Fix accidental noindex directives, canonical loops, blocked rendering resources, soft-404 content, and redirect chains before editing the copy.
- Verify the live response, not only the DOM after client-side code changes it.
- Record uncertainty when a page is new or external index data is unavailable.
Match the page to one coherent search need
Read the page as a user arriving from an unfamiliar result. The title, H1, opening paragraph, major sections, and primary action should describe the same job. A page can include related subtopics, but it should not ask one URL to be a product page, glossary, news article, and general category hub at the same time.
Use query data where available. Group queries by intent and language rather than forcing every phrase into the copy. Compare the page with live results to understand the formats users are being offered: product pages, guides, calculators, lists, category pages, videos, or short definitions. The goal is not to copy competitors. It is to determine whether your page type and information depth fit the need better than the current alternatives.
- Write a one-sentence page promise: “This page helps [reader] decide or do [task] using [distinct evidence or capability].”
- Remove or relocate sections that belong to a materially different intent.
- Keep the title specific enough to set expectations and the H1 natural enough to orient the reader.
Make the answer identifiable and complete
Place a concise response near the heading that raises the question. A direct answer does not mean every page needs a forty-word snippet. It means the reader should not have to assemble the conclusion from vague marketing copy. Define unfamiliar terms, state important conditions, and follow the short answer with the evidence, process, or comparison needed to use it safely.
Use descriptive headings that can stand on their own. Tables are useful when several items share the same comparison fields. Ordered lists are useful when sequence matters. Checklists are useful when the reader needs to verify completion. Prose remains better for nuance and tradeoffs. Choose the format that makes the decision easier rather than publishing repetitive FAQ blocks solely to repeat keywords.
- Answer “what,” “who is this for,” “how,” “when,” “limitations,” and “next step” where they genuinely fit the topic.
- Keep critical qualifiers with the answer so an extract does not reverse its meaning.
- Use concrete nouns and entities instead of relying on pronouns whose referent is unclear outside the paragraph.
Strengthen evidence, authorship, and freshness
Claims are easier to trust when the supporting evidence is adjacent and specific. Link to primary sources for standards, official behavior, original data, and product requirements. Explain how an original table or measurement was produced. If a claim is an interpretation, label it as one. Avoid a long source list that does not connect individual claims to the evidence that supports them.
Show who is responsible for the page. That can be a qualified person or, where appropriate, a clearly identified organization with an editorial method. Do not invent an expert biography. Dates should communicate real publication or review activity; changing a date without a meaningful update creates a freshness signal for readers that the content has not earned.
- Replace unsupported superlatives and precise percentages with evidence or careful language.
- Review time-sensitive facts, screenshots, versions, prices, regulations, and tool behavior.
- Add an About or methodology path that explains how findings and content are produced.
Audit internal discovery and topical support
A good page should be reachable through meaningful internal paths, not only a sitemap. Inspect links from hubs, navigation, related guides, and pages with established visibility. Anchor text should tell a reader what destination to expect. Avoid dumping dozens of repetitive exact-match links into footers or templates; authority routing works when the relationship is useful and the destination deserves the click.
Use a bounded crawl to identify orphan candidates, excessive depth, broken internal destinations, redirecting links, and clusters with weak connections. Then review the links in context. A crawler can count inlinks but cannot decide whether they appear in a place where a reader would actually benefit.
- Link new or strategically important pages from a relevant hub and at least one contextually related page.
- Consolidate near-duplicate pages only after checking query intent and existing performance.
- Update internal links when a URL is redirected so the crawl path points directly to the preferred destination.
Validate structured data, previews, and page experience
Structured data should describe visible content using a documented type. Validate JSON-LD syntax, required properties, and consistency with the canonical page. Do not add types only because a tool gives them a green check. Google now limits FAQ rich results primarily to well-known government and health sites, and HowTo rich results are deprecated in Google Search. Markup is not a display contract.
Review search and social previews as packaging, not as a ranking score. The title should identify the page and differentiator without truncation-driven gimmicks. The description should clarify value and scope. Open Graph and X/Twitter fields should match the current page rather than inherit generic homepage copy.
Test keyboard access, contrast, responsive layout, and performance. Lighthouse supplies controlled lab data; field Core Web Vitals reflect real visits. The “good” thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 at the 75th percentile. They are experience thresholds, not promises of ranking gains.
Turn findings into owners, tests, and measurement
Rewrite each finding as a task someone can finish. Include the affected URL or template, evidence, expected change, owner, verification method, and measurement window. “Improve AEO” is not a task. “Add a two-sentence eligibility answer under the pricing H2, cite the official plan limits, and verify it remains visible without interaction” is.
Separate implementation verification from outcome measurement. Rerunning the page check can prove that the answer and metadata changed. A crawl can prove that internal links and status codes changed. Search Console and analytics can show whether impressions, clicks, and useful actions moved over time. Neither should be used to claim causation without enough evidence and a reasonable comparison.
- Ship small, coherent groups so a later result can be interpreted.
- Annotate the release date and preserve the before-state.
- Define in advance whether the decision is keep, iterate, expand, or revert.
Worked example: auditing a small SEO tool page
Assume a local-first SEO analyzer has a technically valid landing page but almost no non-brand visibility. The page title says “Powerful Website Tool,” the H1 says “Fix Your Rankings,” the opening describes features without defining the user’s problem, and the analyzer is linked only from the homepage. The page receives a few impressions for “on-page SEO analyzer” and “AEO audit tool,” but the click-through rate is inconclusive because the sample is small.
From vague promise to measurable page
Observed evidence
- The rendered title and H1 describe different topics.
- No direct explanation defines what the tool checks or cannot verify.
- The page has valid JSON-LD, but it inherits generic social metadata.
- A bounded crawl finds one internal inlink and no related educational guide.
- Search Console shows early impressions for two relevant query families, but not enough data to claim a trend.
Prioritized response
- Align the title, H1, introduction, and WebApplication description with the actual on-page SEO and AEO job.
- Add a direct answer, evidence boundaries, and a visible explanation of the local workflow.
- Publish a supporting audit guide with original frameworks and link both ways.
- Add route-specific social metadata and relevant hub links.
- Record the release, then compare query-group impressions, clicks, qualified tool starts, and crawl discovery after a sufficient window.
The plan does not predict a ranking position, assign an “AI visibility” probability, or claim that the guide will earn links. It improves the page, adds an internal discovery path, and defines what to measure. Rankings and citations still have to be observed outside the page.
Prioritize by impact, confidence, and effort
A list of 200 warnings is not a strategy. First identify whether the issue blocks access, weakens a high-value page, repeats across a template, or creates an obvious trust or usability problem. Then estimate confidence from the evidence and effort from the actual implementation—not from a generic severity label.
High impact, high confidence
Accidental noindex, broken canonical paths, 5xx responses, a major template title defect, inaccessible primary navigation, or a misleading factual error on an important page.
High impact, lower confidence
Intent mismatch, major consolidation, navigation restructuring, or rewriting a successful page. Gather query, link, and conversion evidence before making a broad change.
Lower impact, high confidence
Missing image dimensions, incomplete social fields, internal redirect links, duplicated helper copy, or a deterministic accessibility defect that can be fixed at the shared component.
Lower impact, lower confidence
Arbitrary word-count targets, cosmetic score chasing, speculative AI markup, mass FAQ generation, or rewriting every title simply because a checker prefers a character range.
For every template issue, inspect representative pages before a bulk change. A rule that improves a product page can damage a reference page if the content model differs. For every editorial issue, preserve useful existing information and add what is missing before assuming the URL needs a complete rewrite.
Measure whether the work helped
Technical validation can happen immediately: the preferred URL returns the right response, the metadata is present, the answer is visible, the structured data parses, internal links point directly to the page, and the layout works. Search outcomes need a longer and messier observation window because crawling, indexing, competition, seasonality, and demand all move independently.
In the Google Search Console performance report, compare the page and relevant query groups rather than only the site total. Review clicks, impressions, click-through rate, and position together. A lower average position can accompany growth if the page begins appearing for many new queries. A higher click-through rate can accompany fewer clicks if demand fell. Export the data when you need more detailed grouping or period comparisons.
For AEO, use an observation log rather than a fabricated visibility score. Record the exact question, system, location or personalization conditions where known, date, whether the page or brand appeared, the cited URL, and the wording of the answer. Repeat a stable set carefully, but do not confuse a small prompt sample with the full market. Combine that observation with normal organic discovery and conversion measures.
| Question | Immediate verification | Outcome evidence |
|---|---|---|
| Can systems access the page? | Response, redirects, robots rules, canonical, rendered content, sitemap and internal paths. | Indexed/canonical reports, impressions, server bot logs where available. |
| Does the page satisfy the need? | Intent alignment, direct answer, supporting sections, evidence, usability review. | Query mix, qualified clicks, engagement tied to the page task, conversions or next-step use. |
| Is the answer reusable? | Clear definitions, descriptive headings, tables or steps, nearby sources and conditions. | Observed snippets or citations, referral traffic where exposed, links and mentions, repeated user success. |
SEO and AEO audit checklist
Use this as a completion check, not as a scoring formula. A failed item matters in proportion to the page’s purpose, evidence, and reach.
- The page purpose, intended reader, search need, and success action are written down.
- The preferred URL returns the expected status and has a clean redirect path.
- Robots rules, meta robots, X-Robots-Tag, canonical, sitemap, and internal signals do not conflict.
- The rendered page exposes its important content and works without hidden interaction requirements.
- The title, H1, opening, major sections, and primary action support one coherent intent.
- A direct response appears near the relevant heading and includes essential qualifications.
- Definitions, steps, comparisons, tables, and checklists are used only where they improve understanding.
- Important factual claims have adjacent primary or clearly identified sources.
- Authorship or organizational responsibility is visible and truthful.
- Publication and update dates reflect meaningful work where freshness matters.
- Internal links connect the page to a relevant hub and useful supporting pages with descriptive labels.
- A bounded crawl has checked broken destinations, redirects, depth, inlinks, and repeated template issues.
- Structured data parses, matches visible content, and uses a documented type without display guarantees.
- Search and social metadata are specific to the page rather than inherited boilerplate.
- Keyboard access, contrast, responsive layout, images, and meaningful interaction states have been reviewed.
- Lab performance and field performance are reported separately.
- Each accepted finding has an owner, affected scope, next action, and verification method.
- The before-state, release date, query groups, and outcome window are preserved for comparison.
SEO and AEO audit questions
What is an SEO and AEO audit?
It reviews whether a page can be discovered, crawled, understood, trusted, and used to answer a search need. SEO covers the broader search foundation; AEO focuses on direct, extractable, well-supported answers. Both belong in the same audit. An on-page check can find weaknesses, but it cannot predict rankings or citations.
Is AEO different from SEO?
AEO is a focused part of organic search work, not a replacement for SEO. A page still needs technical access, relevance, useful content, internal discovery, and authority. AEO work improves answer clarity, section structure, definitions, evidence, attribution, and the ease with which a reader or system can identify the response.
Do I need special AI schema or an llms.txt file?
Google’s current documentation says its AI search features do not require special AI files, new machine-readable markup, or special schema beyond normal Search eligibility. Use structured data only when it matches visible content and a documented type. Other services may publish their own crawler controls, but a new file is not a substitute for indexable, useful, well-supported pages.
Can an audit tool calculate my chance of being cited by AI?
A local page audit cannot calculate a defensible citation probability. Citation selection depends on the query, the system, the available corpus, freshness, source quality, and many external signals the page does not expose. An audit can identify answer clarity and evidence weaknesses; actual visibility must be measured in external results over time.
How often should I audit a website?
Audit after major template, migration, navigation, rendering, or content changes, and use a smaller recurring review for important pages. The practical cadence depends on publishing volume and risk. Monitor search and field data continuously where possible, but reserve full crawls and deep editorial reviews for moments when the evidence or release scope justifies them.
Primary sources and further reading
This workflow uses official documentation for search eligibility, structured data, crawler behavior, performance thresholds, and measurement. Product-specific behavior is documented in the StrictSEO methodology and issue library.
- Google Search: AI features and your website — current eligibility and optimization guidance for AI Overviews and AI Mode.
- Google Search: AI search optimization guide — fundamentals for helpful, accessible, well-supported content.
- Google crawler documentation: robots.txt specification — supported rules and matching behavior.
- Google structured-data policies — visible-content, relevance, and quality requirements.
- Google Search Central: FAQ and HowTo display changes — limits and deprecation relevant to schema recommendations.
- web.dev: Core Web Vitals thresholds — how good thresholds and the 75th percentile are defined.
- Google Search Console performance report — definitions and interpretation of clicks, impressions, CTR, and position.
- Perplexity crawler documentation — an example of service-specific crawler and robots controls.
- StrictSEO methodology and SEO & AEO issue library — product evidence boundaries, repair steps, and verification guidance.
Audit the page you are already viewing
Start with the public browser-based analyzer or request the private Chrome extension build, then use StrictSEO Browser when the decision needs crawl, server, Lighthouse, or accessibility evidence.