1. Content and copy
Content problems are the easiest to miss and the most embarrassing to have live. The only way to catch them is to sit down and read the site before launch. No tool catches a wrong phone number, a placeholder that slipped through, or a service description that's still referencing a city you don't serve. That review needs to happen in a browser pointed at the staging or pre-launch environment, not in a code editor or a design mockup.
Start with the basics: your business name, phone number, address, and email address should be correct on every page they appear. If you have multiple locations or service areas, verify each one independently. A phone number that was right on the old site doesn't automatically carry over correctly, especially when content was copied from a template. Tap every phone number to confirm it actually dials the right number on a phone. This is not optional — a phone number that doesn't dial when tapped on a service page is a missed lead from the moment the site goes live.
Look for placeholder text: "Lorem ipsum" in a paragraph, "Your name here" in a testimonial, or a blank image with alt text that says "placeholder image". These slip through frequently, especially when content was added late in the build process. Also check for draft-stage pages or test pages that were never meant to go live. A leftover test or draft page that went undeleted can appear in Google search results where customers will find it.
Check all images for descriptive alt text. This matters for two reasons: accessibility (screen readers read the alt text to users who can't see the image) and SEO (Google uses alt text as a signal for image search indexing and as content context). Alt text should describe what's in the image concisely: not keyword-stuffed, not left blank where it matters, and not just saying "image of..." which is redundant. Purely decorative images can be marked so screen readers skip them.
Finally, confirm that legal pages are in place. If your site collects any data through contact forms, analytics, or cookies, you need a privacy policy. If you take payments, you need terms of service and a refund policy. These are not optional niceties — they're legal requirements in most jurisdictions, and platforms like Google and Meta require them before running ads.
2. Technical: SSL, links, and cross-browser testing
The technical checklist covers everything determining whether your site works correctly for every visitor on every platform. Most checks take five minutes each; skip them and you discover problems after real traffic has arrived.
SSL certificate. Every page on your site should load over HTTPS. This means not just the home page: verify several interior pages, the contact page, and any page that takes user input. Check the padlock in the browser's address bar and look for the URL scheme. While you're there, check for mixed content. An HTTPS page loading any resource (image, font, script, stylesheet) over HTTP will trigger a browser warning or silently block the resource. Use an online SSL checker like WhyNoPadlock to catch mixed content issues quickly.
Broken links. Run a link checker tool on the full site before launch. Every broken internal link (a page you linked to that doesn't exist, a mistyped slug, or an asset reference that got moved) is a dead end for both visitors and search engines. Broken external links are less urgent but still worth catching. Tools like Screaming Frog's SEO Spider (free for up to 500 URLs) or online crawlers like Ahrefs' Site Audit surface all of them in one pass.
Custom 404 page. Your server will return 404 errors for non-existent URLs. That's unavoidable. What matters is what the visitor sees when that happens. A white screen with "404 Not Found" and nothing else is a dead end. A custom 404 page that matches your site's design, explains that the page wasn't found, and includes navigation back to your home page or popular pages turns a dead end into a redirect opportunity.
Cross-browser and cross-device testing. Test on current versions of Chrome, Firefox, and Safari as a minimum. Safari on iOS in particular has historically handled certain CSS properties differently from Chromium-based browsers, and it's the default browser for iPhone users, which represent a significant share of mobile traffic. Test on both iOS and Android devices — not just browser dev tools emulation, but actual hardware or a service like BrowserStack that runs real device environments. Emulators miss rendering edge cases that physical devices catch.
Search engine access. Check that your site isn't accidentally telling Google to stay away. The private test version of a site is usually set up to keep Google out so it doesn't show up in search before it's ready, and that "stay out" instruction sometimes carries over to the live site if it was moved over rather than rebuilt from scratch. A single leftover instruction like that can keep your entire site out of Google's search results.
Favicon. That's the tiny logo that shows up in the browser tab. Small detail, but visitors notice when it's missing. It should be a square image (minimum 32×32 pixels, ideally 512×512) and properly hooked up so browsers know to display it.
3. SEO: what to get right before Google looks at your site
SEO setup before launch matters disproportionately. The first time Google reads your site sets baseline signals that influence how quickly your pages gain traction in search. Getting things wrong on that first visit — duplicate page headlines, a page-list file Google can't find, or signals pointing at the wrong web addresses — doesn't permanently damage you, but it creates cleanup work you'll have to do while the site is already live and Google may have already remembered the wrong information.
Page headlines and search summaries. Every page needs its own unique clickable headline — the bold blue line Google shows in search results. "Home | Business Name" on every single page isn't unique; it's the same thing repeated across the site, telling Google all your pages look identical. Each headline should describe what that specific page is about. The short summary Google shows underneath your link (about 140–160 characters) doesn't directly affect your ranking, but it heavily influences whether people click. Write it like an ad, not a sentence fragment.
Sitemap. This is a simple list of every page on your site that you hand to Google so it knows what's there. It should include every page you want found in search and nothing you don't (no test pages, no thank-you confirmation pages, no duplicate versions of the same page). After launch, submit it to Google Search Console. Don't assume Google will find it on its own. Submitting it gets your pages in line for immediate processing.
Stop Google seeing duplicate pages. The same page can often be reached at several slightly different web addresses (with or without the "www", with or without a slash at the end, secure or not). Without a clear signal, Google may treat each one as a separate, duplicate page and split your ranking strength between them. Each page should carry a behind-the-scenes signal telling Google which web address is the real one, and all the other versions should automatically forward to it. The signal is a backup, not a replacement for the forwarding.
Behind-the-scenes labels for Google. These are hidden labels that tell Google exactly what your business is, which can earn you richer-looking search results (star ratings, business hours, FAQ answers shown right on the results page). At minimum, a small business site should label the basics on the home page (or every page): your business name, address, phone number, and hours. Service pages should be labeled as services, and FAQ pages as questions and answers. Run these labels through Google's free Rich Results Test before launch to confirm nothing's broken or missing.
Social media previews. This controls the image, headline, and text that show up when someone shares a link to your site on Facebook, LinkedIn, iMessage, Slack, and other platforms. If it's not set, the platform guesses what to show, often badly — a blank box or a random scrap of text. Set a preview headline, a short description, and a preview image (1200×630 pixels is the standard size) on every page so shared links always look intentional.
Forwarding old web addresses (redesigns only). If any of your web addresses are changing in a redesign, every old address needs to automatically forward to its new one before launch. No exceptions. Any page that existed on the previous site and earned trust over time (links from other sites, bookmarks, social shares, directory listings) needs to forward to its new equivalent. An old address that leads to a dead-end "page not found" means lost search authority and frustrated visitors. For a full breakdown of the SEO side of launch preparation, see ArdinGate SEO setup →
4. Forms and functionality
A contact form that doesn't send is arguably worse than no contact form. Visitors fill it out and assume you'll respond, then wonder why you don't. Meanwhile you have no idea the submissions aren't arriving. This category needs end-to-end testing under production conditions, not just a quick tap in the browser.
Submit a test inquiry through your contact form from a different email address — ideally a personal Gmail rather than your business domain. Verify that the submission arrives in the correct inbox, that it isn't landing in spam, and that the auto-reply goes out to the address you submitted. Check the auto-reply on the receiving end as well: does it look right, does it contain the correct business name and contact information, and does it end up in the inbox rather than the spam folder?
Test spam protection by submitting the form with required fields left blank. A functional form with validation should refuse the submission. If your spam protection uses a honeypot field or CAPTCHA, confirm it's active. An unprotected contact form on a newly indexed domain will often start receiving spam submissions within days. Spam in your inbox is an annoyance; spam that fills your database or triggers your email service's sending limits is an operational problem.
If your site has integrations beyond a basic contact form (booking calendars, payment processors, appointment schedulers, client intake flows), test the entire path end-to-end. Click "Book Now," complete the booking, confirm the confirmation email arrives, and verify the booking shows in your calendar or dashboard. For payment flows, run a test transaction in your payment provider's sandbox mode before switching to live mode. Don't assume an integration works because it functioned on staging; production credentials, webhooks, and API keys differ from staging equivalents and need independent verification.
One frequent break between staging and production is email sending. Staging environments often use a local mail sandbox (Mailtrap or similar) that intercepts all outbound email instead of actually sending it. Switching over to the live email setup that really delivers messages is a common source of silent form failures. If email worked on the test version but breaks once the site is live, check that the live email settings point at the real account, not the test catch-all.
5. Speed and Google's page-health checks
Performance is worth checking before launch rather than after. A slow site doesn't fail visibly — it quietly drives higher bounce rates and lower conversion rates, and the fixes (image compression, script deferral, server tuning) are significantly easier to make before real visitors are hitting the page.
Run your site through Google PageSpeed Insights (pagespeed.web.dev) before launch. Run it on mobile, not just desktop. Mobile scores are almost always considerably lower, and Google uses mobile-first indexing, meaning the mobile version of your site is what Google evaluates for ranking. A desktop score of 95 and a mobile score of 42 is not acceptable. Aim for 90+ on desktop and at least 75+ on mobile before going live.
Pay attention to Google's three page-health checks: how fast your main photo or headline shows up on screen, how quickly the page responds when someone taps or clicks, and how much the page jumps around while it's still loading (which is what makes people accidentally tap the wrong thing). All three are confirmed factors in how Google ranks you. The targets: your main content should appear in under 2.5 seconds, the page should respond to a tap in under a fifth of a second, and the layout should stay put while loading. Failing any one puts you at a disadvantage against pages that pass.
The most common culprits on small business sites are oversized images (shrink the file sizes, switch to a modern image format that's far smaller without looking worse, and set each image's dimensions so the page doesn't jump around as they load), non-essential add-ons that hold up the page from appearing (especially third-party widgets like chat boxes and tracking pixels), and slow servers from cheap hosting (if your site is slow to even start responding, no amount of polishing the rest can fully make up for it).
For a full guide to what moves the needle on speed and in what order: How to speed up your website →. For a plain-English breakdown of Google's page-health checks and why website-builder platforms often struggle to pass them: Google's page-health checks explained →
6. Security and privacy
Security isn't just about keeping bad actors out. It's also about protecting your visitors' data and your site's availability. A few baseline checks before launch significantly reduce your exposure.
SSL configuration. The secure padlock is table stakes, but the setup quality varies. Check that your security certificate covers your domain both with and without the "www" in front. Set your server to automatically send every visitor to the secure version of the site, and to send all the alternate versions of your address (with or without the "www") to your single preferred one. Confirm the certificate expiry date and set up auto-renewal. Most hosts handle this automatically with Let's Encrypt, but verify the auto-renewal is configured and working. A lapsed SSL certificate becomes an outage: browsers block access to sites with expired certificates.
Security settings. There's a set of behind-the-scenes instructions your site sends to each visitor's browser that protect against common attacks. The ones worth setting on any site stop browsers from misreading your files, stop other websites from embedding your pages inside theirs to trick your visitors, and limit what information gets passed along when someone clicks a link off your site. Your web developer handles these, but you can confirm they're in place using securityheaders.com after launch.
Direct access to sensitive files. The behind-the-scenes files that run your site — the ones holding passwords, keys, and internal business logic — should be locked away so nobody can pull them up directly in a browser. Your developer should confirm that trying to open one of those files in a browser shows an error or a "not found" page, never the raw inner workings of your site.
Privacy policy and cookie notice. If your site collects personal data — anything from a contact form submission to an analytics cookie — you are legally required to disclose it in most jurisdictions. GDPR in Europe, CCPA in California, and a growing number of US state-level privacy laws all have specific disclosure requirements. A privacy policy page and a cookie consent notice (for sites with non-essential cookies) are required. This isn't just about legal compliance: platforms like Google and Meta require a compliant privacy policy before running paid ads, so missing it can block a future advertising channel.
7. Analytics and search console
You can't improve what you don't measure. Getting analytics in place before you drive any traffic to the new site means you have a clean baseline from day one. Adding it after the fact means you've already lost data from the launch period, which is often one of the most active traffic windows a new site sees as you announce it and drive initial attention.
Google Search Console. This is the most important tool for monitoring a website's relationship with Google search. Verify your domain in Search Console before launch — the DNS verification method is the most reliable, using a TXT record you add through your domain registrar. After launch, submit your sitemap through the Sitemaps section. Search Console shows you which of your pages have been indexed, what queries are sending traffic to your site, which pages have errors, and whether your page-health scores are passing or failing based on what real visitors experience. Check it at least weekly for the first month after launch.
Verify analytics is firing. If you're using Google Analytics, Plausible, Fathom, or any other analytics platform, verify the tracking code is firing on every page of the live site before you announce the launch. Open the real-time report in your analytics dashboard while navigating through the site. You should see your own session appear and pageviews increment as you move between pages. If a page doesn't register, the tracking snippet is missing or broken on that page, likely because a single page template variant wasn't updated or a header include failed to load.
Block internal traffic. Your own visits to the site will skew analytics data if you're not filtering them out. In Google Analytics 4, create an internal traffic filter by IP address under Admin. If you work from multiple locations or your IP changes frequently, browser-based filtering plugins (such as Block Yourself from Analytics) are a practical alternative. This matters most in the early weeks when total traffic is low and your own review sessions can represent a significant percentage of recorded pageviews.
404 error monitoring. Set up monitoring to know when visitors hit dead-end pages. Search Console's Coverage report surfaces crawl errors, but it doesn't catch 404s that aren't in your sitemap. If your analytics platform supports custom events or logs 404 pages as pageviews to a specific report, set that up. Knowing what broken URLs are being hit tells you which old URLs need redirects you missed and which internal links need correcting.
8. Post-launch: the first two weeks
Launch day isn't the finish line. It's when the real-world test begins. The first two weeks are the highest-density period for discovering issues because live traffic creates conditions that testing environments don't replicate: production email servers, actual DNS propagation, mobile devices on cellular networks, and real users navigating in unexpected ways.
Announce the launch. Don't wait for people to find the new site organically. Send an email to your list, post on the social channels where your audience is, and personally message anyone whose opinion matters to you. The initial traffic from announcement is valuable: it creates real-user data in Search Console and analytics, which feeds Google's understanding of how visitors engage with your pages. A site that gets zero traffic for the first two weeks after launch signals nothing to Google either way.
Monitor Search Console daily for the first week. Look at three reports: the Coverage report for errors and indexing issues, the page-health report for any pages that are failing the speed and stability checks based on what real visitors experience, and the Pages report to see which pages Google has indexed and which it hasn't. Any page that was indexed on your old site but isn't showing up on the new one after a week is worth investigating. Either the redirect is missing, or Google has dequeued it for a reason you can find in the Coverage details.
Check your form submissions daily. The contact form getting live traffic is a different load than one test submission. On most small business sites this is fine, but the first week of real traffic sometimes reveals issues: a submission from an unusual character set in the name field that breaks your handler, a spam wave that gets through the protection, or an email provider that starts flagging your form notification emails as spam. Watching form submissions daily in the first week means you catch these before they persist for months.
Test on a real mobile device. Dev tools emulation is useful but not equivalent to a physical device. Get your phone out and browse the site as a visitor would. Check the contact form on mobile. Tap every phone number link to confirm it dials. Scroll through long pages to see if anything breaks. The things most likely to surface: small tap targets that work fine with a mouse but are frustrating on a touchscreen, font sizes that render differently on mobile hardware than in the emulator, and layout breaks on very small screens that weren't in your test device matrix.
Watch server error logs. PHP errors, 500-level server errors, and unexpected exceptions sometimes only appear under real traffic patterns. If your host provides access to error logs (most do through cPanel, Plesk, or a CLI), check them once daily for the first week. An error that happens once per 50 visitors might not show up in manual testing but will accumulate in logs. Errors that silently eat form submissions or API calls are the ones you want to catch early.
9. Launch day: the exact sequence
Every other section in this guide covers categories of things to check. This section covers the sequence: what to do on launch day when you point your domain name from the old site to the new one, in what order, and what to confirm at each step before moving to the next. A launch isn't just "point the domain and hope." It's a deployment procedure with a specific order of operations.
Before you point the domain at the new site. Confirm the pre-launch checklist is complete on staging. The contact form sends. PageSpeed Insights mobile score is at least 75+. SSL is active on the staging URL. Redirects are staged and ready to deploy. All placeholder text is gone. Legal pages exist. Your analytics property is verified (but confirm it's not firing on staging; you don't want staging sessions polluting your baseline data). Screenshot or export the old site's Search Console performance data so you have a before/after benchmark.
Step 1: Point your domain at the new site. In your domain settings, update the entry that tells your domain name where to send visitors so it points at the new server. Write down the old address before you change it. If something goes wrong in the next two hours, you'll need it to switch back. There's a setting that controls how long it takes a domain change like this to spread across the internet — if it's set to an hour or more, lower it to a few minutes at least 24 hours before launch, so when you flip the switch the change takes effect quickly instead of leaving some visitors on the old site for up to an hour.
Step 2: Confirm the secure padlock is working on the live site. Before you announce anything, open a browser to your real domain (not the private test address) and confirm the padlock shows up and the security certificate is issued to the right domain. The certificate is usually set up automatically, but the system can only finish the job once your domain is fully pointing at the new server. Trying to set it up before the domain change has fully spread across the internet is the most common reason the padlock fails to appear at launch.
Step 3: Test the contact form from your phone. Not dev tools, not desktop. Use your actual phone on cellular (not WiFi) from an email address you don't normally monitor. This catches the production email config in the real environment and also catches any mobile layout issues that only surface on a real device against real network conditions. Confirm delivery to the business inbox and auto-reply to the submitter before moving on.
Step 4: Submit the sitemap to Search Console. Log into Google Search Console, navigate to Sitemaps, and submit your site's page-list address. Don't do this before your domain has finished pointing at the new server — Search Console will try to grab the page list from the live domain, and if it's still pointing at the old server, you'll get an error. After submitting, immediately use the URL Inspection tool to request indexing on your five highest-priority pages: home, your primary service page, contact, and any two pages you most want to rank.
Step 5: Verify analytics is live. Open the real-time report in your analytics dashboard and navigate through the site. Confirm your visit appears, and watch the page count tick up as you move from page to page. If the tracking is missing on any page, you'll see it in real-time as a gap — much better to catch now than after a week of launch traffic that went unmeasured.
Step 6: Spot-check redirects. Take ten to fifteen of your most important old web addresses and type them directly into a browser. Confirm each one lands on the correct new page, not a dead-end "page not found." It should also forward in a single hop rather than bouncing through several addresses on the way — each extra hop costs you a little bit of search authority and slows the visitor down, so a multi-step forward is worth straightening out now.
Step 7: Announce. Only after the above steps are confirmed. Send the email, post on social, message the contacts. Now you're driving traffic to a verified environment, not a gamble.
What to do if something breaks during launch. Stay calm and work through it systematically. If the site is completely down, check whether your domain has finished pointing at the new server yet (an online "DNS propagation checker" tells you in seconds). If the secure padlock isn't showing up, check that nothing is blocking the certificate system from reaching your domain. If the contact form is broken, check the live email settings first. If pages are showing "not found" unexpectedly, have your developer check the server setup. Having the old server's address handy so you can switch back is your last resort. Keep it written down until you're confident the launch is stable.
Key takeaways
- Read every page before launch. Placeholder text, wrong phone numbers, and missing legal pages require human review — no tool catches them automatically. Block time to actually read the site as a visitor would.
- The secure padlock is non-negotiable. Every page should load securely, with nothing on the page sneaking in over an insecure connection. Use a free padlock checker to catch any insecure pieces before visitors see the browser warnings they trigger.
- Get SEO right before Google first looks at your site. A unique clickable headline on every page, a valid page list submitted to Search Console, a clear signal of which web address is the real one, behind-the-scenes labels tested against Google's Rich Results Test, and — for redesigns — old web addresses forwarding to their new equivalents. These are pre-launch tasks, not post-launch cleanups.
- Test forms end-to-end under production conditions. Use a different email address. Verify delivery, auto-reply, and spam filter behavior on both ends. Staging email sandboxes and production mail configs are different, and they break in different ways.
- Run PageSpeed Insights on mobile before launch. Your mobile score is what matters for Google's ranking. An unoptimized site can be addressed before launch; it's harder after you've already announced and driven traffic to it.
- Verify analytics before you drive any traffic. Open the real-time report and navigate through the site. If a page doesn't register, find out why before you start measuring your launch results against broken data.
- Plan to be available on launch day. Launch during business hours mid-week. Have server access, your host's support contact, and two to three hours blocked to monitor before you step away.