The two checks that matter most before a website goes live are the two most often skipped: that every old URL redirects to its new equivalent, and that the site is not still telling search engines to stay away. Everything else on this website launch checklist is recoverable in an afternoon. Those two can cost a business rankings it spent years earning.
Key takeaways
- Map every old URL to a new one before launch, and redirect permanently. Missing redirects are the number one cause of traffic loss after a redesign.
- Remove the staging block. A site that launched with search engines blocked can sit invisible for weeks before anyone notices.
- Test every form to a real inbox, not a test inbox, and confirm the notification arrives.
- Confirm analytics and Search Console are live on day one, because you cannot backfill the data later.
- Check it on a real phone, not a resized browser window.
What has to be done before launch day?
These are the items where fixing it after go-live is meaningfully worse than fixing it before.
| Check | Why it is urgent | Cost if missed |
|---|---|---|
| Redirect map, old URL to new | Search engines and existing links point at the old URLs | Lost rankings, broken links across the web |
| Search engine blocking removed | Staging sites are blocked by default | Site invisible in search for weeks |
| Forms deliver to a monitored inbox | The site looks fine and swallows leads | Enquiries lost with no trace |
| Analytics installed | Data cannot be backfilled | No baseline to compare against |
| SSL certificate valid | Browsers warn on insecure pages | Visitors bounce at the warning |
| Phone numbers and address correct | Copy-paste errors survive proofreading | Calls to the wrong number |
Work down that list before anything cosmetic. A typo in the hero heading is a five-minute fix next week. A missing redirect is a ranking you may not get back.
How do I build a redirect map?
Export a list of every URL on the current site, decide the closest equivalent on the new site, and set a permanent redirect for each one.
The process in practice:
- Get the full URL list. Your existing sitemap is the starting point, but it will be incomplete. Add every URL that has traffic in analytics and every URL in Search Console's coverage report.
- Match each one to its new equivalent. Closest match by intent, not by name. An old "/services/drain-cleaning-repair" goes to the new drain cleaning page, not to a generic services hub.
- Only send to the home page as a last resort. A redirect that dumps everything on the home page tells search engines the old content is gone, which is functionally the same as deleting it.
- Use permanent redirects, not temporary ones. A temporary redirect tells search engines the old URL is coming back.
- Test the list after launch, every entry, with a crawler or a script. Assume nothing.
Google's guidance on site moves with URL changes is the authoritative reference here, and it is worth ten minutes of reading before a redesign rather than after.
The pages most worth protecting are the ones already ranking. If a service page is bringing in enquiries today, its URL and its content both deserve care in the move.
What is the staging block, and why does it catch people?
Staging sites are usually configured to tell search engines not to index them, which is correct while the site is in development and catastrophic if it survives launch.
There are two separate mechanisms and both need checking, because fixing one and missing the other produces exactly the same invisible outcome:
- robots.txt may contain a blanket disallow rule
- A noindex directive may be set site-wide in the platform settings or in the page head
Check the live site after launch, not the staging site before. View the source of the home page and search for "noindex," then load /robots.txt directly in a browser. It takes two minutes and it is the single highest-value post-launch check there is.
Search Console's URL Inspection tool will tell you plainly whether a page is indexable, and it is worth running on the home page and two interior pages on launch day.
How do I test forms properly?
Submit each one as a customer would, from a phone, and confirm a real person receives it.
The failure modes worth catching:
- The form shows a success message but nothing sends
- The notification goes to an address nobody monitors, or one that was correct for the previous developer
- The notification lands in spam because the sending domain was never authenticated
- The reply-to address is the website's own address, so hitting reply emails the site instead of the customer
- The confirmation email never sends, so the customer has no record
That third one deserves emphasis. Transactional email from a new domain frequently lands in spam until the domain's sending records are configured, and the failure is silent. Test to an address on a different provider than your own, and check the spam folder.
While you are in there, confirm the form itself is not costing you completions. Our contact form best practices covers the field count and the follow-through.
What tracking needs to be live on day one?
Analytics and Search Console, both verified before you announce the site.
Analytics data cannot be backfilled. If you launch on the first and install the tag on the fifteenth, the first two weeks of your new site simply do not exist, which is exactly the period you will want to look back on.
Search Console needs the property verified and the new sitemap submitted. It is also where crawl errors surface, which is how you find the redirects you missed.
Two smaller items in the same category: confirm the tracking tag is firing on every page rather than just the home page, and confirm you are pointing at the right property if you have more than one. Sending data into a second, forgotten property is a common and genuinely confusing failure, because everything looks installed and no data appears.
What should I check on a real phone?
Most of your visitors are on one, and an emulator will not catch several of these.
- Tap targets are big enough to hit accurately
- The phone number is tappable and dials the right number
- No horizontal scrolling on any page
- Forms bring up the right keyboard, and autofill works
- Images are not loading at desktop size over a mobile connection
- Any sticky header or chat widget is not covering the content
That last check catches a surprising number of problems. A chat bubble that sits politely in the corner on a desktop can cover the submit button on a phone.
Performance is worth a real-device look too. If the site feels slow to load on a phone on mobile data, it is slow, whatever the score says, and the hero image is the usual reason. Our guide on improving Largest Contentful Paint covers the fix.
What about the Google Business Profile?
If your address, phone number, or website URL changed, update the profile the same day the site goes live.
Local search leans heavily on consistency between what your site says and what your profile says. A profile pointing at a URL that now redirects is not fatal, but it is a loose end, and the profile is usually a bigger driver of local enquiries than the website itself. Google's Business Profile Help covers what each field affects.
The same applies to any directory listing carrying your details. You do not need to chase all of them, but the major ones are worth an hour.
What should I check in the first week?
Set a reminder rather than trusting yourself to remember:
- Search Console coverage report. New errors here are usually missed redirects.
- Analytics traffic. A total drop means tracking is broken. A partial drop is normal for the first fortnight after a redesign.
- Form submissions. Confirm at least one real enquiry arrived and was answered.
- Broken internal links. Run a crawler across the site; redesigns always leave a few.
- The old site is genuinely gone, not still live on a subdomain competing with you.
That last one happens more than it should, usually because the old site is left running "just in case." Two live copies of the same business will compete with each other in search, and the wrong one often wins.
What does not need to be perfect at launch?
Launching is better than polishing. Things that can safely wait:
- The full guide library. Publishing steadily beats holding the site back.
- Every service page written to final depth. Get the top three right and expand.
- Photography, if you have workable interim images and a plan to replace them.
- Every city page, if you are covering multiple markets. Our guide on multi-location website structure covers how to phase that properly.
Holding a launch for content that could ship next month is how a redesign becomes an eighteen-month project.
What to do next
If a redesign is coming, build the redirect map first. It is the item most likely to be skipped and the one with the highest cost.
If you would rather hand the whole launch to someone who has done it before, that is what we do. Tell us what you are moving from and we will tell you what the risky parts are.
