SEO

20 technical SEO questions we ask before we hire anyone.

By Ridho Putradi S'GaraAug 6, 202629 min read
// share
// table_of_contents▸
► Listen to this post

technical seo interview questions

Most technical SEO interviews just test memory. You ask what a canonical tag does, the person gives you the textbook line, everyone nods, and you come away knowing they can read documentation. You still have no idea whether you can hand them a live migration.

The questions below are meant to get past that. Every one has a tidy answer a sharp junior can memorise, and then a real answer that only turns up once someone has had to fix the thing on an actual site. The second answer is the one we care about.

We use these to hire technical SEOs at Search Agency, and I'm putting the whole list here for two reasons. If you're prepping for an interview, it shows you the kind of depth that gets people hired instead of the surface that gets them a polite no. And if you do the hiring yourself, take it, it's yours. A good set of interview questions isn't a secret, it's just annoying to write.

One thing before you start. We're not after the person who knows the most facts. We're after the person who knows when a rule stops being true, who tries the cheap fix before the clever one, and who can tell you what they'd look at first when traffic falls off a cliff on a Friday afternoon. Each question ends with a few things worth reading, mostly Google's own docs, plus the original research wherever I've quoted a number.

1. What is the difference between crawl budget and crawl demand?

Crawl budget is the umbrella term, the number of URLs Googlebot both can and wants to fetch on your site in a given stretch of time. Underneath it are two separate things. Capacity is what your server allows, and it moves with response time and error rates, so a run of 5xx or 429 responses has Google backing off within hours. Demand is what Google wants, and it moves with how popular a URL is, how often it actually changes, and how much Google rates the inventory as a whole.

Those two fail in opposite directions, which is the point of pulling them apart. A quick server buried in thin duplicate content has all the capacity in the world and no demand, so nothing gets crawled however much hardware you throw at it. A site people actually want, sitting on a slow host, gets throttled while Google is still asking for more, and the fix there is the server, not the writing.

The best thing a candidate can do with this one is tell you it usually doesn't matter. Google's own line is that crawl budget is a concern for sites over a million pages changing weekly, or ten thousand changing daily. On a three hundred page brochure site it's a non-issue, and knowing not to chase it is worth more than reciting the definition.

Further reading

2. Is a canonical tag a directive or a hint?

A canonical tag is a hint, not an instruction, and that difference is exactly why the question is useful. Google reads rel=canonical as one vote among several, weighed against your redirects, your internal links, which version sits in the sitemap, HTTPS, hreflang, and the external links pointing at each variant. When those disagree with the tag, Google goes with its own read, and you see it in Search Console as "Duplicate, Google chose different canonical than user."

So the tag on its own is never enough. If page B should defer to page A, then the internal links, the sitemap, the breadcrumbs and the hreflang all have to say A as well, because contradict yourself and Google throws the lot out. Mismatched signals are far and away the most common reason a canonical gets ignored, and anyone who has untangled a site where the tag said one thing and every link said another already knows it in their bones. It helps to be clear about what a real directive looks like by comparison, noindex in a meta robots tag or the X-Robots-Tag header, which Google does obey, and Disallow in robots.txt, which controls crawling rather than indexing.

Further reading

3. What is the difference between meta robots and robots.txt?

The simplest way to hold these two apart is by when they act. Robots.txt works before the fetch and controls crawling, so it answers whether a bot may request the URL at all. Meta robots and the X-Robots-Tag work after the fetch and control indexing and display. The catch that trips people up is that a URL blocked in robots.txt can still show up in results as a bare link with no description, because Google never fetched it and so never saw the noindex you were counting on. Block the crawl and you block the instruction you actually wanted read.

robots.txtMeta robots / X-Robots-Tag
StageBefore the fetch (crawl control)After the fetch (index and serve control)
ScopeSitewide, by URL path patternPer page, or per file via the header
Question it answersMay I fetch this?May I index and display this?
Needs the page fetchedNoYes, the bot has to download it to read the tag
File typesAny URLMeta tag is HTML only; X-Robots-Tag works on PDFs, images, any response

Once that clicks, the right way to pull a page out of the index is obvious. Leave it crawlable, serve noindex, wait for the recrawl and for the page to drop, and only then block it in robots.txt if you want to stop wasting crawl on it. The extra marks go to whoever adds that robots.txt is public so it's no place for sensitive paths, that it's per host and per protocol, that blocking CSS and JS wrecks rendering, and that a noindex line inside robots.txt hasn't worked for years.

Further reading

4. How do you fix a "Crawled, currently not indexed" status?

Read the label literally, because plenty of people don't. Google fetched the page, had a look, and decided not to index it. That's a verdict on value, not a bug, and hitting "request indexing" again won't change its mind.

The usual reasons sit in a small cluster. The page is thin, or too close to something already indexed. It's barely linked, orphaned or five clicks deep or only reachable from the sitemap, which reads as you not rating it either. The whole domain has a quality problem and new pages inherit the doubt. Or the content only loads after JavaScript runs, so the first look is an empty shell.

The fix follows the reason. Be honest about whether the page deserves to be indexed at all, since the answer is often to merge or drop it rather than force it in. If it stays, give it something the pages already indexed don't have, link to it from pages Google crawls often, pull it nearer the homepage, and check the rendered HTML actually contains the words. Then trim the sitemap down to URLs you'd stand behind, and wait, because on a big site this plays out over weeks. The related status, "Discovered, currently not indexed," is a different animal, Google knows the URL exists but hasn't even fetched it, and that one points at crawl budget or server speed instead.

Further reading

5. What factors influence Google's crawl budget?

Sort the factors into the two halves and the answer stays clean. Capacity is your server's business, response time, error rates where 5xx and 429 responses bite hardest, hosting quality, timeouts. Demand is Google's, the pull of links and traffic to a URL, how often it really changes, how good the inventory looks overall, big one-off events like a migration, and honest lastmod dates in the sitemap.

The part people forget is the third bucket, everything that burns the budget you've already got. Faceted URLs multiplying into the millions, session IDs and tracking parameters left crawlable, redirect chains where every hop costs a fetch, soft 404s handing back a 200 on empty pages, the www and non-www and trailing-slash twins, internal search results linked into the crawl. You almost never raise crawl budget by asking for more of it, you raise it by fixing the server, cutting the waste, and giving Google reasons to want the pages that matter.

Further reading

6. What is a crawl trap, and can you give a real example?

A crawl trap is any URL setup that spins out a basically infinite number of crawlable URLs, so a bot pours its budget into pages that lead nowhere and never reaches the end. I ask for an example because the definition is easy to parrot and the examples aren't, and the one someone reaches for tells you fast whether they've actually met one.

The one that comes up most is faceted navigation on a shop. Eight filters, each with a few values, plus sort order and page size, and because the parameters can appear in any order you get a fresh URL for every combination, so ?color=red&size=m and ?size=m&color=red are two addresses holding the exact same products. Eight facets can turn four hundred products into millions of URLs. Infinite calendars are the other favourite, a booking site linking "next month" forever until Googlebot is happily crawling years with nothing in them. Then there are relative-path bugs that recurse into /shoes/shoes/shoes/, session IDs that mint a new URL on every crawl, and "popular searches" boxes that link into internal search results, which link into more searches.

Fixing them starts further back than people expect. You stop generating the links in the first place, then disallow the parameter patterns you never want fetched, sort parameters into a fixed order on the server, cap how many filters can stack, and put a sane limit on things like calendar range. The bit that marks someone out as senior is the last step, going back to the logs to confirm Googlebot actually stopped, rather than assuming it did because the tickets are closed.

Further reading

7. How do you optimise a website for Google AI Overviews?

The honest starting point is that there's no separate rulebook for AI Overviews. Google says the same things it says for Search, useful content, a page that can be crawled and indexed, sensible internal links, decent page experience, and structured data that matches what's on the page. Anyone selling a secret AIO trick is guessing. What shifts is the emphasis.

The base still has to be right, a page that's crawlable and indexable and served as HTML that doesn't lean on JavaScript for its main content, and ranking well in the normal results still helps a lot, even though the sources that get cited aren't always the ones sitting at the top. On top of that, most of the real work is making the content easy to lift. Write headings as the question someone would actually type, put a straight answer of roughly forty to eighty words right under the heading before you expand on it, and make each section stand on its own so it still reads when it's pulled out of the page. Keep the numbers, dates and names inside the sentence rather than leaving them to context, because that's what ends up in the summary.

Trust decides as much as structure does. Real authors with real credentials and entity markup, first-hand data and testing, facts that are current with the update date on show, structured data that matches the page, and a presence off your own site in the places a model has already read. AI Overviews also lean toward informational, comparison and multi-part questions, so it pays to map the People Also Ask set and answer each one out loud.

The measurement side finally moved this year. On 3 June 2026 Google launched Search Generative AI performance reports in Search Console, with their own view of impressions inside features like AI Overviews and AI Mode. They break impressions down by page, country, device and date but don't show clicks, CTR or queries yet, so until the rollout is wider the working proxy is watching impressions climb while CTR slides on your priority queries, backed up by actually looking at the SERPs. And the caveat to say out loud, citations move around, Google swaps sources without an obvious pattern, and grinding every page down into extractable snippets at the cost of real depth tends to come back on you.

Further reading

8. What technical SEO factors help LLMs understand your website?

The factor that matters more than all the others is server-rendered HTML, because most AI crawlers barely run JavaScript, so anything that only appears after the client renders is often just invisible to them. Around that sit the access questions, how you treat agents like GPTBot, ClaudeBot, PerplexityBot and Google-Extended in robots.txt, whether your WAF or CDN is turning legitimate crawlers away by mistake, and whether your URLs stay put over time, since a citation points at a URL and link rot wipes out the references you've built up.

Then there's comprehension. Clean semantic HTML with a real heading order, content broken into sections that stand alone because retrieval works on passages and not whole pages, structured data that pins down who you are with Organization, Person, Article and sameAs, the same entity details repeated consistently across your site and the wider web, and the actual content sitting in the initial HTML instead of hidden behind tabs and accordions. None of it is exotic. It's the same hygiene that helps a normal crawler, done with the knowledge that the thing reading you is stitching passages together.

On llms.txt, better to be straight than trendy. It's a community idea, not a standard, and the evidence that it helps you get found is thin. Ahrefs found that 97% of llms.txt files got zero AI bot requests in May 2026, Google's John Mueller said back in mid-2025 that no AI system uses it, and Google has since confirmed it changes nothing for Search rankings. It's cheap to publish and does have a genuine use for agent and developer retrieval, so the sensible line is to not sell it to a client as an AI visibility play. Pointing the other way, work from Rutgers Business School and The Wharton School found that news publishers who blocked AI crawlers lost around 7% of weekly traffic within six weeks, and it showed up in human visits, not just bot logs, which makes blocking a real cost rather than a free bit of caution.

Further reading

9. When should you use a 301 redirect instead of a 302?

A 301 says the move is permanent, so the target takes the source's place in the index and the ranking signals flow onto it. That's what you want for migrations and domain changes, for rewriting URL structures, for pushing HTTP to HTTPS and www to non-www, for retiring a page toward its nearest replacement, and for merging two pages that have been competing with each other. A 302 says the original is still the one to keep, which fits A/B tests, temporary geo or language routing, a product that's briefly out of stock, and short campaigns you're going to reverse.

The detail is where this gets interesting. Google will eventually treat a 302 that never goes away as a 301, but you should still say what you mean rather than lean on that. Keep chains to one hop where you can and never much past three, and update the links at the source instead of piling redirect on redirect. Don't dump everything onto the homepage in a migration, Google reads an irrelevant redirect as a soft 404 and the signals don't carry across, and keep the old redirects alive for a year afterwards while you watch the logs for Googlebot to stop asking for the old URLs. Anyone who brings up 307 and 308 as the method-preserving versions has usually read the actual spec rather than a summary of it.

Further reading

10. How do you investigate a sudden organic traffic drop?

The answer worth hearing has a fixed order, because the whole skill is ruling out the cheap explanations before you spend money on the expensive ones. First job is proving the drop is even real, since a good number of them are just tracking breaking, so you check the tag deployment, the analytics config, the consent banner, and whether Search Console clicks fell in step. If GSC is steady and analytics has cratered, the problem is in your measurement, not in search.

Once it's real, you work out exactly what fell by slicing Search Console by date, page, query, country, device and appearance, because the shape of it names the cause. Impressions and position both down means you lost rankings. Impressions and position flat with CTR down means the SERP changed around you, an AI Overview or a new feature or a rewritten title. A drop on one template is something structural on that template. A flat, even drop across everything is an algorithm update or a site-wide problem.

After that it's mechanical. Check the Pages report for a swing in indexed versus excluded, hunt for a stray noindex or a Disallow: / that escaped from staging, look for canonicals pointing somewhere odd after a deploy, and rule out server errors, an expired certificate, or a robots.txt throwing a 5xx, which Google eventually treats as a full block. Manual actions and security issues are two clicks away, so check them early rather than last.

Only then do you line the date up against known algorithm updates and read your own history, deploy logs, template changes, content you pruned, and put a fresh crawl next to an old one. The habit that marks out someone experienced is forming one hypothesis and testing it, instead of changing ten things at once and learning nothing about which one worked.

Further reading

11. What is the difference between indexing and ranking?

Indexing is getting a URL into Google's index so it's allowed to show up for queries, and it covers everything from discovery and crawling through rendering, parsing, canonical choice, and the underlying call on whether the page is even worth keeping. Ranking is the order Google puts already-indexed pages in for a specific query at a specific moment, based on relevance, intent, quality, context and location. The order runs one way. A page has to be indexed before it can rank, being indexed promises nothing about ranking, and a URL can sit in the index for years without ever getting an impression. The reason it's worth being precise is that it splits a problem cleanly in two. If a page isn't indexed you look at crawling, robots rules, canonical choice, content quality, internal links and server health, and if it's indexed but not ranking you look at relevance, depth, authority, competition and cannibalisation. Checking index status first saves you rewriting a page for relevance when the real issue is that it's blocked in robots.txt. And once you know canonical choice happens during indexing, you understand why a page Google folded into another URL isn't really in the index on its own terms, and why "we rank number four" means nothing until someone says for what, where, and on which device.

Further reading

12. What are the most important Core Web Vitals for SEO?

The three metrics are Largest Contentful Paint at 2.5 seconds or better, Interaction to Next Paint at 200 milliseconds or better, which took over from First Input Delay in March 2024, and Cumulative Layout Shift at 0.1 or under. Anyone can list those. The question is really about perspective, and the honest read is that Core Web Vitals are a light tie-breaker inside page experience rather than a heavy ranking factor, so they rarely explain a real drop on their own, and no amount of speed work will push a thin page above a better one.

Within that, LCP is usually the one that matters most, because it tracks how fast the page feels, which ties straight to bounce and conversion. INP earns its keep on heavy interactive apps and shop filters. CLS shows up where ads, late fonts or unsized images shove the layout around, and it's often the cheapest of the three to sort out. Knowing which lever belongs to which template beats knowing the three numbers.

What shows someone really gets it is the data behind the scores. Google uses field data from the Chrome User Experience Report, not the lab score in Lighthouse, so a perfect PageSpeed number sitting on bad field data means nothing for ranking. It's measured per URL where there's enough traffic and falls back to origin-level grouping where there isn't, which is why quiet pages inherit the site's numbers, and the bar is the 75th percentile, so you're really fixing things for your slower visitors. The stronger case for doing the work at all is usually conversion and revenue, and that's the framing that tends to get it funded.

Further reading

13. How do you perform log file analysis for SEO?

Log files are the only record of what crawlers actually did on your site, as opposed to what a crawl simulation predicts or what Search Console samples and rounds off, and leading with that reason tells me someone trusts evidence over opinion. The work starts with getting the data, raw server logs or CDN logs where a CDN soaks up most of the requests, making sure you've got every host and both protocols, ideally ninety days of it with the full format, status code, user agent, IP, response time and referrer.

Verify the bots before you analyse anything, because user agent strings are trivial to fake. You confirm Googlebot with a reverse DNS lookup on the IP and a forward lookup back to the same address, or against Google's published ranges, and you do the same for Bingbot and the AI crawlers. Then you join the logs to a fresh crawl and to your sitemaps, since the overlaps are where the story is.

What you ask of that data is the real tell. How the crawl splits across money pages versus archives and parameters, how much is wasted on 404s, redirect chains and faceted combinations, whether 5xx or 429 rates are creeping up and explaining the throttling, which sitemap URLs never get touched, which crawled URLs are missing from both your crawl and your sitemap and are therefore orphans, and how long it takes Googlebot to first hit a new URL. Plot response time against crawl rate and you usually see the first rising just before the second falls. And none of it counts unless it changes a distribution, so you fix the waste, push links at the under-crawled pages that matter, and pull the logs again a month later to watch the shape move.

Further reading

14. Which schema types are essential for an e-commerce website?

The core set is short and goes where you'd expect. Product on the product page with an Offer holding price, currency, availability and condition, plus brand, sku, gtin and image, then AggregateRating and Review where the reviews are real, BreadcrumbList below the homepage, Organization across the site with logo, sameAs and contact details, and ItemList on category pages. The giveaway that someone has worked on merchant eligibility lately is whether they bring up shippingDetails and hasMerchantReturnPolicy, the two that turn a plain product result into a full merchant listing and that go missing far more often than they should.

Past the core, ProductGroup handles variants spread across separate URLs, and the usual supporting types, LocalBusiness, VideoObject, Article, cover most catalogues. More useful than a longer list is knowing what to warn against, that FAQ and HowTo rich results got cut back for most sites and no longer show for a typical shop, so the markup can still help a machine read the page but shouldn't be pitched as a rich result.

How it's implemented matters more than the type list, and this is the part I listen hardest for. Use JSON-LD, keep the markup matching what people actually see, because marking up prices or ratings that differ from the visible page is a spam violation, keep prices and stock in sync with the Merchant Center feed or the listings get suppressed, and validate with the Rich Results Test while watching the Enhancements report for errors at scale. Schema is a set of claims that have to be true. Treat it as decoration and you'll eventually get a client's listings pulled.

Further reading

15. What is E-E-A-T, and how do you implement it?

E-E-A-T is Experience, Expertise, Authoritativeness and Trust, and it comes out of Google's Search Quality Rater Guidelines, the manual human raters use to judge whether results are any good, not the ranking algorithm itself. The framing that matters, and the one weaker answers skip, is that it isn't a score you can dial up. Raters don't touch individual rankings, so E-E-A-T is a description of what Google's systems are trying to approximate. Google has said Trust is the most important of the four, and it weighs heaviest on the money, health and safety topics where a bad answer does real damage.

You put it into practice across all four in ways you can actually ship. Experience is first-hand, the account of having used or visited or tested the thing, your own photos, results you generated yourself instead of a stock image and a secondhand summary. Expertise is named authors with real credentials and proper bio pages, Person schema linking out to their professional profiles, and a named, dated expert review on anything in a sensitive category. Authoritativeness mostly happens off your site and outside your direct control, press, editorial links, a clear topic focus, and being a recognised entity in the graph. Trust, the big one, is complete and checkable business details, clear policy pages, honest disclosure, HTTPS and a secure checkout, current content with visible dates, and genuine reviews including the bad ones.

Underneath all that, I'm listening for honesty about what not to do, because the quickest way to fail these signals is exactly what the guidelines were written to catch, piles of unreviewed AI content under made-up author names, bought credentials, invented experience. Treat E-E-A-T as a bag of tricks and you've misread it. The point is to build a business that actually deserves trust, then make that trust easy for Google to see.

Further reading

16. How do you handle duplicate content on a large website?

The answer that works starts by sorting the duplication by type, because the right fix is completely different for each. Technical duplicates from protocol, host and trailing slash are one thing. Parameter and faceted duplicates are another. Near-identical templated pages, localised versions, syndication and an accidentally indexed staging site each behave differently again, and reaching for one tool to cover all of them is a sign of never having done it at scale.

Then you match the lever to the type. Fix it at the source first, with server rules that normalise case, protocol, host and trailing slash, since the cheapest duplicate is the one you never create. Use 301s for variants that shouldn't exist on their own, self-referencing canonicals everywhere plus variant-to-preferred canonicals where both have to stay reachable, robots.txt for the infinite spaces with no value in them, and noindex, follow for pages that need to stay linkable but out of the index. Consolidate the thin near-duplicates into fewer stronger pages, and where you can't consolidate, make them actually different with real inventory data and local detail instead of a swapped city name. hreflang handles localised duplicates as long as the return tags are right. The thing to say plainly is that there's no duplicate content penalty in the algorithm, the damage is wasted crawl, signals split across URLs, and Google picking a canonical you didn't want, and on a big site that last one is the expensive problem to keep an eye on.

Further reading

17. What is the best canonical strategy for paginated pages?

Self-referencing canonicals on every page in the series, page two to page two, page three to page three, and someone who says that without wobbling has usually cleaned up a site that did the other thing. Pointing pages two onward back to page one tells Google those pages are duplicates of page one, which they aren't, so Google may stop working through the deeper pages properly and the products linked only from them lose their way in, and on a large category that can strand thousands of items. The supporting moves are crawlable <a href> links for the pagination rather than JavaScript click handlers or infinite scroll with no fallback, titles and H1s that aren't identical all the way down the series, and leaving pages two onward indexable rather than reaching for noindex, which costs you discovery because Google crawls a permanently noindexed page less and less over time. Rel next and prev are gone as far as Google is concerned, they said so back in 2019, so keep them for Bing if you like but don't build anything on them. Sort and view parameters are a different case, ?sort=price really is the same content as the unsorted page, so canonical those to the base URL or keep them out of the crawl entirely. The judgment I want to hear is that pagination is plumbing to keep products reachable, and page one is the only part you treat as a landing page.

Further reading

18. How do you optimise faceted navigation without harming SEO?

Faceted navigation is the biggest source of large-scale technical SEO damage in ecommerce, because it multiplies URLs combinatorially, and the plan is always the same shape, decide which combinations earn a real indexable page and hide everything else from crawlers. It starts with research, because some combinations are genuine searches with volume, "nike running shoes", while price ranges and sort order and page size almost never are, so you index what people look for and bury the rest.

From there a tiered plan does the work. The combinations with proven demand become proper landing pages, with clean static paths, their own titles and copy, a self-referencing canonical, and a spot in the sitemap and the internal links. A small middle tier stays crawlable but unindexed, where a filter has to be clickable for people but adds nothing for search. Everything else, which is most of it, stays out of the crawl entirely, blocked by robots.txt patterns and built through JavaScript state or POST requests so no new crawlable URL ever gets made.

Holding the whole thing together comes down to controlling how URLs get generated, sorting parameters into a fixed order, dropping empty and default ones, capping how many filters combine, and returning a proper status for a zero-result combination instead of a thin 200. The one trade-off to be upfront about is that blocking facets in robots.txt saves crawl but also stops Google seeing the canonicals on those URLs, so if some have already picked up links or index presence, you let them stay crawlable with canonicals until they consolidate, then block. Since Google dropped the URL Parameters tool in 2022, all of this lives on the site now, checked through the logs and the Pages report.

Further reading

19. What are the biggest technical SEO mistakes you see?

The worst ones are also the most ordinary, which is what makes the question work, because the list someone reels off tells you what they've actually had to clean up. Top of mine is a staging Disallow: / or a site-wide noindex going out with a release, still the most common disaster in the business, then migrations shipped without a real redirect map that send everything to the homepage, a robots.txt throwing a 5xx that Google eventually reads as a full block, and an expired certificate or a WAF rule that starts turning Googlebot away.

Below the outright disasters are the slow leaks. Client-side rendering with no fallback so the raw HTML is nearly empty, internal links built as onclick handlers or divs so there's no link graph to follow, a site-wide canonical aimed at the homepage from a misconfigured plugin, index bloat from facets and internal search and parameters, sitemaps stuffed with redirects and noindexed URLs, soft 404s on out-of-stock pages, redirect chains four and five hops deep, and hreflang with no return tags. The answer I like best lands on process rather than tags, that the real failure is usually the absence of a pre-launch check and any monitoring on indexed count, 5xx rate and robots.txt changes, because a team that can't see these things will keep shipping them.

Further reading

20. What is your process for a complete technical SEO audit?

I'm not after a memorised list of phases here, I'm after someone who audits toward a business goal and finishes with work that ships. The good answers start before any crawling, by pinning down what the audit is even for, since an audit for a traffic recovery looks nothing like one for a migration, and by getting the access that makes the rest possible, Search Console across every property variant, analytics, server or CDN logs, the CMS, and a clear picture of who can actually push changes.

The middle is the part most people can describe, and it moves from a baseline of current performance into a crawl run as Googlebot smartphone, ideally twice, once with rendering and once without, so the gap between them shows you the JavaScript risk. From there it's crawlability and indexability, rendering, site structure and internal links, performance from field data, content and duplication, structured data, and logs. What lifts a walkthrough above a recital is the sequencing and the enrichment, wiring the Search Console and PageSpeed APIs into the crawl, crawling the sitemaps as a list to catch URLs that 404 or redirect, and running one pass that obeys robots.txt and one that ignores it to see what's hidden behind it.

The end is where audits live or die, and it's the part I push on hardest. A good auditor scores every finding by impact, effort and confidence, ties each one to a template that actually makes money rather than to some abstract idea of site health, and hands over tickets instead of a document, one issue each, with the URL pattern, the fix, the acceptance criteria and how it'll be tested. Then they check the work after it ships with a re-crawl, and set up monitoring so the same problems get caught next time. The line I like to end on is simple, the point of an audit is the change that ships out of it, and an auditor who hands over a flawless hundred-page report that nobody acts on has produced nothing.

Further reading

Using this list

If you're prepping for an interview, the pattern is the same across all twenty. Give the clean answer, then show the judgment under it, the case where the rule stops holding, the cheap fix you'd try first, and what you'd check before touching anything. Recall gets you through the door, and the reasoning is what actually gets you the job.

And if you're the one hiring, the best signal usually isn't the most complete answer. It's the person who says "it depends," and can then tell you exactly what it depends on, who reaches for the logs and Search Console instead of an opinion, and who'll happily tell you when a technique is the wrong one to use. That's the person who saves you from the migration that goes sideways and the release that ships a noindex, and those are the ones that actually cost money.

This is the bar we hold our own technical SEO work to. If you'd rather hand the audits, the migrations and the monitoring to a team that already works this way than build one from scratch, see how we approach SEO or start a conversation.

// want_this_for_your_brand

See where your brand stands in AI answers today, benchmarked against your competitors, no pitch required.

[ request_an_audit → ]
// related_reading
Freshness only helps if the AI crawlers can actually see it
SEOAug 3, 2026

Freshness only helps if the AI crawlers can actually see it

Everyone's updating pages for AI citations. Almost nobody checks whether their servers ever tell the crawlers a page changed. Here's how to find the leak.

read_post →
Your content can sit inside two billion AI answers a month and still send zero visitors
SEOJul 26, 2026

Your content can sit inside two billion AI answers a month and still send zero visitors

Your content can be quoted inside two billion AI answers a month and still send zero visitors. That is not a traffic problem, it is a measurement problem, and the old dashboard cannot see it.

read_post →
How to build video that AI search actually cites
SEOJul 21, 2026

How to build video that AI search actually cites

YouTube is the most-cited source in Google's AI Overviews, and short-form is where product discovery now begins. What it takes to make your videos the ones AI search pulls from.

read_post →