A technical SEO audit should answer one question before any other: what is costing us search visibility right now, and in what order do we fix it? On most sites the honest answer runs the same way, indexing before crawl efficiency, then Core Web Vitals, then schema, then the plumbing everyone defers. This guide gives you that triage, and a 90-day plan that sequences the work so each fix compounds the last instead of blocking it.
Start with measurement, not fixes
The reason two teams can run the same audit and get different results is rarely effort or budget. It is that one team measured first. Before you change anything, capture the state you will be judged against: export the Performance and Page indexing data from Google Search Console, run a full crawl in Screaming Frog or Sitebulb, save your Core Web Vitals field data, pull baseline traffic and conversions from GA4, and on larger sites sample the server logs into BigQuery. Park all of it in a Looker Studio dashboard so month three has something to compare against, because in that meeting memory is not evidence. While you are in there, kill the outright blockers a first crawl always surfaces: an accidental noindex on a money page, a robots.txt rule swallowing a whole directory, canonicals pointing at the wrong domain, 5xx errors on a key template. These take hours, not sprints, and each one silently caps everything you do later.
First, can your money pages be indexed?
Open the Page indexing report in Google Search Console before you open anything else. The two statuses that matter most are “Crawled, currently not indexed” and “Discovered, currently not indexed”. The first usually means quality or duplication, Google saw the page and declined it. The second usually means crawl prioritisation, Google has not fetched it yet. Inspect each commercially important URL with the URL Inspection tool, confirm the indexed version is the canonical you expect, and hunt for stray noindex tags and canonicals aimed at the wrong URL. This comes first for a plain arithmetic reason: everything later in the audit improves signals, and signals only register on pages that are in the index. Indexation is the multiplier on every other fix, so it goes first even when a more interesting problem is shouting for attention.
Second, stop wasting crawl on pages you do not want
Crawl budget is a real constraint mainly past the tens of thousands of URLs, but waste dilutes signals on smaller sites too. The usual offenders are faceted navigation, parameter URLs, internal search results, thin paginated archives and infinite calendar pages. Find them in the Crawl stats report and, on bigger sites, in the server logs you loaded into BigQuery. Fix with robots.txt disallows for pure waste, noindex for pages that must exist but not rank, and canonical tags for genuine duplicates. Then rebuild the XML sitemap so it contains only indexable, canonical, 200-status URLs, because a clean sitemap is your plainest statement of what deserves to rank.
Third, Core Web Vitals, read in field data
The thresholds are public: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1, each at the 75th percentile of real users. Work from the Core Web Vitals report in Search Console and the field data in PageSpeed Insights, not a single lab run on your office connection. LCP is usually an image or server-response problem, INP is usually script bloat, CLS is usually images without dimensions or late-loading embeds. Fix the metric that is actually failing rather than chasing a perfect lab score. One scheduling note decides where this sits in the plan: field data lags roughly a month, so speed fixes are best shipped against a stable baseline, which is why they land late rather than early. Low-traffic pages may show no field data at all; read lab tests as direction then, not verdict.
Fourth, schema that earns something specific
Prioritise schema markup with a visible payoff: Article for posts, Product with price and availability for commerce, LocalBusiness for physical locations, Organization site-wide, BreadcrumbList for structure. Validate with the Rich Results Test and watch the enhancement reports in Search Console for errors. Beyond rich results, accurate markup feeds the answer engines now summarising pages inside their own results, which makes schema one of the few audit items whose value is still rising rather than fading.
Fifth, the plumbing everyone defers
Redirect chains that leak signals, internal links to 404s, mixed trailing-slash conventions, orphan pages with no internal links, hreflang errors on international sites. None is dramatic alone; together they are friction on every crawl and every click. A crawler such as Screaming Frog or Sitebulb, cross-referenced with GA4 to catch pages that get sessions but sit outside the crawl, will surface most of it, and a scheduled site audit in Ahrefs or Semrush keeps the list from growing back. Export findings by template rather than by URL wherever you can, because one template fix usually closes hundreds of rows at once.
The 90-day plan: sequence the fixes so they compound
The order above is also the schedule. Weeks one and two are baseline and blockers. Weeks three and four are indexation and nothing else, because the point is to get earning pages into the index before you spend effort improving their signals. Month two is crawl efficiency and template-level repairs: those need developer time, which you deliberately booked during month one while doing indexation work that needed none, and the index changes from month one are still settling, so this is exactly when Google recrawls you most attentively and notices the cleaner architecture. Month three is speed, then schema, both read against the stable baseline the earlier phases created. Run the sequence backwards and it falls apart, you would spend month one on speed fixes for pages that are not indexed, measured against nothing, with developer goodwill spent before the template work begins. Momentum here is a scheduling outcome, not a personality trait.
Day 91: measure again, honestly
Re-crawl the site, pull the same reports you saved in week one, and write the comparison up plainly, including what did not move. Blend the before and after in Looker Studio so the trend is legible to people who will never open Search Console. That honest document, not a fresh two-hundred-row spreadsheet, becomes the plan for the next ninety days, and this time it starts from data you created on purpose.
Key takeaways
- Order the audit by what is costing visibility now, not by what is imperfect; most audits then collapse into a short list.
- Measure first. A baseline in GA4, Google Search Console and Looker Studio is the only way to prove what your fixes did.
- Indexation is the multiplier: fix it before crawl efficiency, speed or schema, because signals only count on indexed pages.
- Read Core Web Vitals in field data at the 75th percentile, and schedule speed late because field data lags about a month.
- Sequence beats effort. The same fixes compound or stall depending only on the order you ship them in.
If you would rather have this run for you, our Technical SEO Audits service delivers the baseline, the prioritised fix list and the day-91 comparison as one managed piece of work; email digitalstrategy@globalcharter.com to scope it.
Frequently asked questions
How long does a technical SEO audit take?
The audit itself is a few days of crawling and analysis across Screaming Frog or Sitebulb and Google Search Console. The fixes are the real timeline, and the 90-day plan above exists because shipping them in the right order is what produces results, rather than closing every ticket at once.
Which tools do I actually need?
Google Search Console and one crawler, Screaming Frog or Sitebulb, cover most of a technical SEO audit. Add GA4 for traffic and orphan-page checks, PageSpeed Insights for Core Web Vitals, and, on larger sites, BigQuery for server logs and Looker Studio for reporting. Ahrefs or Semrush are useful for ongoing site audits and visibility tracking.
Should I fix everything the audit finds?
No. Most findings are low-value warnings that cost more to close than they return. Fix the items that block indexing, waste crawl, fail a Core Web Vital in field data or break schema first, then judge the rest against the revenue each page protects.