In short
Launch the site to a private staging address first and work through the checks there: words, links, forms, phones, speed, titles and descriptions. On the day, connect the domain, publish to production and test the live address end to end. Then spend two weeks watching that forms arrive, pages get found and nothing has quietly broken.
Why launches go wrong
Most launch problems aren’t technical failures. They’re small things nobody checked: a contact form still sending to the developer’s test inbox, placeholder text on the About page, a “Book now” button linking to nowhere, a search setting that tells search engines to ignore the whole site. Each takes a minute to fix before launch and a lot longer to explain after.
A checklist turns launch from a nervous moment into a routine. Work through it on a staging copy, where mistakes are private, and keep the live address for the version that has passed.
Before launch: on a staging copy
Do all of this on a private preview link, not the live site. If you haven’t used staging before, our guide on staging vs production explains the idea, and why check a staging version before you publish covers why it’s worth the extra step.
Content
- Read every page out loud once. Typos hide from silent reading.
- Search the site for placeholder text: “lorem ipsum”, “TBC”, “your text here”, sample names.
- Check names, prices, addresses, opening hours and phone numbers against what the business actually uses.
- Make sure every image is the final one, the right way up, and not stretched.
- Add short descriptive alt text to images that carry meaning.
- Confirm the legal basics are there: privacy policy, cookie notice if needed, company details.
Links and buttons
- Click every item in the navigation, on every page template.
- Click every button and call to action.
- Tap phone numbers and email links on a phone to check they open the right app.
- Check social links go to the business’s own profiles.
- Run a broken link checker over the staging site.
Forms
- Submit every form with real-looking details.
- Confirm each message arrives at the right inbox, not a test address.
- Check the thank-you message or page appears.
- Try submitting with a field missing and see that the error makes sense.
Phones and other screens
- Go through the main pages on a real phone, not just a narrow browser window.
- Check text is readable without zooming and buttons are easy to tap.
- Look for anything that scrolls sideways.
- Open the site in at least two different browsers.
Our article on making a website mobile-friendly goes into more detail.
Speed
- Run the home page and one key page through a page speed test.
- Resize and compress large images; they’re the usual cause of slow pages.
- Remove scripts and embeds the site doesn’t need.
Search basics
- Give every page a unique, descriptive title and meta description.
- Use one main heading per page.
- Set a social sharing image and check how a link looks when pasted into a message.
- Add a favicon.
- Make sure the staging copy is hidden from search engines, and that the live version won’t be. This is the classic launch mistake: a “don’t index” setting copied from staging to the live site.
- Prepare a sitemap file.
Sign-off
- Send the staging link to whoever needs to approve the site.
- Get a clear yes in writing, even a one-line email.
- Agree a launch time when someone can watch the site for an hour or two afterwards. Avoid late Friday.
On launch day
If you’re replacing an old site
Launching over an existing site is closer to a migration than a fresh launch. Before you switch, list the old site’s addresses and set up redirects to the matching new pages, so links and search listings keep working. Our website redesign checklist and website migration checklist cover this in depth.
Connect and publish
- Take a copy of the final files before publishing.
- Connect the domain to the new site through your domain and hosting settings. Allow time for the change to spread; it can take from minutes to a few hours.
- Make sure both the plain domain and the “www” version work, and that one redirects to the other.
- Check the site loads over https with no security warnings.
- Publish to production.
Test the live site
- Repeat the quick version of the pre-launch checks on the live address: navigation, buttons, forms, phone layout.
- Submit every form again from the live site and confirm delivery.
- Check the live site isn’t set to hide from search engines.
- Submit the sitemap through the search engine tools you use, if you use them.
- Set up analytics, if the business wants it, and check it records a visit.
After launch: the first two weeks
The launch isn’t finished when the site goes live. Problems often show up over the following days.
- Day one: check forms are still arriving, and ask the business to tell you about anything odd customers mention.
- First week: search for the business name and check the listing; look in search tools for crawl errors and pages that can’t be found.
- First two weeks: fix any broken links that turn up, check redirects from the old site are working, and look at which pages people actually visit.
- End of week two: a short handover. Who can edit the site, who can publish, where the files live, and when the first maintenance check is due. Our website maintenance checklist is a good place to start that routine.
Who does what on launch day
Even on a small project, launch goes more smoothly when everyone knows their part. Agree it in a short message the day before:
- The person publishing connects the domain, publishes and runs the live checks.
- The person approving, usually the client or business owner, is available for an hour in case a decision is needed.
- Someone who knows the business checks the details that only they would spot: prices, names, opening hours.
- Everyone knows the plan if something goes wrong, which is usually to fix forward on staging and republish, or put the previous version back.
Write down who has access to the live site afterwards, and give each person only the access they need.
A one-page version
Before launch:
- Every page read; no placeholder text.
- Details checked: names, prices, hours, contact.
- Every link, button and form tested on staging.
- Checked on a real phone and two browsers.
- Large images compressed.
- Titles, descriptions, sharing image and favicon set.
- Staging hidden from search; live version won’t be.
- Written approval received.
Launch day:
- Final files copied.
- Domain connected; www and plain domain both work.
- https working.
- Published to production.
- Forms re-tested on the live site.
- Sitemap submitted; analytics checked.
After launch:
- Forms watched for a week.
- Search listing and crawl errors checked.
- Redirects from any old site confirmed.
- Handover done; maintenance scheduled.
How Devdwell helps with launch
Devdwell’s publish panel has staging and production side by side: tick Staging to get a private preview link for checks and approval, then tick Production when it has passed. The steps are in how to publish a website. After launch, the site sits on your dashboard with its address and when it was last published, so you can see at a glance that the version you approved is the one that’s live.
Questions
What should I check before launching a website?
Content and placeholder text, every link and button, every form end to end, the layout on a real phone, page speed, unique page titles and descriptions, and that the live site isn’t set to hide from search engines. Do these checks on a private staging copy first.
How long does it take for a new domain to start working?
After you point a domain at a new site, the change can take from a few minutes to several hours to reach everyone. Plan the launch for a time when you can wait and test, and avoid announcing the site until it loads correctly.
What is the most common website launch mistake?
Leaving a setting on the live site that tells search engines not to index it, often copied from the staging version. Others include forms sending to a test inbox and missing redirects from an old site.
What should I do after a website launches?
Watch for the first two weeks: confirm form messages keep arriving, check the search listing and crawl errors, fix broken links and redirects, then hand over and schedule regular maintenance.