A useful SEO audit finds the specific things stopping search engines from crawling, understanding, and ranking your important pages, proves each one with evidence, and tells you what to fix first. It covers crawling and indexation, rendering, site structure, content, on-page signals, structured data, and your own Search Console data. If a finding cannot be tied to a page, a cause, and a fix, it does not belong in the report.
What is an SEO audit actually for?
An SEO audit exists to explain the gap between how your site performs in search and how it could perform, and to turn that gap into a ranked list of work. It is a diagnosis, not an inventory.
That distinction matters because most sites have hundreds of small imperfections. A missing alt attribute on a decorative image and a template that blocks every product page from indexing are both "issues," but only one of them changes anything. A good audit spends its time on the second kind.
Before any crawling starts, I want to know three things: which pages earn money or leads, which searches the business needs to appear for, and what has changed recently (a migration, a redesign, a traffic drop). Those answers decide where the audit looks hardest.
Crawling, indexation, and rendering
The first job is to confirm that search engines can reach your important pages, render them as users see them, and choose to index them. If that chain breaks, nothing else on the page can help.
Crawl and indexation
- Robots.txt and meta robots: are any important sections blocked or set to noindex by mistake, often left over from a staging site?
- Status codes: do important URLs return 200, and are redirects single hops to the final URL rather than chains?
- Canonical tags: do they point where you intend, or are pages canonicalized to the wrong version? This is where canonicalization problems usually surface.
- XML sitemaps: do they list only indexable, canonical URLs, and do they match what the site actually links to?
- Crawl waste: on large sites, are faceted filters, parameters, or internal search pages consuming crawling that should go to real content? Crawl budget is rarely a concern for small sites, but it is for large catalogs.
Rendering
Google can render JavaScript, but the audit should still check that the rendered page contains the main content, the internal links, and the metadata. Compare the raw HTML with the rendered HTML from the URL Inspection tool. If product descriptions, navigation links, or canonical tags only appear after scripts run, or not at all, that is a finding worth confirming page by page.
Site structure, content, and on-page signals
Once pages can be seen, the audit checks whether they are organized and written so a search engine can tell what each page is about and which page should rank for which query.
Information architecture and internal links
Look at how many clicks it takes to reach important pages from the homepage, which pages receive the most internal links, and whether that matches business priority. Orphan pages (indexable pages with no internal links pointing to them) and important pages buried deep in pagination are common. Anchor text matters too: links labeled "learn more" tell a search engine very little.
Content quality and cannibalization
Check whether key pages answer the query better than what currently ranks, whether thin or near-duplicate pages are diluting the site, and whether several pages compete for the same query. Keyword cannibalization shows up in Search Console as multiple URLs trading impressions for one query over time. It is not always a problem, so the audit should show the data before recommending a merge.
On-page elements
Titles, headings, and meta descriptions should describe the page in the words searchers use. The audit should flag templates that produce duplicate titles at scale, not list every title a few characters over a length limit.
Structured data
Check that markup is valid, matches the visible content, and uses types that fit the page. Structured data helps search engines interpret entities and can make pages eligible for rich results, but eligibility is not a guarantee. If the relationships between your brand, people, services, and locations are unclear across the site, that is a larger entity architecture question than a markup fix.
Using Search Console and analytics as evidence
Search Console and analytics data turn suspicions into findings. A crawler tells you what the site looks like; performance data tells you whether it matters.
- Performance report: which pages and queries carry the site, which lost clicks, and whether the losses come from position, click-through rate, or impressions.
- Page indexing: trends in indexed versus not indexed pages, whether important templates are affected, and whether the exclusion reasons match what the crawl shows.
- Crawl stats: response times, error spikes, and how crawling is split between page types.
- Analytics: whether organic landing pages convert, so the audit prioritizes pages that produce value, not just traffic.
- Server logs (where available): what Googlebot actually requests, which is the most direct evidence of crawl behavior.
An audit that never opens Search Console is guessing. Third-party tools estimate; your own property data measures.
What an audit should ignore
Ignore vanity scores and raw issue counts. They measure how many rules a tool checked, not how much a problem costs you.
Site health percentages, "SEO scores," and headlines like "1,248 issues found" come from tools applying generic rules to every URL. The tool does not know which pages matter, which warnings are intentional, or which issues have no practical effect on your site. A site can score well and still have its main category pages canonicalized to the wrong URL.
Other common padding:
- Meta description and title length warnings presented as ranking problems.
- Generic page speed scores with no link to real user data or a specific template.
- Keyword density targets.
- Recommendations to "add more content" without saying which page, which query, and what is missing.
What the deliverable should look like
The deliverable should be a short, ranked list of findings, each with the evidence behind it, how sure you are, who owns the fix, and how you will know it worked. Length is not a measure of quality.
The most useful habit is separating what is confirmed from what is suspected. A confirmed finding has direct evidence: the noindex tag is in the source, the redirect chain is visible, Search Console shows the pages excluded. A hypothesis is a reasonable explanation that still needs testing, such as "these pages may be losing to competitors because their content is thinner." Mixing the two leads teams to spend weeks on guesses presented as facts.
| Field | What it contains | Example |
|---|---|---|
| Finding | One specific problem on named URLs or templates | Product template canonicalizes to the category page |
| Status | Confirmed or hypothesis | Confirmed |
| Evidence | Source code, Search Console reports, log lines, screenshots | URL Inspection shows the Google-selected canonical differs from the declared one |
| Priority | Based on affected pages, their value, and effort | High: affects every product page |
| Owner | The person or team who can make the change | Development |
| Verification | How to confirm the fix worked | Re-inspect sample URLs; watch the indexed count for the template |
Prioritization should weigh how many important pages a problem touches, how directly it blocks ranking, and how much work the fix takes. A one-line template fix that affects every product page beats a rewrite of one blog post. If you want a structured starting point, my three-step SEO diagnostic follows this format.
How to judge an audit you are sold
Judge an audit by whether you could start work from it tomorrow and know when each item is done. Use this checklist.
- Does it start from your business goals and priority pages, not from a generic crawl?
- Does it use your Search Console data, not only third-party estimates?
- Is each finding tied to specific URLs or templates?
- Are confirmed findings separated from hypotheses?
- Does each finding show its evidence?
- Is the list ranked, with a clear reason for the order?
- Does each item name an owner and a verification step?
- Does it avoid headline scores and issue counts as the main message?
- Does it say what it did not check, and why?
- Could your developer act on the top five items without a follow-up call?
If an audit fails most of these, it is a tool export with a cover page.
Common questions
How long should an SEO audit take?
It depends on the number of page templates, the size of the site, how quickly you can grant access to Search Console and analytics, and whether server logs are available. A small brochure site can often be reviewed in a few days. A large ecommerce or multi-language site can take several weeks.
How often should a site be audited?
Run a full audit before and after major changes such as a migration, redesign, or platform switch, and whenever traffic drops without an obvious reason. Between those, regular checks of the Search Console indexing and performance reports catch most regressions early.
Can I run an SEO audit myself with a tool?
A crawler will collect the raw data, and that is a good start. The work an audit adds is interpretation: deciding which issues affect pages that matter, confirming them against Search Console, and ranking the fixes.
Should an audit include backlinks?
It should review the link profile as context, including which pages attract links. Treat automated "toxic link" scores the same way as other vanity scores: as prompts to look, not as findings.