SEO Audit Guide
How to run an SEO audit that leads to useful fixes
A practical SiteBoost editorial guide to finding technical and on-page problems, judging their impact, and proving that a fix worked after deployment.
What an SEO audit should actually accomplish
An audit is useful when it turns evidence into decisions. The goal is not to collect the largest possible list of warnings. It is to determine whether important pages can be discovered, understood and used, then identify the problems most likely to interfere with those goals. A strong audit also records enough evidence that another person can reproduce the finding.
Start by defining the page types that matter to the business: the homepage, product or service pages, editorial pages and other public landing pages. Sample each type instead of assuming one URL represents the whole site. Template-level mistakes can affect hundreds of URLs while an isolated warning may affect only one page.
1. Establish a crawl and indexability baseline
Check that an important public URL returns the intended response and does not depend on a broken redirect chain. Review robots directives, canonical URLs and sitemap inclusion together. These signals should tell a consistent story about which URL is primary and whether it is intended for search.
A canonical is not a substitute for fixing every duplication problem, and sitemap inclusion does not force indexing. Treat these as diagnostic signals. If a page is accidentally blocked, incorrectly canonicalized or unreachable through normal navigation, fix that foundation before polishing smaller metadata details.
2. Match metadata and headings to real page intent
Read the title, description, H1 and opening copy as a group. They should make the subject and purpose clear without repeating the same keyword unnaturally. Useful metadata is specific to the page. Large sets of near-identical titles often indicate a template problem rather than dozens of independent writing problems.
Then inspect heading structure. Supporting headings should help a reader scan the page and understand how sections relate to the main topic. Do not change headings merely to satisfy a mechanical pattern; prioritize clarity and hierarchy.
3. Judge the main content, not just the HTML tags
A technically valid page can still be weak if it does not answer the reason a visitor arrived. Look for original explanation, examples, evidence and practical detail. Remove placeholder sections and avoid creating many pages that say essentially the same thing with a different keyword in the heading.
For a software site, public educational pages should stand on their own even when a visitor never creates an account. Explain the problem, how to investigate it, common mistakes, and what a reader can verify independently. Product calls to action can support that content, but should not replace it.
4. Audit internal links and information architecture
Important pages should be reachable through useful navigation and contextual links. Link related guides where the connection helps a reader continue learning. Descriptive anchor text is more informative than repeating generic phrases everywhere. Also look for orphan pages that appear in a sitemap but have no meaningful path from the rest of the public site.
When an old page is removed, update internal links rather than relying on redirects forever. A clean information architecture makes maintenance easier and gives both people and crawlers clearer paths through the site.
5. Review images, mobile usability and performance in context
Informative images need useful alternative text; decorative images usually do not need descriptive copy. Check whether large media, fonts or third-party scripts delay the page. Performance measurements can vary, so compare the same page under similar conditions and use repeated measurements before declaring a regression fixed.
Mobile review is not just a viewport check. Confirm that text remains readable, controls are usable, content is not hidden unexpectedly and important navigation works without precise pointer input.
6. Prioritize with reach, severity and confidence
Reach asks how many important pages or visitors are affected. Severity asks what the problem can prevent or degrade. Confidence asks whether the evidence clearly supports the diagnosis. A sitewide accidental noindex has high reach and severity; a slightly long title on one low-priority page usually does not.
Write the expected outcome beside every important fix. For example: “After changing the template canonical, sampled category pages should each point to their own preferred URL.” This makes verification objective instead of relying on a vague sense that the site looks better.
7. Deploy, rescan and keep an evidence trail
Do not mark an issue complete when code is merged. Check the live URL after deployment, repeat the relevant test and record the result. Search systems can take time to recrawl pages, so distinguish an immediate technical verification from a later search-performance outcome.
A perfect audit score only means the measured checks passed under that audit. It cannot guarantee rankings, traffic or revenue. The most useful workflow is continuous: measure, prioritize, fix, verify, then revisit important templates as the site changes.