Most post-launch problems are the same handful every time: forms that do not deliver, the staging site left blocked from search, redirects missing, and details that were placeholders. Half an hour of checking before going live prevents weeks of quiet losses.

The one that matters most

Whether the forms actually deliver.

This is the failure that costs real money and produces no error. The site looks fine, enquiries stop arriving, and nobody discovers it until somebody phones to ask why their message was ignored.

Test it properly: submit every form on the site, from a device that is not yours, and confirm the message arrives. Check the junk folder. Check the automatic acknowledgement went out. And check where submissions are stored if they are.

Then do it again after any change on launch day, since a last-minute adjustment is exactly what breaks it.

The one everybody forgets

Removing the block that stopped search engines indexing the staging site.

Staging copies are correctly blocked while in development. Launching without removing that block means the new site is invisible, and it can persist for weeks before anybody notices traffic never arrived.

Check the setting in the platform, check the file that controls crawler access, and check the page-level directive in the markup. Any of the three can carry it.

The reverse problem is worth checking too: that the staging copy itself is still blocked and password protected, so it does not compete with the live site.

Redirects, where a rebuild loses its history

If any address changed, every old one needs a permanent redirect to its closest new equivalent.

The list should be made before launch from the old site's pages rather than reconstructed afterwards. Search Console and the old sitemap are the sources.

Redirecting everything to the homepage is the common shortcut and it discards most of what the old pages had accumulated.

Test a sample by visiting old addresses and confirming where they land, including ones from search results and any that appear on printed material.

The content check

The technical check

Short, and each item is a real failure that happens.

The secure connection, working on every page, with the insecure version redirecting. Check for mixed content warnings, which occur when a page loads something over an insecure connection.

One version of the site, with and without the www prefix resolving to the same address rather than both being live.

The sitemap, present, correct, and submitted.

Analytics installed, firing, and recording conversions. A launch that loses tracking makes the comparison against the old site impossible.

The favicon, which is a small thing and visibly absent.

Every internal link, checked with a crawler rather than by clicking, since a rebuild produces broken links in places nobody looks.

On the devices that matter

Not a device matrix, three checks.

A real phone, on mobile data rather than office wifi, which is where most visitors are and where speed problems show. Check the menu opens, the number is tappable, and the forms work.

A desktop browser at a normal window size, and again zoomed to two hundred percent.

Keyboard only, tabbing through the homepage and a service page, confirming you can see where focus is and reach everything.

The things to have ready before launch, not after

Because these are harder to do once the site is live and busy.

A full backup of the old site, kept regardless of how the new one goes. The baseline figures from the old site, recorded. Access to everything, confirmed in your own name rather than the developer's. And the files, meaning you actually hold a copy of what was built.

That last one is the handover question, and the moment to ask is before the final payment rather than a year later.

The first week afterwards

Launch is not the end of the checking.

Watch for errors in the server log and in Search Console, which will surface addresses that are being requested and failing. Confirm pages are being indexed. Check the forms again. And ask two people who did not build it to use the site and report anything odd.

Most launch problems that survive the checklist surface in the first week, and they are cheap to fix then and expensive to discover in March.

Keeping a record of what changed and when is what makes any of that diagnosable, which is the habit described in keeping track of website changes.

Frequently asked questions

What is the most important pre-launch check?

Whether the forms actually deliver. Submit every one from a device that is not yours, confirm arrival including the junk folder, and repeat after any launch-day change.

What do people most often forget?

Removing the block that stopped search engines indexing the staging site. The new site is then invisible, sometimes for weeks before anybody notices.

What about redirects?

Every old address needs a permanent redirect to its closest new equivalent, listed before launch from the old site's pages. Redirecting everything to the homepage discards what those pages accumulated.

What technical items need checking?

The secure connection with mixed content resolved, one version of the site resolving, the sitemap submitted, analytics recording conversions, the favicon, and every internal link.

What device testing is needed?

A real phone on mobile data, a desktop browser at normal size and at two hundred percent zoom, and keyboard-only navigation through the homepage and a service page.

What should I have before launch rather than after?

A backup of the old site, the baseline figures recorded, access confirmed in your own name, and a copy of the files that were built.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Launching a new site this month?

We run the checks that catch the silent failures, particularly the forms and the staging block, before anyone notices they were broken.

Start a Conversation