An SEO audit is an evidence-first workflow. Before you rewrite a title tag or add a paragraph, you confirm that crawlers can reach your pages, that Google indexes what you intend, that a clear answer exists on the page for search and AI systems to draw from, and that you understand your current link profile from a consistent data source. This guide walks through that workflow with free tools, so you can diagnose problems with evidence rather than guesswork and decide which fixes are actually worth making.
Traditional audits focused on getting a page into Google's blue links. A modern audit adds one question: can search and AI systems reach, render, and understand your content well enough to surface it? Google's AI Overviews and AI Mode, along with assistants like ChatGPT and Perplexity, can synthesize answers and present sources before a user visits a page. When one of those systems builds a source-backed answer through web retrieval, crawlable and accessible pages are more likely to be available for it to draw on, though the exact retrieval and citation process varies by platform. The technical and content foundations of audit checks are, for Google's AI features specifically, the same ones that govern whether a page is eligible to appear in Search at all. The process below is repeatable: identify gaps, collect evidence, and decide on fixes.
What an SEO audit is and why it matters
An SEO audit is a structured review of your site across four areas: technical infrastructure, on-page content, off-page authority signals, and how legible your pages are to search and AI systems. Done well, it surfaces specific, fixable problems: pages returning errors instead of content, structured data that does not match the page, slow-loading elements, thin pages that do not answer the query they target, and shifts in your backlink profile.
It matters because an audit protects work you have already paid for. Algorithm updates, CMS migrations, and gradual content drift can erode rankings that took months to build, and regular audits catch those issues before they compound into losses that are harder to recover. It also keeps your site aligned with how people now search. Google has been explicit that its generative features run on the same core ranking and quality systems as the rest of Search and retrieve from the existing Search index, and that a page must be indexed and eligible to appear in Search with a snippet before it can be considered for those features. So for Google's AI features, optimizing is mostly a matter of solid SEO with a few added checks rather than a separate discipline. Other assistants use different indexes, crawlers, and retrieval methods, so the same foundations are sensible groundwork rather than a universal citation standard. And whichever engines you care about, optimization is only half the job: knowing whether a given engine actually mentions or cites your brand is a separate, prompt-level measurement exercise that a conventional audit does not cover.
Free tools worth starting with
You do not need enterprise software to run a thorough audit. Four current Google tools form the backbone: Google Search Console for crawl and indexing data, PageSpeed Insights for Core Web Vitals, Google Analytics 4 for behavior data, and the Rich Results Test for validating structured data that targets a supported rich result. Google retired the standalone Mobile-Friendly Test and the Search Console Mobile Usability report on December 1, 2023, so use Chrome DevTools, Lighthouse, or the Search Console URL Inspection live test for mobile rendering checks. Google uses mobile-first indexing for all sites, so how a page renders on mobile still matters.
In Search Console you can check index coverage, submit XML sitemaps, monitor crawl stats, review the queries you appear for, and inspect individual URLs to test the live page and, in the indexed result, review the canonical Google selected. Analytics 4 adds which pages attract traffic and where visitors drop off. PageSpeed Insights runs Lighthouse lab tests for any URL and, when there is enough Chrome User Experience Report data for that URL or its origin, real-user field data as well; new or low-traffic pages may have no URL-level field data at all. Chrome DevTools lets you inspect rendered HTML, check network requests, and confirm meta tags in the DOM.
Supplement these with the free version of Screaming Frog SEO Spider, which crawls up to 500 URLs and surfaces broken links, redirect chains, missing title tags, duplicate content, and response-code errors in one pass. For larger sites, run targeted crawls on individual subdirectories. Bing Webmaster Tools is worth adding to see how your content is indexed beyond Google, since Bing supports experiences including Yahoo, DuckDuckGo, Microsoft Start, and some AI assistants. Bing may be one input into those systems, though, not the whole story, so treat it as a useful cross-reference rather than a readout of how any AI engine will retrieve or cite you.
The step-by-step workflow
Work through the technical stage first, since every downstream fix depends on a page being reachable and renderable. Use a spreadsheet as your worksheet: for each check, log what you found, the likely explanation, and the action you decided on. That last column matters. An audit that jumps straight from "this looks off" to "rewrite it" tends to generate busywork; the useful pattern is observation, then possible explanations, then the evidence you need, then the fix.
Step 1: Verify crawl access
Open your robots.txt (usually at yourdomain.com/robots.txt) and confirm you are not disallowing paths you want indexed. Then inspect your homepage and a few key landing pages in Search Console and capture the HTTP status. Each intended indexable page should return 200. Review any 3xx redirect separately rather than treating it as an automatic failure: a permanent redirect is a normal way to consolidate a moved URL, and Google uses it as a canonicalization signal. Flag a redirect only when it is unintentional, points to the wrong destination, forms an unnecessary chain or loop, or sits on a URL that is meant to stay independently indexable. Treat 4xx and 5xx responses on pages that should serve content as real problems to resolve.
Step 2: Confirm indexability and canonical selection
In the Search Console Pages report, review excluded URLs and the reason given for each. For key pages, check whether the canonical Google-selected matches the one you declared. If it differs, that is a prompt to investigate, not proof of lost ranking: canonicalization exists to consolidate duplicate or near-duplicate URLs, and Google may be signaling that two pages look substantially similar, that your canonical, sitemap, redirect, and internal-linking signals disagree, or that the page is weakly differentiated. Self-canonicalization is often sensible, but it is not a hard requirement for every page. The audit question is whether Google's choice aligns with your intent, and, if not, why your signals point elsewhere.
Step 3: Review the XML sitemap
Open your sitemap (usually at yourdomain.com/sitemap.xml), confirm it lists the canonical, indexable URLs you want found, and submit it in Search Console. Compare submitted and indexed counts by sitemap or page type. There is no universal healthy percentage here; a sitemap is a discovery hint, not a guarantee of crawling or indexing. Investigate unexpected gaps, especially when canonical, indexable URLs stay unindexed, and read the gap against the exclusion reasons Google reports rather than against a fixed ratio.
Step 4: Run a technical crawl
Crawl the site with Screaming Frog (free, up to 500 URLs), export the results, and note broken links, redirect chains, pages missing or duplicating title tags or meta descriptions, and images with missing alt attributes, followed by a manual check to distinguish informative images from decorative ones. Rather than ranking redirect chains by a fixed hop count, prioritize by impact: a short chain on millions of frequently crawled URLs matters more than a longer chain on one obsolete page. Reduce unnecessary chains by pointing internal links straight at the final destination, and weigh each by scale, crawl frequency, traffic, backlinks, and latency.
Step 5: Test Core Web Vitals
Run your key templates, not just the homepage, through PageSpeed Insights, since blog posts, product pages, and category pages often perform differently. Google's Core Web Vitals assessment is based on field data at the 75th percentile of real users, so that is the official basis for whether a URL passes; use Lighthouse lab data to diagnose likely causes and test fixes, especially when field data is sparse or unavailable. The bands Google publishes are: LCP good at 2.5s or less, needs improvement above 2.5s to 4s, poor above 4s; INP good at 200ms or less, needs improvement above 200ms to 500ms, poor above 500ms; CLS good at 0.1 or less, needs improvement above 0.1 to 0.25, poor above 0.25. Record the causes and recommendations PageSpeed Insights associates with any metric below "good," then confirm which changes actually move the measured bottleneck before prioritizing the work.
Once technical health is confirmed, move to on-page, content, and off-page checks.
Step 6: Audit on-page elements
For each key page, review the title, meta description, headings, and image alt text. Keep titles descriptive, unique, and concise, and check how they display across devices rather than enforcing a fixed character count; Google has no fixed length limit and may generate the displayed title link from several page elements. Write useful meta descriptions while recognizing that Google often rewrites them per query. Use a clear primary heading; multiple H1 elements are not automatically an error, though competing main headings can blur what the page is chiefly about. Give informative images concise, context-appropriate alt text, and use an empty alt attribute for purely decorative images so assistive technology can skip them.
Step 7: Evaluate content quality
Apply a concrete test to each key page. Can a reader quickly locate a clear answer to the page's target question? Does it support important claims with linked sources or named data? Does it offer something that competing pages on the same results page do not? If the answer to any of these is no, flag the page for improvement. A site: search (site:yourdomain.com "exact phrase") is a quick manual spot-check for obvious duplication, but it shows only what Google chooses to return, so treat it as a clue rather than a complete duplicate-content inventory; crawl-based comparison or your CMS data is more reliable.
Step 8: Check internal linking
Identify your priority pages by traffic, conversion, or strategic importance, and confirm each is reachable through the site's architecture and receives relevant contextual links. Rather than applying a universal minimum, weigh link depth, anchor relevance, and how many internal links a page gets relative to its importance. Orphan pages are a genuine concern, but "zero internal links" in a crawl can also reflect where the crawl started, so verify before acting.
Step 9: Validate structured data
Where a page qualifies for a supported rich-result type, validate the relevant structured data with the Rich Results Test and confirm the markup matches the visible content. The tool checks structured data tied to Google rich results, not every Schema.org type, and valid markup makes a page eligible for a feature without guaranteeing it appears. Not every page needs structured data, and a warning does not necessarily make an implementation invalid; read errors and warnings against the requirements for that specific feature.
Step 10: Review your backlink baseline
Open the Search Console Links report and note the top linking sites, most-linked pages, and anchor-text patterns. This report gives examples and aggregates rather than a complete backlink database, so read it as a partial, directional picture. A drop in displayed links does not by itself indicate a manual action or ranking problem; it may reflect reporting changes, recrawling, canonicalization, removed pages, or genuine link loss. If you suspect a real problem, check it alongside the Manual Actions and Security Issues reports and your indexing, ranking, and traffic data before drawing a conclusion.
Turning findings into priorities
Sort what you found by impact and effort, and treat the tiers below as a sample framework rather than a fixed sequence, since severity is site-specific. A crawl block on a revenue page is urgent; a server error on a low-value archived page may not be. As a general shape: resolve crawl and indexing blocks first, because pages Google cannot properly crawl, render, or index are unlikely to compete meaningfully in Search or its generative features; then close content gaps and missing direct answers on pages that already draw traffic or target high-value queries; then make structured-data and internal-linking corrections that compound over time; then invest in longer-term authority work like earning links from relevant, credible sites.
Document each issue in your worksheet with the page affected, the fix, the deploy date, and the change in traffic, rankings, or citations over the following weeks, and assign an owner to each. Reviewing progress on a regular cadence during active remediation, then less often once the major issues are closed, turns a one-time audit into an ongoing cycle and gives you a record of what changed and why.
Auditing for AI search visibility
The most useful thing to understand about optimizing for AI search is what Google itself now says about it. In its guidance on generative AI features, Google states that AI Overviews and AI Mode are rooted in its core ranking and quality systems, which they retrieve from the existing Search index, and that "optimizing for generative AI search is optimizing for the search experience, and thus still SEO." Two practical consequences follow. First, for Google's features, a page must be indexed and eligible to appear in Search with a snippet before it can be considered, which is why the technical checks above are the real foundation of AI visibility there; other AI systems may use different indexes, crawlers, licensed sources, or retrieval methods, so this is not a universal citation law. Second, Google does not identify a special technical optimization required only for its AI features: it explicitly says you do not need llms.txt files, content chunking, AI-specific rewriting, or special schema for them. Foundational SEO remains the basis, while measuring visibility across engines is a separate workflow.
Structured data is the point most likely to be oversold. Google's own wording is that structured data "isn't required for generative AI search, and there's no special schema.org markup you need to add," while remaining worth using as part of overall SEO because it supports eligibility for rich results. So use a schema that accurately represents visible content and makes a page eligible for a real search feature; do not present it as a proven requirement for citation in ChatGPT, Perplexity, or Google's generative features.
That leaves a shorter, more honest list of things worth doing. Beyond technical eligibility, favor a clear and direct answer to the target query in visible HTML, reliable and named sourcing, and consistent terminology for people, products, and organizations so your entities are unambiguous. These are sound editorial practices that make a page easier for people and retrieval systems to interpret, not guaranteed or universally documented citation factors. Google's own emphasis lands in the same place: it says unique, compelling, useful content, the kind built on direct experience rather than assembled from what is already everywhere, is likely to influence long-term presence in its generative features more than the other optimizations in its guidance. These practices improve clarity, usefulness, and interpretability rather than promise a result, because citation depends on the query, the available sources, the index, and each engine's own retrieval and ranking, which vary and are not publicly documented. And a note of caution Google itself raises: be wary of tools that claim access to internal Google metrics, because no external tool has that access.
For a fuller treatment of where these terms sit, our explainer on how SEO, GEO, and AEO relate is a good next read; GEO and AEO are overlapping industry labels without settled boundaries, both describing efforts to earn visibility in synthesized answers.
How often to audit
A comprehensive audit every three to six months suits most sites; larger or fast-moving ones may warrant a quarterly deep dive. The right cadence depends on your site's size, how competitive your space is, and how often you change the site, since migrations, redesigns, and CMS updates introduce the most risk. Treat these intervals as practical recommendations rather than fixed rules.
Run a focused mini-audit immediately after any migration, redesign, or CMS update, covering crawl access, index coverage, canonical selection, and Core Web Vitals, since these changes can introduce crawl, canonicalization, rendering, and performance problems. A lighter monthly check on crawl stats, Core Web Vitals, and index coverage catches problems without a full overhaul. After a confirmed Google core update, avoid drawing conclusions while it is still rolling out; once it completes, compare longer date ranges and allow time for reporting and normal daily variation before attributing any change to the update.
What free tools cannot do
Free tools have real limits. Screaming Frog's free tier caps at 500 URLs, so larger sites need a segmented crawl strategy or paid software. PageSpeed Insights tests one URL at a time, which makes batch testing tedious. Search Console and other webmaster tools only work on sites you have verified, so you cannot use them to audit a competitor's domain. And Search Console's backlink data, while fine for baseline monitoring, is a partial set of link examples and aggregate reports rather than a complete backlink index, without the competitor database, detailed authority metrics, or rich historical link tracking that paid suites provide. When those gaps start to cost you, a paid platform or professional help is the next step; the right one connects technical findings to measurable outcomes rather than just surfacing more data.
If you are weighing platforms, Pixis maintains side-by-side breakdowns against an enterprise SEO suite, an SEO automation tool, and a purpose-built GEO platform that walks through where each fits.
Frequently asked questions
What does an SEO audit actually check?
It reviews technical health (crawlability, indexing, canonicals, Core Web Vitals), on-page elements (titles, headings, content quality), off-page signals (your backlink profile), and how legible your pages are to search and AI systems. The goal is to find specific, fixable issues before they compound into traffic losses that are harder to recover.
Which free tools do I actually need?
Google Search Console for indexing and crawl data, PageSpeed Insights for Core Web Vitals, Google Analytics 4 for behavior, the Rich Results Test for supported structured data, and the free Screaming Frog tier for crawling up to 500 URLs. For mobile rendering, use Lighthouse or the URL Inspection live test, since the Mobile-Friendly Test was retired in December 2023.
How do I start a technical audit?
Begin with crawlability and indexing in Search Console: check robots.txt, confirm key pages return 200, and review canonical selection. Then test Core Web Vitals with PageSpeed Insights, and check for broken links and unnecessary redirect chains with a crawl. Fix anything that blocks a page from being reached or rendered first.
Does structured data help my pages show up in AI answers?
Not as a dedicated lever. Google says structured data is not required for its generative AI features and there is no special markup for them, though it remains useful for rich-result eligibility in regular Search. Use schema where it matches visible content and qualifies a page for a real feature, and don't expect it to earn AI citations on its own.
How is auditing for AI search different from regular SEO?
For Google's AI features, the optimization foundation is largely the same: crawlability, indexing, technical accessibility, and useful content. A cross-engine AI-visibility audit adds a separate measurement layer, including prompt-level mentions, citations, competitor presence, answer accuracy, and variation across engines. Clear answers and first-hand content are sensible editorial practices, but they are not guaranteed citation factors.
In a Nutshell
A modern SEO audit covers technical health, on-page content, off-page signals, and AI-search legibility, but the AI layer is mostly solid SEO rather than a separate discipline. Google Search Console and Screaming Frog do most of the free diagnostic work, within real limits on scale and competitor analysis. Fix what blocks a page from being reached or rendered before investing in deeper content work. Direct answers in visible HTML, reliable sourcing, consistent terminology, and original, first-hand content make pages clearer and more useful, but no practice guarantees citation across AI engines. And read Search Console's backlink data as partial rather than complete, tracking linking sites and pages from a consistent source over time instead of chasing a single authority score.
Start with the technical foundation, work through content and off-page signals, and document every fix so you can measure what worked. That is how an audit becomes a repeatable system rather than a one-time checklist. A traditional audit can tell you whether a page is technically and editorially eligible to compete, but not whether a particular AI engine actually mentions your brand, which source it cites, or how the answer shifts across prompts; that takes separate, prompt-level monitoring. When you are ready to connect audit findings to published improvements and track how AI engines cite your pages across engines, you can run a check in Pixis Visibility.