An audit is a fix list, not a document
The deliverable most agencies hand over is a crawl export with every warning the tool could generate. It is thorough and it is useless, because nobody can tell which twelve of those four hundred issues are worth a developer's week. A useful audit is ranked by impact and written so a developer can start on Monday.
The order we check things
- Can Google reach the pages that matter? Crawl the site as a bot sees it. Orphan pages, broken internal links and pages buried five clicks deep are found here.
- Is crawl budget going somewhere useful? Faceted navigation, session parameters and endless pagination quietly consume the crawl on stores. Control them before optimising anything.
- Is there one canonical version of each page? HTTP/HTTPS, www/non-www, trailing slashes, parameter variants — each split is diluted authority.
- Does the page render for a bot? Client-side rendered content that depends on JavaScript sometimes indexes and sometimes does not. Check the rendered HTML, not the source.
- Is the page fast on a mid-range phone? Field data, not a lab score on a fast laptop.
What we deliberately leave out
Meta keyword tags. Keyword density. Word count targets. Fixing every H1 warning on pages with no traffic. These fill audit documents and change nothing.
If a finding does not come with an estimate of what fixing it is worth, it should not be in the audit.
How to keep it honest
Record the ranking and traffic position before the fixes go live, ship them in batches rather than all at once, and annotate the analytics on each deploy date. Six weeks later you can say which change did what — which is the only way an audit ever earns a second one.
Ahmed KhanzadaFounder & Chief Executive Officer, AffilioTechAbout the author