Nine steps to build a technical SEO strategy: outcomes, sampled crawls, scoring and review points

What to take away

A technical SEO strategy is a set of choices about which crawling, rendering and indexing problems you will solve, in what order, and who owns each one.
Start from commercial outcomes, not from crawl severity scores.
Plan in quarters and build review points into the plan, because search platforms change faster than annual cycles.
Budget for governance as well as fixesan owner, a definition of done and proof that the fix worked.
Settle consent and lawful basis before implementation, because they decide what you can measure.

Build the strategy before the fix list

Treating a crawl export as a strategy is the most common mistake. A tool returns thousands of issues ranked by its own severity score. That tells you what is broken, not what matters or what your team can ship this quarter.

A strategy answers different questions. Which URLs earn the revenue? Which templates control those URLs? What is technically blocking them? Who can change that, and by when?

Start from commercial outcomes

Write down the two or three commercial outcomes the next four quarters depend on. Every technical item must connect to one of them.

If you lack numbers, use a labelled illustrative example. An illustrative retailer with 40,000 product URLs where 8% carry duplicate canonicals has 3,200 affected URLs.

Separate platform risk from site risk

Platform risk is anything outside your control, such as how crawlers render JavaScript or how results are displayed. Site risk is internal: template logic, server behaviour, content governance and release process. Map both in your risk scenarios.

You cannot plan platform risk away, but you can reduce exposure. Keep critical content in HTML rather than behind interaction. Treat this as insurance, and review the 2027 trends each quarter instead of betting on one search feature.

Choose tools you can test

Every mainstream crawler finds broken links and missing titles. The differences that matter are rendering, log-file handling and export into your tracker. Screaming Frog's free version crawls up to 500 URLs, and a licence removes that limit.

Shortlist two of the technical SEO tools, then run both against the same template set. Compare what each returns. The overlap is your baseline, and the unique findings show which tool suits your architecture. Record the test date and the URL sample so you can repeat it next year.

Run the nine-step planning workflow

Steps one to five: evidence and diagnosis

Define the commercial outcomes for the next four quarters, with a named owner for each. Keep the list to three or fewer.
Map revenue or lead value to URL templates, using analytics segments and, where available, server logs.
Crawl those templates specifically, not the whole domain. Sample enough URLs per template to be confident, and record the crawl date.
Reconcile crawl findings with log files and index coverage data. Where they disagree, investigate before you plan.
Write a one-page diagnosiswhat is broken, which outcome it affects and how confident you are in the evidence.

Step three is where plans quietly fail. A whole-domain crawl produces a report nobody reads. A sampled crawl across your highest-value templates produces a plan you can defend in a budget meeting.

Steps six to nine: sequencing, delivery and proof

Score each finding on commercial impact, effort and confidence. Impact and confidence come from your data. Effort comes from the engineers who will do the work.
Sequence the work into a quarter-by-quarter roadmap and leave capacity unallocated for unplanned platform changes.
Agree a definition of done for every itemwhat changes, who verifies it and which measure shows it worked. A canonical fix is done when each URL has one self-referencing canonical and returns a successful status, not when the ticket closes.
Set review points every six to eight weeks. Recheck the diagnosis against fresh crawl and log data, then reorder the roadmap if the evidence has changed.

Report in commercial language, not a count of closed tickets. Borrow the acceptance criteria idea from agile delivery. The GOV.UK user stories guidance says acceptance criteria are a list of outcomes used as a checklist to confirm the work has done its job.

Worked example: the illustrative 40,000-URL retailer

The same nine steps applied to one labelled example.

Step	What the retailer does	Output
1	Names three outcomes: non-brand growth in one category, less paid dependency, a spring launch	Three-outcome brief
2	Maps revenue to templates: product pages carry most non-brand revenue	Template revenue map
3	Crawls 5,000 product and category URLs, not all 40,000	Dated sample crawl
4	Reconciles with logs and index data: 3,200 product URLs (8%) show duplicate canonicals	Disagreement list
5	Links the canonical fault to the category outcome	One-page diagnosis
6	Scores the fix high on impact and confidence, medium on effort	Scored list
7	Schedules the fix for Q1 and leaves Q2 capacity open	Quarter roadmap
8	Defines done: one canonical per product URL, verified in the crawl	Done definition
9	Reviews every six weeks and reports revenue covered by fixed templates	Review log

A quarter-by-quarter sequence is easier to agree than one large plan. The ninety day plan shows how to phase diagnosis, remediation and verification across a first quarter without overcommitting the team.

Govern the plan so it stays alive

Name an owner for each workstream, record decisions in one place and treat every release as a chance to introduce regressions. A quality checklist covering robots directives, canonical logic, status codes and rendering is cheap to maintain and catches most self-inflicted damage.

Write down what you will not do this year, and give each exclusion a review date. Keep the exclusions in the same document as the roadmap.

When the roadmap is agreed, move it into a working format. A planning template with owner, acceptance test, target quarter and evidence to date makes the plan auditable later.

Treat consent and data as technical requirements

Analytics, personalisation and marketing tags all touch the crawl and render path. Consent logic that blocks scripts can also block content, and measurement gaps make it harder to prove that technical work delivered.

You must have a valid data protection reason, a lawful basis, to use people's information for direct marketing activity, as the ICO direct marketing guidance states. Treat consent configuration as a planning dependency. If it is unresolved, your measurement plan is unresolved too.

Where teams go wrong under pressure

When a quarter goes badly, teams chase a platform update or buy another crawler. Each fixes a symptom. Return to the outcomes, recheck the evidence and cut the roadmap to what the team can verify this quarter.

Before you act

Write down three or fewer commercial outcomes, each with an owner.
Map revenue to templates before you crawl.
Sample URLs per template and record the crawl date.
Score findings on impact, effort and confidence.
Define done and the verifying measure for every item.
Settle consent and lawful basis before measuring.

Common questions

How long should a technical SEO strategy cover?

Plan in quarters with an annual frame, and review every six to eight weeks.

How many issues should the first roadmap contain?

Keep it to what the team can ship and verify in the quarter. A long list makes delivery slip and measurement impossible.

Do small sites need a formal technical SEO strategy?

Yes, but the document can be one page. The value is in the choices: what you will fix, who owns it and how you will know it worked.

How do you prove technical work delivered results?

Agree the measurement before the work starts, at template level rather than site level. Compare the affected template with a comparable unaffected one over the same period.