SEO Audit: The Complete Site Assessment Framework
An SEO audit is a structured review of everything that limits a site’s organic performance: whether search engines can crawl and index it, whether its pages render and load well, whether the content answers what people search for, how its links compare with competitors’, and which problems to fix first. A complete framework covers all of those layers in an order where each one builds on the last, and it ends with a prioritized list of fixes someone can act on, not a pile of observations.
1. Crawl the Site
Every other part of the audit depends on knowing what is on the site and how a crawler experiences it. A desktop or cloud crawler such as Screaming Frog SEO Spider, Sitebulb, or Lumar (the tool formerly called DeepCrawl) maps the site and reports:
| Area | What the crawl shows |
|---|---|
| Status codes | Pages returning 4xx or 5xx, and the internal links pointing to them |
| Redirects | Chains of more than one hop, loops, and internal links that point at redirects |
| robots.txt | Paths blocked from crawling, including ones that should not be |
| Sitemaps | Listed URLs that are not indexable, and important URLs that are missing |
| Canonicals | Missing, conflicting, or chained canonical tags |
| Depth | How many clicks separate each page from the homepage |
On large sites, crawl efficiency matters. Google’s crawl budget guide defines crawl budget as the URLs Google can and wants to crawl on a site, and warns that long redirect chains hurt crawling.
A simulated crawl shows what a bot could do. Server logs show what Googlebot requested, how often, and which low-value URL patterns, such as faceted filters or internal search results, take up its requests.
No single crawl is the whole site. Combine the crawl with the URLs in the CMS, the sitemaps, the server logs, and analytics landing pages; a URL that appears only outside the crawl is an orphan candidate to check, not yet a confirmed orphan.
2. Check Indexing
The Page indexing report in Search Console (the report once called Index Coverage) gives counts of indexed and not-indexed URLs with a reason for each group, and example URLs that Google limits to 1,000 per list and does not guarantee to be complete. Read it by template: when one page type shows up under “Crawled, currently not indexed” or “Duplicate, Google chose different canonical than user,” look at the template before looking at individual pages.
Structured data belongs here too, with one correction to older audit checklists: valid markup is not the same as an enhanced listing. Google narrowed FAQ and HowTo results in 2023, and its Search Central changelog records that FAQ rich results stopped appearing in Google Search on May 7, 2026. An audit that promises rich results from adding FAQ or HowTo markup is recommending something Google no longer shows.
3. Test Rendering
On sites built with JavaScript frameworks, compare the raw HTML with the rendered page. Content present only after scripts run depends on rendering, and the URL Inspection tool shows what Google rendered for a given URL. Record which rendering approach each template uses (server-side, static, or client-side) and whether its scripts or styles are blocked in robots.txt.
4. Measure Page Experience
The current Core Web Vitals are Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (visual stability). Google’s INP documentation states that “INP is the successor metric to First Input Delay (FID),” and the March 2024 announcement says “FID will no longer be a Core Web Vital, and will be officially deprecated and removed from the program.” A finding about FID in a current audit is a finding about a retired metric.
Use two kinds of data:
- Field data from the Chrome UX Report, shown in Search Console and PageSpeed Insights, tells you whether real visitors have a problem and on how many pages.
- Lab data from Lighthouse, run on specific pages, tells you why.
Trace each failing metric to its cause. For loading, check the hero image, server response time, and render-blocking files, and check that the main image is not lazy-loaded: Google’s LCP guide warns against lazy-loading the LCP image, since it always delays that resource and hurts LCP. For responsiveness, look at long JavaScript tasks and heavy event handlers. For layout shift, look at images and ads without reserved space, font swaps, and content injected above what the visitor is reading.
5. Review the Content
Start from an inventory of indexable URLs with title, meta description, length, last substantive update, and organic clicks and queries. Then look for:
- pages that do not answer the query they appear for
- several pages competing for the same query
- missing, duplicated, or inaccurate titles and descriptions
- heading structures that do not reflect the page’s outline
- important pages that receive few internal links
- facts, prices, or dates that have gone out of date
Judge each finding against the pages currently ranking for the same queries, since a content gap is relative to what searchers are already being shown.
6. Review the Backlinks
No backlink tool sees the whole web, so compare at least two sources or add Search Console’s links data. Look at how many distinct domains link to the site, how relevant and established they are, whether anchor text is dominated by one commercial phrase, any sudden spikes or losses, and links lost from strong sources. Set the numbers next to the sites that rank for the same terms, since a link count means little on its own.
7. Compare With Competitors
Run the same checks on two or three sites ranking for the target queries. For example, imagine the audited site’s main pages show a field LCP of 2.8 seconds and 12 referring domains, while three competitors on page one show under 1.5 seconds and around 80 referring domains. A comparison like that turns “the site feels slow” into a gap someone can be asked to close.
8. Prioritize
A findings list is only useful once it is in order. Place each finding by expected impact and effort:
| Impact | Effort | What to do |
|---|---|---|
| High | Low | Fix first |
| High | High | Scope as a project |
| Low | Low | Batch into routine work |
| Low | High | Document and defer |
Then check dependencies. A broken canonical template should be fixed before a content change on the same pages is measured, or the result of the content change will be hard to read. Problems that block basic access, such as errors on important pages or important pages blocked from indexing, come before everything else.
9. Report
Group findings by theme, show the evidence for each (a screenshot, a crawl export, a report row), and pair each with a specific action and an owner. Record a baseline of clicks, rankings, and conversions before fixes ship, so the effect can be compared later against the same measures, and check first that the analytics tag fires on every template and that each key event is counted once. Note the Manual Actions and Security Issues reports in the same record, even when both are empty, and mark any area left out of scope as such. Findings that cannot be fixed now still go in the report with their expected impact, so they are not rediscovered from scratch next time.
Questions About SEO Audits
How long does an audit take?
It depends on the number of pages, the layers in scope, the site’s complexity (JavaScript, international versions, faceted navigation), and the quality of its historical data. Scope those variables first, then set a timeline.
How often should a site be audited?
After any migration, redesign, or platform change, and on a regular cycle in between that the team can sustain. Continuous monitoring of indexing and Core Web Vitals catches problems between audits but does not replace a full review.