Chapter 5: Technical SEO

Technical audit SOP for a site you have just inherited

Twelve checks, in this order. Do not open a ticket until you have run all twelve — half the “issues” found in step three disappear once you know the answer to step one.

1. Crawl the site. Screaming Frog or an equivalent, full site if it fits, otherwise a stratified sample that includes each template. Export status codes, titles, meta, canonicals, H1s, word counts, indexability.
2. Read robots.txt from the outside. Fetch it as a URL, not as a file on your laptop. Look for a leftover Disallow: / in a staging block, and for rules that block CSS or JS the renderer needs.
3. Validate the XML sitemap. Fetch it, check it returns 200, check for non-canonical and 4xx URLs inside it, and confirm it is submitted and parsed in Search Console.
4. Audit indexation state. In the Page Indexing report, read the reasons, not just the totals. A large “crawled — currently not indexed” bucket is a quality signal, a large “discovered — currently not indexed” bucket is a crawl-priority signal.
5. Hunt duplicates. Duplicate titles, duplicate H1s, parameter permutations, trailing-slash and case variants, and every URL pattern that resolves to the same content without a canonical pointing at one of them.
6. Map the redirect graph. Chains, loops, 302s used where 301s belong, and internal links still pointing at redirected URLs — every internal redirect is a small tax on crawl budget.
7. Test rendering. Compare raw HTML with the rendered DOM on the main templates. Anything important that exists only after JavaScript is a risk you should be able to name and quantify.
8. Measure Core Web Vitals. Field data first (CrUX or Search Console), lab data second. Record LCP, INP and CLS per template, not per site — an average hides the template that matters.
9. Check transport and security. HTTPS everywhere, no mixed content, no certificate chain problems, HSTS in place if the team supports it.
10. Validate structured data. Sample each template through a validator, not a single page you happen to like. Watch for required fields going empty because a CMS field was renamed.
11. Read the logs if the site is large. Bot hits by directory, status code distribution, and which sections consume crawl budget without earning traffic.
12. Write the report for the person who will do the work. Severity, evidence, affected URLs, expected impact, effort, owner. An audit that lists 400 issues without a priority order is a research paper, not a plan.

Interview questions and answer frameworks

Q1: A large number of pages are “crawled — currently not indexed”. What do you do?

Framework: Start with the interpretation, because it drives the fix: the engine fetched the page and decided it was not worth storing. That is a quality judgement, not a technical error — telling the client “we’ll resubmit the sitemap” is not an answer. Then investigate in three directions. Content: sample the pages and look for thin pages, near-duplicates generated by a template, or AI text with no unique information. Site-level trust: on a young or low-authority domain, the engine is simply stricter about what it stores. Demand: pages nobody searches for and nobody links to have no reason to be indexed. Fixes follow from which of the three dominates: merge or improve the thin pages, add internal links from pages that are already indexed and performing, and use noindex for pages that exist only for site functionality. Be honest that recovery is slow and measured in months.

Q2: What is render blocking and how do you fix it?

Framework: Any resource the browser must fetch and process before it can paint the first meaningful screen — typically blocking CSS and synchronous JavaScript in the head. Fix in order of impact: inline the critical CSS for above-the-fold content and load the rest asynchronously; mark non-critical scripts defer or async; preload the one or two assets the first screen genuinely needs; audit third-party scripts and remove or delay everything that is not earning its cost. Then measure again — the goal is LCP under 2.5 seconds on the templates that receive traffic, not a perfect lab score on a page nobody visits.

Q3: What do you check before, during and after a site migration?

Framework: Before — crawl and archive the old site completely, export every URL, build a one-to-one redirect map (not a blanket rule), freeze content changes, and stage the new site with robots blocked so it cannot be indexed early. During — switch DNS, verify redirects resolve in one hop, spot-check status codes per template, update internal links and the sitemap, and confirm analytics still fires. After — file a Change of Address for the old domain if the domain itself moved, watch 404s hourly for the first days, compare crawl stats and index coverage weekly, and track rank and traffic against the pre-migration baseline for at least eight weeks. Name the two classic failures explicitly: redirecting everything to the homepage, and launching with the new URLs accidentally blocked. Both cost more than the entire migration.

Q4: How do you prioritise a 400-item technical backlog?

Framework: Score each item on three axes: does it affect pages that carry traffic or revenue, does it affect crawl or indexation of those pages, and how expensive is it to fix. Anything that blocks indexing of high-value URLs outranks everything cosmetic, even if the cosmetic list is longer. Then group by owner: what only engineering can do, what content can do, what you can do this week. Publish the top ten with expected impact, and re-score monthly — a backlog that never shrinks is usually a prioritisation failure, not a capacity failure.