Most technical SEO problems are cheap to fix before launch and expensive to fix afterwards. A redirect chain caught on a staging site takes ten minutes. The same chain found six months later has already cost you rankings, and untangling it means checking every internal link that points at it.
This is the checklist we run on every new build, in the order we run it. It is deliberately boring. Boring is what you want here.
Before anything else: can it be crawled?
- Check robots.txt. The single most common launch failure is a staging
Disallow: /shipped to production. Confirm it allows what you want crawled and points at your sitemap. - Check the noindex flag. In WordPress, Settings then Reading, make sure “Discourage search engines” is unticked. Then view source on a few templates and search for
noindex— plugins and themes add it in places the settings screen does not mention. - Submit an XML sitemap. It should contain only canonical, indexable URLs — no redirects, no 404s, no paginated duplicates. Register it in Search Console.
- Force one hostname and one protocol. Pick HTTPS with or without www, then redirect the other three variants to it in a single hop. Test all four by hand; a two-hop redirect is a surprisingly common default.
Then: is each page distinct and understood?
- Set canonical tags. Every page should declare itself canonical unless it genuinely duplicates another. Watch for filter and sort parameters generating near-identical pages, and check that the canonical points at the live domain rather than the staging one.
- Write unique titles and meta descriptions. Not templated to the point of being identical. Crawl the site and sort by title — duplicates surface immediately.
- Give every page exactly one H1 that describes that page, and keep the heading order sensible below it. Themes that render the site name as an H1 on every page are a common culprit, and so are page builders that hide a second one in a slider.
- Add structured data where it genuinely applies — organisation, breadcrumbs, article, product, local business. Validate it. Do not mark up things that are not on the page; that is the fastest route to a manual action on rich results.
Then: does it hold together?
- Crawl for broken links and redirect chains. Fix internal links to point at the final destination rather than relying on a redirect to catch them.
- Check the internal linking depth. Anything more than three clicks from the home page had better deserve to be that far down. Orphan pages get found here too, and on a new build there are always some.
- Compress and size images properly, serve modern formats, and set width and height attributes so the layout does not shift while they load.
- Test on a real mobile device, not just a narrow browser window. Tap targets, font sizes and anything that depends on hover are what break.
The three that catch people out most often
Of those twelve, three account for most of the launches we have had to rescue. They are worth calling out because all three are invisible if you only look at the site in a browser.
The staging robots.txt. It blocks everything, it was correct on staging, and nobody removed it. The site looks perfect and simply never appears. Check this first, and check it again the day after launch.
Canonicals still pointing at staging. Worse than the robots file, because the site gets crawled and then politely told that the real version lives on a domain nobody can reach. It is one line in the source of every page, and it is easy to miss when the pages themselves render correctly.
Hard-coded internal links. Links written with the full staging or http:// URL rather than relative paths. Every one of them is now a redirect at best. A crawl catches these in a couple of minutes; nothing else will.
What we deliberately leave until later
Chasing a perfect performance score before launch is usually a poor use of time. Get the site fast enough that it is not obviously slow, ship it, then optimise against real field data rather than a lab score — we went into which metrics still earn that attention in Core Web Vitals in 2026.
The same goes for exhaustive schema and for content pruning. Both are much easier to judge once you can see which pages people actually land on.
Week one in Search Console
Launching is not the finish line, and the first week is when a bad decision is still cheap to reverse. Three things are worth watching.
Check that the sitemap has been read and how many of its URLs were accepted. A gap between submitted and indexed is normal at first; a gap that does not close over a fortnight is a signal.
Read the Page Indexing report properly rather than glancing at the total. “Discovered — currently not indexed” usually means the page was found and judged not worth the crawl, which is a content problem wearing a technical costume. “Crawled — currently not indexed” is a similar message stated more bluntly.
Finally, use the URL Inspection tool on your three or four most commercially important pages and look at the rendered HTML, not the source. If your content arrives through JavaScript, this is where you find out whether it arrived at all.
Run it again after launch
Launch day changes things. Run the whole list once more a week after go-live, when the site is on its production hostname with production caching in place. That second pass catches more than the first one for most builds.
If you would rather someone else ran it, that audit is where every on-page SEO engagement of ours begins. Ask us for a free audit and we will send you the findings whether or not you work with us.