The pre-launch website checklist a non-technical owner can run

Website launches go wrong for boring reasons: a contact form that sends to nobody, old URLs that dead-end, a staging setting that tells search engines to ignore the whole site. A pre-launch checklist is not paperwork, it is the difference between a quiet Monday and a week of firefighting. The list below is grouped and sequenced so a non-technical owner can run it with a browser, a phone and about two hours a day over the final two weeks.

Content, legal and the pages everyone forgets

Content is the slowest part of any launch because it depends on approvals, so clear it first. Walk the site page by page with a notepad and check the unglamorous things.

• Placeholder hunting. Use the site search and your browser find function for "lorem", "coming soon", "TBD", "test", "example.com" and any previous business name. Placeholders survive launches far more often than anyone expects.
• Titles and descriptions. Every page needs its own page title and description. Duplicates across ten pages tell search engines you have one page, not ten.
• The forgotten pages. A useful 404 page with links back into the site, privacy policy, terms of use, an accessibility statement, and a contact page that carries your real business name, address, phone number and hours.
• Consistency. Phone number, email and address should match exactly in the footer, the contact page and any listing you control. Mismatched details confuse customers and search engines equally.
• Images. Alt text on anything that carries meaning, and no photographs you do not have a licence to use.

If you serve customers in both official languages, check the French pages with the same care as the English ones. Half-translated navigation is a common and avoidable embarrassment.

Analytics and consent, wired before you launch

If tracking goes live a week after the site does, you have no baseline to compare against and no way to tell whether the new site is working. Set it up during the build and verify it on staging.

Create the analytics property, confirm the tag fires on every page including thank-you and confirmation pages, and define the three to five actions that actually matter to your business: form submission, phone tap, booking, quote request, file download. Vanity metrics can wait. Then verify the site in Google Search Console and Bing Webmaster Tools so you have somewhere to submit your sitemap on launch day.

Consent comes with it. Your banner should default to declining non-essential cookies, and your tags must genuinely respect that choice rather than firing regardless. Before launch, remove any staging or test property IDs so your real numbers are not split across two accounts. If you want a second pair of eyes on measurement design, that is the kind of work our analytics and CRO practice does alongside a build.

Test every form, notification and reply path

This is the most valuable hour on the list, and it needs no technical skill. Run these steps in order for each form on the site.

1. Fill out the form as a real customer would, on a phone, on mobile data rather than office Wi-Fi.
2. Confirm you see a clear on-screen confirmation, not a blank page or a silent reload.
3. Check the inbox that is supposed to receive it, then check the junk folder, then check it again an hour later in case of delay.
4. Read the automatic reply the customer receives. Check the sender name, the reply-to address and the wording.
5. Reply to that automatic email and confirm it reaches a monitored inbox rather than a no-reply void.
6. Confirm the enquiry also lands wherever you keep records: CRM, shared inbox or spreadsheet.
7. Submit deliberately bad data, such as a malformed email address, and confirm the error message is readable and the form keeps what was already typed.
8. Repeat once from a different device and browser, because notification failures are often device-specific.

While you are here, ask whoever manages your domain to confirm SPF, DKIM and DMARC records are set for the address your site sends from. Notification email that lands in spam looks identical to a broken form from the customer's side. Email authentication and form handling sit inside the same security and compliance conversation, and both are worth settling before launch rather than after.

Accessibility and performance spot-checks you can run yourself

You do not need an audit tool to catch the obvious problems. You need fifteen minutes and a willingness to stop using your mouse.

The keyboard and zoom pass

Press Tab repeatedly from the top of the homepage. You should always be able to see where you are, reach the navigation, open the menu, and get to the main content without a trap. Then zoom the browser to 200 per cent and confirm nothing overlaps or disappears. Check that form fields have visible labels rather than placeholder text alone, that link text says where it goes, and that any video has captions. These are the everyday failures behind WCAG 2.2 AA, which is the standard we build to by default.

The weak-signal pass

Load the homepage, your busiest service page and the contact page on a phone with a poor connection. Watch for hero images that take too long, text that jumps as fonts load, video that autoplays and eats data, and buttons that shift under your thumb.

If it does not work on a five-year-old phone on transit Wi-Fi, it does not work.

Note what you find, then get it fixed before launch rather than adding it to a list nobody returns to.

Launch day: redirects, DNS, SSL, backups and monitoring

Save every irreversible switch for one focused window, ideally a weekday morning when the people who can help are awake. Follow this order.

1. List every old URL. Export the old sitemap or crawl the existing site so you have the full inventory, not just the pages you remember.
2. Map old to new. Point each old URL at its closest new equivalent with a permanent redirect. Sending everything to the homepage is the lazy option and it loses rankings and confuses returning visitors.
3. Back up the old site. Take a complete copy of files and database, store it somewhere off the server, and keep it for at least a few months after launch. It is your only undo button.
4. Lower the DNS TTL further ahead of the switch than the current TTL value, so the old records have expired everywhere by the time you change them.
5. Confirm the certificate. Check that SSL covers both the www and non-www versions, that one redirects to the other, and that the padlock appears on every page.
6. Force HTTPS and look for mixed-content warnings, usually caused by an old image or script loading over plain HTTP.
7. Remove the staging guards. Delete the noindex tag, the password wall and any Disallow rules in robots.txt that were protecting the build. Miss this one and the new site can sit invisible to search engines for weeks before anyone notices.
8. Submit the sitemap in Search Console and request indexing for your homepage and top service pages.
9. Switch on monitoring. Uptime checks, certificate expiry alerts and automated daily backups, with one restore actually tested so you know the backup works.

Test the whole set from a device that has never seen the site: a phone on mobile data, in a private window. Your own computer may be holding a cached version and telling you a comfortable lie.

The week-one watchlist

A launch is a week of observation. Put fifteen minutes in your calendar each day and check the same short list.

Two things to ignore in week one: small ranking wobbles, which are normal while search engines recrawl, and design opinions from people who have not used the site on a phone. Fix what is broken first, then argue about the hero image.

How OlDevs helps

We have been launching sites from Vancouver since 2014, and we run this checklist on every build we ship. You get one accountable team rather than a relay of contractors, a working demo every week so nothing is a surprise at the end, and full ownership of your code, designs, accounts and IP when the project closes. Accessibility to WCAG 2.2 AA is built in rather than retrofitted, and we work in English and French when your audience needs both.

If you are launching soon and want the redirect map, tracking and launch-day sequence handled by people who have done it many times, tell us about the project. We reply to every enquiry within one business day. See how we approach web development, or request a quote and we will walk your current site with you.