The technical SEO audit. Our step-by-step process.

What a technical SEO audit actually is

A technical SEO audit is a structured inspection of every part of your site that decides whether Google can crawl, render, index and rank your pages. It is not a content review. It is not a link review. It is the under-the-bonnet check that runs through robots rules, sitemaps, redirects, canonical tags, JavaScript rendering, mobile usability, Core Web Vitals and the dozen other things that have to be true before a single keyword can earn a position.

The output of a real audit is a triaged fix list. Each item names the URL or template, the issue, the suspected traffic impact, the fix and the team that needs to do it. The list is sorted so the highest-impact, lowest-effort items sit at the top. The bottom of the list is the "nice to have when there is time" pile. That is the deliverable. Not a 60-page PDF. Not a screenshot album. A spreadsheet of decisions.

Two distinctions matter before we get into the steps. First, an audit is a snapshot, not a process. Running the audit once is the starting line, not the finish. The findings have to ship as code changes, content edits and tracking. Without the follow-through, the audit is decoration. Second, the audit covers technical issues only. On-page work (title tags, headings, internal copy) and off-page work (backlinks, brand signals) need their own audits. Trying to combine all three into one document is how clients end up with a 200-page deck nobody reads. Our standard delivery splits them.

Why an audit matters

Two reasons. Defensive, because most sites are bleeding traffic from issues nobody has checked for. Offensive, because the fixes you find usually compound across the whole site.

Defensively, the patterns we see are remarkably consistent. The 18-suburb tradie page set canonicalised to the homepage. The Shopify theme blocking the collection URLs in robots.txt. The HTTPS migration that left half the internal links pointing at http://. The React build with no server-side rendering on the bio pages. The 200 redirect chains accumulated over five years of "we will tidy that up later". Every one of those is invisible until someone audits for it.

Offensively, technical fixes scale across the entire site. Fix one canonical pattern and 800 URLs benefit at once. Clean up the sitemap and Google starts crawling the right pages. Compress the hero image template and Core Web Vitals improve across the whole catalogue. Compare that with content work, where one new page earns traffic for its own keyword set only. Technical wins multiply.

One more reason worth naming. Audits force a conversation. Before an audit, the developer says the site is fine, the marketer says SEO is the agency's problem, and the owner does not know what to ask. After an audit, there is a list. The list has names against each item. Suddenly the conversation is about priorities and timelines instead of vibes. Half the value of an audit is in unsticking the internal politics around technical work.

The nine-stage process

We run every audit in the same order. The order matters because earlier stages tell you what to look for in later stages. Skipping stages or running them out of order leaves blind spots.

Stage 1. Indexation and coverage

First question, always: how many of your URLs are actually in Google's index? Open Search Console, go to the Pages report (formerly Coverage). Note the indexed count. Note the not-indexed count. Read every reason in the "Not indexed" breakdown. Look for spikes in the time-series chart: a sudden jump in "Crawled but not indexed" or "Discovered but not currently indexed" tells you something changed.

Then run the site: operator in Google. If your site has 2,400 URLs in the sitemap and 8,000 show up in site:yourdomain.com.au, you have an indexing problem. Most likely cause: parameter URLs being indexed instead of canonicalised. Less common but more painful: a CMS spitting out duplicate URL patterns for the same content.

What to capture: indexed count, sitemap-submitted count, the gap between them, and any "Not indexed" categories with more than 50 URLs in them.

Stage 2. Robots.txt and meta robots

Open https://yourdomain.com.au/robots.txt in a browser. Read every line out loud. Yes, out loud. We have caught accidental Disallow: / rules four times this way that we missed reading silently. If a line begins with Disallow:, ask "what does that block, and was that intentional?". For each Allow: rule, check it sits after the relevant Disallow:.

Then crawl the site with Screaming Frog. In the report, sort by Meta Robots tag. Look for any pages with noindex that should not have it. The most common offenders: thank-you pages that someone forgot, tag archives in WordPress that the SEO plugin defaulted to noindex, and entire template folders accidentally noindexed during a theme migration.

Full chapter on this: robots.txt and meta robots.

Stage 3. XML sitemap

Find the sitemap. It lives at /sitemap.xml on most sites, sometimes at /sitemap_index.xml on WordPress with Yoast or Rank Math. If it is missing entirely, that is finding number one already.

Open the sitemap. Read the URLs. Confirm three things. One, every URL is HTTPS. Two, every URL is the canonical version (no ?utm_, no trailing-slash inconsistencies, no parameter URLs). Three, no URL in the sitemap is also noindexed, blocked by robots.txt or returning a non-200 status code. The single most common sitemap failure we see is a CMS dumping every URL it knows about, including thank-you pages, into the sitemap because nobody told it not to.

Submit the sitemap in Search Console and check the success rate. If it says "Couldn't fetch" or shows error counts, those are open tickets. The full breakdown is in XML sitemaps explained.

Stage 4. The full Screaming Frog crawl

Now we go wide. Run a Screaming Frog crawl with default settings. For larger sites, set a crawl limit of 50,000 URLs and respect robots.txt. Let it finish. Then export six reports:

1. Status codes: anything that is not 200 OK is a flag. Group the 301s, 302s, 404s and 5xx errors.
2. Indexability: count pages marked "Non-Indexable". Note the reason for each.
3. Canonicalisation: pages with canonicals pointing at a different URL. Most should self-reference. Anything pointing elsewhere needs justification.
4. Page titles and meta descriptions: missing, duplicate, over-length. This is technically on-page but the data is right here.
5. Internal links: pages with zero inbound internal links. These are orphan candidates.
6. Hreflang errors (if applicable): missing return tags, conflicting language declarations.

This stage takes longest. It is also where 60 percent of audit findings come from.

Stage 5. Redirects

From the Screaming Frog crawl, isolate every 301 and 302. Three checks:

One, redirect chains. Any URL that hops more than once before reaching the final destination is a chain. Two hops is acceptable. Three or more is a fix. Each hop loses a small amount of authority and adds latency. We have inherited sites with seven-hop redirect chains accumulated over a decade.

Two, 302s that should be 301s. A 302 (temporary) is rarely the right choice. If the move is permanent, change it to a 301. Full breakdown in 301 vs 302 redirects.

Three, redirect loops. A redirects to B, B redirects back to A. Pages caught in a loop never get indexed. Screaming Frog flags these explicitly.

Stage 6. Canonical tags

Every page should have a <link rel="canonical"> tag in the head. Most should self-reference. Variants (paginated archives, faceted product listings, parameter URLs, print versions) should point to the canonical version. Cross-domain canonicals (where one site canonicalises to another) should exist only when there is a deliberate syndication arrangement.

The most common error: a developer adds a self-referencing canonical generator to the template but does not exclude the parameter URLs. Result, /product?colour=blue&size=large self-references and competes with /product/ for indexing. The full guide is in canonical tags explained.

Stage 7. Mobile and rendering

Open Search Console, use Inspect URL on five templates: the homepage, a top service page, a product page, a blog post and a location page. Click "Test live URL" and then "View tested page". Compare the rendered HTML to what your CMS exports. If big chunks of content are missing, you have a rendering problem. Almost always a JavaScript framework that builds the page client-side without server-side rendering.

This is the check that catches React, Vue and Nuxt sites where Googlebot sees an empty shell. Run it before assuming the rest of the audit is even valid; if Google cannot see the content, every other finding sits on top of a more fundamental problem. Full guide: JavaScript SEO essentials. Then check mobile-first indexing for the desktop-vs-mobile parity questions.

Stage 8. Core Web Vitals

Go to PageSpeed Insights. Run it on the same five templates from stage seven. Capture the field data (real-user data over the last 28 days), not the lab data (synthetic test). Field data is what Google uses for the ranking signal.

For each template, note LCP, INP and CLS. Anything in the red is a fix. Anything in amber is a watchlist item. The detailed work happens in the Core Web Vitals pillar, but the audit just needs to capture which templates fail and roughly why.

Stage 9. Triage and prioritise

Pull every finding from stages one through eight into a single spreadsheet. For each row, add four columns: traffic impact (high, medium, low), effort (hours estimated), team (SEO, developer, content), and dependency (does another fix have to ship first?).

Sort by traffic impact descending, then by effort ascending. The top of the list is the quick-win pile. The bottom is the long-term backlog. Hand the spreadsheet to whoever can ship the work. Schedule a fortnightly check-in to keep the list moving.

That is the audit. Nine stages, 28 checks, half a day to two days depending on site size. The full audit document we deliver also includes a written summary, screenshots of the biggest finds and a one-page risk register. Those are the cosmetics. The spreadsheet is the substance.

Common audit mistakes

If you have been handed a technical audit that does not look like the "good" column, ask for the spreadsheet. If there is no spreadsheet, the audit is not finished.

Tools and checklists

The minimum kit:

1. Google Search Console. Free. The Pages report, Crawl Stats, Sitemaps and Inspect URL cover stages one, two, three and seven. Search Console is non-negotiable.
2. Screaming Frog SEO Spider. Free up to 500 URLs. Paid for anything larger. The single most useful crawler for stages four, five and six.
3. PageSpeed Insights. Free. Field-data Core Web Vitals. The Lighthouse-based lab data is interesting but not the ranking signal; field data is.
4. A spreadsheet. Whichever one. Google Sheets, Excel, Airtable, Notion. The audit is a spreadsheet.
5. Our free SEO audit tool. Pulls Lighthouse, indexability checks, schema validation and keyword data for any URL. A useful first-pass to know whether a deeper audit is needed. Run a free audit.

The more advanced kit for larger sites: log file analysis (we cover that in log file analysis for SEO), an enterprise crawler like Sitebulb for sites above 100,000 URLs, and the Schema.org validator for structured-data work.

If you would rather skip running the audit yourself and have us deliver the spreadsheet, that is the website audit service. The ongoing fixes after that sit inside the SEO retainer. If the site is slow specifically, speed optimisation is the focused engagement.

Perth and WA context

We do a lot of these. Some patterns recur often enough that they deserve calling out.

Perth metro multi-suburb businesses (trades, healthcare, professional services) almost always have a canonical or duplication issue across their location pages. The 18-suburb tradie set is a real recurring shape. Two hours of canonical and internal-link work typically lifts the whole set into the local pack across Perth, Joondalup, Fremantle, Cockburn, Mandurah and Rockingham.

Bunbury and Busselton businesses sometimes inherit sites built by Perth metro agencies that never localised the technical signals: schema with a Perth address on a Bunbury-only practice, hreflang or geo tags missing. Easy fixes, but only if someone audits for them. The Bunbury SEO and Busselton SEO pages on our site exist because the South West has its own audit pattern.

Kalgoorlie, Karratha and Port Hedland businesses serving the mining sector tend to have catalogues built on legacy CMS platforms. The audits there usually surface render-blocking JavaScript, missing structured data, and URL patterns that fight the canonical generator. Karratha SEO sees this most often. The mining SEO industry page covers the broader pattern.

Mandurah and Rockingham e-commerce on Shopify and WooCommerce frequently has the same Shopify theme robots.txt issue or the same WooCommerce variant-URL crawl-budget waste. Same fixes, same sites, every audit.

One pattern that crosses all of these. The site was built by a developer who has since moved on. Nobody at the business has read the robots.txt or the sitemap. Nobody has Search Console set up properly. The audit is the first time anyone has looked under the bonnet. The findings are not exotic. They are the basics, and the basics are worth a meaningful chunk of organic traffic.

Related guides

• Back to the Technical SEO pillar for the full 12-chapter index.
• Canonical tags explained. The tag that causes more audit findings than any other.
• Robots.txt and meta robots. Stage two of the audit, in full.
• XML sitemaps explained. The full breakdown of stage three.
• 301 vs 302 redirects. Everything we look for at stage five.
• JavaScript SEO essentials. The rendering check from stage seven.
• Log file analysis for SEO. The advanced diagnostic for large sites.
• Site migration SEO checklist. The audit's older sibling for replatforms.
• Crawling, indexing and ranking. The conceptual prequel to the audit.
• Internal linking strategy. Where orphan pages from stage four go to get fixed.