What Went Wrong on Launch Day

The faults repeat

Different businesses, different builders, different platforms, and largely the same short list of problems.

That consistency is useful. It means launch day does not require diagnostic brilliance, it requires a checklist and somebody with an hour to work through it.

It also means the faults are predictable enough to be checked for deliberately rather than waited for.

Have somebody else do the checking

Ideally not the person who built the site.

Not from any distrust, but because they have looked at every page a hundred times and their eyes pass over things. They also know how the site is meant to work, which means they unconsciously use it correctly.

Somebody less familiar, following a written list, on their own device, finds more.

One: indexability

The first check, because it is the most expensive to miss and the least visible.

View the homepage source and search it for a robots instruction. If it says the page should not be indexed, that setting has come across from the build environment.

Check the robots file at the root of the site for a rule blocking everything, which is the other version of the same mistake.

Nothing about the site will look wrong if this is set. The symptom arrives weeks later as traffic quietly disappearing, and by then the damage takes months to undo.

Two: redirects

Take a dozen old addresses from the top of the traffic list and request each one by hand.

You are checking three things: that it goes somewhere, that it goes to the right thing rather than the homepage, and that it does so in a single hop.

Then run the full mapped list mechanically, because twelve by hand confirms the rules exist and only the whole list confirms the rules are correct.

Three: forms

Submit every one of them for real, from a phone on mobile data, using an address you can check.

Forms break in migrations more reliably than anything else, because they depend on a destination address, a mail configuration, and a delivery path, and a rebuild frequently changes all three at once.

Confirm the message arrives, that it lands in an inbox rather than junk, that every field came through, and that replying reaches the sender.

A form that submits successfully and delivers nowhere is the most expensive fault on this list, because it looks like a quiet week.

Four: analytics

Open the site and confirm your analytics is registering the visit.

Tracking codes are lost in rebuilds constantly, since they live in the template and the template was replaced.

This is not urgent in the sense that customers are affected, and it is urgent in a different way: the two weeks after launch are precisely when you need to see what is happening, and data not collected cannot be recovered later.

Five: the mobile view

On an actual phone, on mobile data, not on a desktop browser made narrow and not on office wifi.

Check the homepage, one service page, the contact page, and the navigation menu.

Confirm the phone number is tappable, the menu opens and closes, nothing overflows sideways, and the page becomes usable quickly on a normal connection.

Most visitors will arrive this way, and the desktop version is the one everybody tested during the build.

Six: the certificate

Confirm the padlock appears, on the new address, without warnings.

Then check the variants: with and without the www prefix, and the plain unsecured version of the address, each of which should land on the correct secured page rather than an error or a warning.

A certificate that covers one form of the address and not another is common after a move, and a browser warning stops a visitor completely in a way that no design flaw does.

A worked example

A regional firm launched on a Tuesday morning and ran an hour of checks with an office manager rather than the developer.

She found four things.

The plain address without the prefix produced a certificate warning.

The careers page form delivered to an address that had been closed a year earlier, which had been broken on the old site too and was only discovered because the list said test every form.

Analytics was missing from every page except the homepage.

And the phone number in the header was not tappable on a phone, having been placed inside an image.

All four were fixed by the end of the day. None would have been found by looking at the site, and three had nothing to do with the rebuild itself.

What not to do on launch day

Do not start making design changes because somebody in the office has opinions.

The first day produces a flood of taste-based feedback, all of it sincere and most of it unhelpful, and acting on it while genuine faults are still being found is how the important things get lost.

Write it down, thank the person, and look at it next week.

Do not delete the old site, do not cancel the old hosting, and do not remove the old sitemap. All three are cheap to keep for a month and expensive to have discarded.

The counter-case

There is a version of launch-day diligence that becomes its own problem.

A team that spends the day refreshing rankings, comparing traffic hour by hour against the previous week, and reacting to every fluctuation will make changes based on noise.

Nothing meaningful about search performance is visible on day one, or day three. The numbers move for reasons that have nothing to do with you, and a migration adds volatility on top of that.

Check the six things, fix what is broken, then deliberately stop looking until there is enough data to mean something.

The first hour

1. Check indexability, in the page source and the robots file.
2. Test a dozen redirects by hand, then the whole map.
3. Submit every form from a phone and confirm arrival.
4. Confirm analytics is recording.
5. Check the mobile view on real hardware.
6. Check the certificate on every address variant.
7. Write down anything else and look at it next week.

An hour, by somebody who did not build it, and it catches nearly everything that matters.

The form problem is the one worth understanding in depth, covered in forms that stopped working silently.

Frequently asked questions

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.