Interview plan template

Use Template
to edit & run interviews

SEO Engineer (Technical SEO & Search Infrastructure) interview questionsMigration Round — What the Redirect Map Missed round

A 60 min interview plan with a time-boxed script, what each question is for, and the signals to score against. Key skills: Sourcing a redirect map from records that contain the URLs a crawl cannot find, recognising a validation that was run against its own input, cutover mechanics that cannot be rehearsed in staging, and a monitoring and rollback decision made before the traffic is ambiguous.

Click "Use template" to edit

The brief and the map

10 min
•

I'm [YOUR_NAME] and I own the platform at [COMPANY_NAME], including the migration we're about to talk about. Three things about the format. This is a working session, so you'll have a terminal and I'd much rather watch you check something than hear what you would check. The migration in front of you was scoped before you arrived and parts of it are wrong — I know which parts and I am not going to tell you, and finding them is most of what this hour is. And by the end I want two artifacts I could actually use: the sources you'd build the map from, specific enough that I could go and pull them, and a monitoring plan with a rollback decision in it that has a number and an hour attached. If you tell me something I've done is wrong, that is the round working. I built some of this.

•

Here's the migration. About 12,000 URLs, moving between content systems, and the URL structure changes — every path is different afterwards. The team has a redirect map with 11,400 rules in it, generated from a full crawl of the old site. Cutover is in three weeks. You've got ten minutes: tell me what you want to know about that map, and what you'd go and look at first.

What this question is for, and what to listen for

Purpose

The fastest discriminator in the round and it resolves on one question — where the map came from. A crawl finds pages that are linked from other pages it can reach. It does not find orphans, and orphans are disproportionately the URLs that carry external links, which is the equity a migration is supposed to preserve. A candidate who accepts the crawl as the inventory has told me they have never audited a migration after the fact.

Signals to score

  • Asks where the 11,400 came from before asking anything about their contents
  • Names the limitation of a crawl directly: it finds what is linked, so orphans are absent by construction
  • Names other sources unprompted — server access logs, Search Console, a backlink index, analytics, the CMS or database, old sitemaps
  • Says which of those contain URLs a crawl cannot find, and is specific that logs and Search Console are the ones that do
  • Asks how many URLs Search Console knows about, and treats a gap against 11,400 as the finding rather than as a rounding difference
  • Asks whether this is the first migration or whether earlier redirects are already in place
  • Asks what is being deliberately removed, and separates removal from oversight
  • Asks about non-HTML assets: PDFs, images with links, feeds, anything served outside the content system
  • Asks whether any URLs are generated by campaigns or third parties and never linked internally
  • Proposes reconciling the sources into one union list before touching the map's contents

Follow-up questions

  • The crawl was complete — it ran to exhaustion and found everything reachable. Isn't that the site?
  • Which single source would you add if you could only have one?
  • How far back would you go in the logs, and why that far?
  • Suppose Search Console reports 14,200 URLs. What does that number mean?
  • Some of those old URLs get no traffic at all. Do they matter?

What the map missed

18 min
•

Now the same migration, six weeks after cutover. Organic sessions down 31%. Here's what we have. The validation job ran before cutover and passed: for every URL in the redirect map, request it, assert it returns a 301, follow it, assert the destination returns 200. Zero failures across all 11,400. Since cutover the access logs show requests to about 2,900 distinct paths that are not in the map, almost all returning 404, and roughly two hundred of those have external links pointing at them. Search Console knows about 14,200 URLs. Tell me what happened. And then tell me why the validation passed.

What this question is for, and what to listen for

Purpose

Two questions, and the second is the one worth the time. Anyone can reconstruct the missing-URLs story from the numbers on the table. The second question asks why the control was worthless, and a candidate who reaches "the test set and the input were the same artifact" has identified a defect class that will show up in everything they build for us afterwards.

Signals to score

  • Reconstructs the mechanism: the map was built from the crawl, the crawl missed orphans, the orphans now 404
  • States plainly that the validation iterated over the map, so a URL absent from the map was never tested
  • Names the general form: the test set and the input were the same artifact, so the check could not fail on the failure mode
  • Says what the validation should have iterated over instead — the union list, or specifically the log and Search Console URLs
  • Separates the two harms: lost traffic to those URLs directly, and lost link equity that was propping up other pages
  • Treats the two hundred externally-linked URLs as the urgent subset, distinct from the 2,900
  • Asks whether the 31% is concentrated in the migrated section or sitewide, and treats a sitewide drop as evidence of something additional
  • Notes that six weeks is long enough for status-code damage to show and not long enough for full recovery, and does not conflate the two
  • Asks what else changed at cutover besides URLs, rather than assuming the map explains all 31%
  • Proposes the fix in priority order: externally-linked first, then by log request volume

The cutover

20 min
•

Three weeks out, and I want the cutover itself. Two parts. First: name the things that will be true in production and cannot be tested in staging, and tell me what you'd do about each. Second: it's live. Walk me through the first hour — what you look at, in what order, and what you're looking for.

What this question is for, and what to listen for

Purpose

Staging is a different machine with a different edge, different access controls and a different robots posture, and a candidate who believes a green staging environment predicts a clean cutover has not been through one. The first-hour sequence is where experience is least fakeable: the order tells you whether they have actually stood in the middle of one of these.

Signals to score

  • Names the staging robots posture as the classic disaster: a noindex header or a blanket robots.txt disallow shipping to production
  • Says how they would prevent it specifically — an assertion on the production response, not a reminder to the team
  • Names the CDN and edge configuration as untested, including cache rules, redirects implemented at the edge, and stale cached objects
  • Names anything user-agent-conditional, which cannot be exercised by a logged-in human clicking through staging
  • Names TLS, DNS and canonical host behaviour — www against apex, trailing slash, protocol
  • Names staging authentication masking real status codes, so a 401 or 403 hides what production would return
  • Checks robots.txt and the noindex posture first in the live hour, before anything else
  • Checks status codes on a prepared cohort rather than browsing the site
  • Watches the access log live for 404s and 5xx, and treats that as the fastest available signal
  • Explicitly does not look at traffic or rankings in the first hour, and says why
•

Now give me the artifact. Specify the monitoring: which URLs, under which agents, how often, for how long, what threshold fires, to whom, and the first line of the runbook. Then the decision I actually need from you — what is the condition under which we roll back, and when does rolling back stop being available?

What this question is for, and what to listen for

Purpose

The only point in the round where the candidate produces something mergeable rather than describing something desirable. The rollback half is the senior discriminator: rollback on a migration has an expiry, most people have not thought about when it lands, and a plan that assumes rollback remains available is a plan with a hole in the middle of it.

Signals to score

  • Specifies the URL cohort by construction — top by traffic, top by external links, known orphans, a random sample, a known-good control
  • Fetches under both a browser and a non-rendering crawler agent, and gives the reason rather than the ritual
  • Gives an interval that tightens for the first period and relaxes afterwards, with both numbers stated
  • Fires on consecutive failures rather than on one, and names the threshold
  • Names a recipient and one concrete first action, not a channel and a hope
  • Watches the aggregate 404 rate from the access log as a separate signal from the cohort checks
  • Separates immediate signals from lagging ones and says which are allowed to trigger a decision in week one
  • States that rollback stops being clean once caches, DNS and Google's processing have moved, and puts an hour or a day on it
  • Gives a rollback condition that is a status-code or availability condition, not a traffic condition
  • Says what happens instead of rollback once the window has closed, and does not treat forward-fix as a failure

What you would not migrate

12 min
•

Two to finish. First: 12,000 URLs is a decision, not a fact. Name what you would not carry across, tell me how you decide, and tell me how you defend deleting something to the person who wrote it. Second, and take real time here: what would you need from me in the three weeks before cutover for any of this to happen?

What this question is for, and what to listen for

Purpose

"Redirect everything" is the absence of a position and the first half catches it. The 410 question also has a real technical answer that separates people who have read the documentation from people who have absorbed the folklore. The second half decides offers at this band more often than the technical sections do.

Signals to score

  • Proposes not carrying everything, and gives a decision rule rather than a feeling
  • Uses external links, log request volume and business value as the axes, and applies them in that order
  • Knows that a 410 is a legitimate outcome and says when it beats a redirect
  • Says what Google does with a mass redirect to the homepage, and names it as a soft 404
  • Redirects to the closest genuine equivalent, and treats "no equivalent exists" as a reason to 410 rather than to reach for the homepage
  • Raises redirect chains, and asks whether an earlier migration's rules are still in place
  • Says chains should be flattened so every historical URL points at the final destination in one hop
  • Asks who owns the content decisions and whether they get a veto
  • Names one specific access they want in the three weeks — the log store, Search Console, the CDN configuration, the repository
  • Asks what happens if their pre-cutover checks say do not ship
•

That's what I had. What I write up is the source list you gave me for the map and your rollback condition, and I'll do something with the first one — I still have the union list from our migration, so I'll check your sources against what we actually found missing and tell you what your version would have caught. You'll hear that either way, including if it would have missed the same things ours did. Two things before you decide about us. The 31% is real, it took about five months to recover, and the union list exists now because of it — so the map problem is solved here and the next migration is the one you would own. And the rendering round you may already have had in this loop is the same codebase and the same team, which means the assertions you dictate in either round are ones you would be maintaining yourself. [RECRUITER_NAME] will come back to you within [NUMBER] working days.

Use Template
to edit & run interviews
Interview Template
Position
SEO Engineer (Technical SEO & Search Infrastructure)
Round
Migration Round — What the Redirect Map Missed for 60 min
Key skills
Sourcing a redirect map from records that contain the URLs a crawl cannot find, recognising a validation that was run against its own input, cutover mechanics that cannot be rehearsed in staging, and a monitoring and rollback decision made before the traffic is ambiguous

SEO Engineer (Technical SEO & Search Infrastructure) interviews — common questions

Who is this SEO Engineer (Technical SEO & Search Infrastructure) interview plan for?
It is written for the interviewer, not the candidate: the hiring manager, engineer or panel member running the Migration Round — What the Redirect Map Missed round for a SEO Engineer (Technical SEO & Search Infrastructure) role. It gives you a 60 min script to follow in the conversation — 5 questions with what each one is for and the signals to score against — so you are not writing the round from scratch the night before.
What does the Migration Round — What the Redirect Map Missed round assess?
This round is focused on: Sourcing a redirect map from records that contain the URLs a crawl cannot find, recognising a validation that was run against its own input, cutover mechanics that cannot be rehearsed in staging, and a monitoring and rollback decision made before the traffic is ambiguous. It works through The brief and the map, What the map missed, The cutover and What you would not migrate, scoring against 50 observable signals, with follow-up prompts on 1 of the 5 questions for going deeper where an answer is thin.
How is the 60 min split up?
The brief and the map (10 min), What the map missed (18 min), The cutover (20 min), What you would not migrate (12 min). The timings are there so the round stays on schedule and every candidate gets the same shape of interview — which is what makes two candidates comparable afterwards.
What other rounds should I run for a SEO Engineer (Technical SEO & Search Infrastructure)?

A single round does not cover a whole role. The other round in this library for a SEO Engineer (Technical SEO & Search Infrastructure):