What a ninety day technical SEO plan covers, month by month

What to take away

The plan only makes sense once you know which problems are worth fixing. Most teams arrive with a list of symptoms rather than a ranked set of causes.

Ad hoc fixes still have a place for a broken robots.txt or a stray noindex. The ninety day format suits the larger set of issues that need ranking, scheduling and measurement.

What should the first thirty days produce?

The first thirty days are an evidence month. Pull crawl data with a crawler such as Screaming Frog SEO Spider or Sitebulb, work through server logs in Screaming Frog's Log File Analyser, and export index coverage from Google Search Console into one sheet. Then rank the problems by the revenue or traffic each one blocks.

Log analysis shows where Googlebot spends its time. If crawl demand is outrunning capacity, Google Search Central's guidance on reducing Google's crawl rate explains the settings available in Search Console.

You also need a scoring method, because two analysts will rank the same defect differently. A written rubric settles that, and our technical SEO planning template sets one out row by row: defect, the check that confirms it, owner, fix date and evidence source.

The block ends with a ranked defect list. Each entry carries a named owner and a date.

Set a cutoff for the list. If a defect cannot be scoped inside a week of engineering time, park it and record the reason.

How do days thirty one to sixty get fixes shipped?

Delivery fills the second block. Work in weekly batches so something ships every seven days, even when the batch is small.

Sequence matters. Close indexing and crawl blockers before cosmetic work, because a redesign on top of a broken canonical wastes the quarter.

Typical batches cover robots.txt directives, noindex and canonical tags, redirect chains, XML sitemap hygiene, structured data, hreflang and pagination, and JavaScript rendering. Each fix needs a confirmation check — a re-crawl, a URL Inspection in Search Console or a query against the log file.

Copy changes need a compliance pass. Run headings, descriptions and claims past the CAP Code rules the ASA enforces before publication, since a claim pulled after launch costs more than one edited before it.

Keep a change log. Record the date and page group for every deploy, plus the defect it closes. Month three then attributes movement from evidence rather than memory.

Batch size should suit the release process. A team shipping daily can group small configuration changes; a team on fortnightly releases should plan fewer, larger deploys.

By day sixty most of the list should be closed. The rest carries dates people agreed to in writing.

What does the before and after comparison look like?

The table is a format, not a forecast. Fill in your own baselines — crawl requests per day from the log file, indexed and excluded URLs from Search Console index coverage, Core Web Vitals field data — because a row without a starting measurement turns the comparison into opinion.

Add a column for the evidence source behind each row, so a reader can trace a number back to a crawl, a log file or a dashboard.

Why does the final month decide whether the plan survives?

The final month exists to measure and hand over. Re-run the same crawl, the same log-file window and the same index checks from week one, then compare like for like.

Report what moved and what stalled. Anything still open needs a reason on the record, not a quiet deletion from the sheet.

Handover is the step teams skip. Write down who watches crawl data after the quarter ends, how often they check it and what would trigger a new plan.

A quarter on its own will not hold a site together. Roll it into our technical SEO strategy and planning guide, which sets out how quarters sit inside a budget cycle.

A ninety day plan that ends without a named next owner is a project, not a process.

Common questions

How many people does a ninety day technical SEO plan need?

Usually two to four. An analyst, a developer and someone accountable for content is a common shape.

Can the plan run without developer time?

Not easily. Crawl, canonical and rendering fixes need engineering effort, so without it keep the plan to content and configuration work.

What if the evidence month finds nothing worth fixing?

Then shrink the plan. A short list closed properly beats a long list half finished, and it frees the next quarter.