Most website launch problems are invisible on the day and expensive a week later. The site loads, the homepage looks right, everyone celebrates, and the issues that cost you traffic are sitting in places nobody thought to look.

This is the checklist we run before we let a site go live, written from launches that taught us each item the hard way. Part two covers what happens to your search rankings afterwards.

Does every internal link still point somewhere real?

If you built on a staging domain or in a subfolder, every internal link and image URL may carry that old path. Move the site and they all break at once.

The fix is a database search-and-replace of the old URL for the new one, but never a raw SQL find-and-replace. Page builders store their layout as serialised data with character-length counts baked in; a blind SQL replace corrupts those counts and blanks pages silently. Use WP-CLI’s search-replace or a plugin that understands serialised data.

Then actually crawl the live site and check every page resolves. We have seen a launch where the search-replace ran clean and reported hundreds of changes, yet a dozen links still broke, because the page builder had stored those URLs in an encoded form the replace could not see. The report said success. The links said otherwise.

Are any images or scripts still loading over http?

A search-replace that changes your domain often leaves the scheme untouched, so http:// survives even after everything moves to https://. The result is mixed-content warnings: a padlock that is no longer solid, and in some browsers blocked resources.

Worse, the images most likely to keep an http link are the ones inside cached, pre-rendered widgets: headers, mega menus, anything a plugin renders once and stores. The database looks clean; the served page is not. Check the actual page source, not just the database.

Will your URLs collide with existing files?

This one is subtle and it bites hard. In WordPress, uploaded media shares the same address space as your pages. Upload an icon called contact-us.svg and it can claim the /contact-us/ slug, so your real contact page imports as contact-us-2, and the clean URL quietly serves the image file instead.

It does not look like a broken link. The page exists, the menu points at the right address, and the address serves an SVG. The fix is to never name an upload after a page slug, prefix every asset, and check your key URLs resolve to pages, not files, before launch.

Are redirects in place for anything that moved?

If any URL changed, whether a new structure, dropped pages or a removed folder, every old address needs a 301 redirect to its new home. Miss this and you throw away the ranking those pages earned, and hand visitors a 404 the moment they click an old link or search result.

List every URL the old site had, map each to its replacement, and put the redirects live with the launch, not after someone complains. This is the single biggest avoidable SEO loss in a migration, and we go deeper on it in part two.

Is the boring configuration done?

The unglamorous settings that get forgotten in the excitement:

Search engine visibility is ON. WordPress has a checkbox that blocks indexing, used during the build. Launch with it still ticked and you are invisible to Google for as long as it takes someone to notice. Check it first.

The static front page is set, and if your blog lives at a custom URL, the posts page points at it. On a fresh install these reset.

Forms actually send. Submit every contact form and confirm the email arrives. A launch where enquiries silently vanish is worse than no launch.

Permalinks flushed. Save the permalink settings once after launch, or some URLs 404 until you do.

Does it hold up on a phone?

More than half your visitors are on mobile, and mobile is where launch bugs hide. Check the header does not eat the screen, the menu opens and closes, forms are usable one-handed, and that you can actually scroll to the very bottom of the footer, the detail people miss. A sticky element set wrong can trap the page short of the end, and it looks fine on desktop.

None of this is glamorous. All of it is cheaper to check before launch than to explain after. If you would rather have someone who has made every one of these mistakes handle it, that is what our website development and website management work exists for.

Part two: what happens to your search rankings after launch, and how to make sure a new site is a step up rather than a step back.

Frequently asked questions

Planning a launch or a migration? Book a free strategy session and we will make sure it is a step up, not a step back.