Blog · 6 November 2026 · 10 min read

Website launch checklist: 24 things to check after your new site goes live

The new site looks great, the agency has sent its invoice, everyone is happy. Then it turns out Google has not seen the site for three weeks, the contact form sends e-mails into the void, and the old URLs printed on your business cards lead to a 404. These are not rare accidents. They are the standard set of launch mistakes we see in almost every audit of a freshly launched site. Below is a list of things to check in the first week, each with a way to verify it yourself in about a minute.

Day one: can anyone find the site at all

1. No leftover “noindex” from staging. Draft versions are hidden from Google with <meta name="robots" content="noindex"> or a rule in robots.txt, and this very often survives the move to production. How to check: open yourdomain.com/robots.txt; there should be no Disallow: /. View the home page source (Ctrl+U) and search for “noindex”. In WordPress: Settings → Reading → “Discourage search engines” must be unticked.
2. Redirects from old URLs. If a site existed before, every old page URL (services, contact, blog posts) should 301-redirect to its new equivalent. Without this you lose rankings and the traffic from links that have accumulated over the years. How to check: take 10 old URLs from Search Console or the old sitemap and paste them into the browser. Each should land on a sensible new page, not a 404 and not the home page.
3. One canonical address. http://, https://, with www and without: three of the four must redirect to the fourth. Otherwise Google sees duplicates and users get different cookies. How to check: type all four variants and see whether the address bar always ends up the same.
4. Sitemap and Search Console. A new site usually has a new sitemap (/sitemap.xml); submit it in Google Search Console and request indexing of the home page. If the domain changed, use the “Change of address” tool. How to check: Search Console → Sitemaps → status “Success”; after a few days the “Pages” report shows how many URLs made it into the index.
5. Canonical tags. Each page should point to itself with <link rel="canonical">. A common post-migration bug is a canonical still pointing at the staging host or the old domain. How to check: search the source of a few pages for “canonical” and compare the URL with the address bar.
6. A proper 404 page. Type a non-existent URL. The page should return status 404 (not 200 with a “not found” message, which Google indexes as junk, a “soft 404”) and help the visitor onwards: menu, search, contact.

HTTPS and basic security

7. Certificate and https redirect. A padlock on the home page is not enough; check that typing http:// takes you to https:// and that the certificate also covers the www version. How to check: type the address with http:// by hand; click the padlock and note the certificate expiry. If it does not renew automatically, put a reminder in your calendar.
8. Mixed content. Images, scripts or fonts loaded over http:// on an https page: a classic after migrating an old site, because the URLs sit inside the content. Browsers block them or drop the padlock. How to check: open the browser console (F12 → Console) on a few pages and look for “Mixed Content” warnings.
9. Security headers. HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy: six lines of configuration that every scanner flags when missing. What they do and how to enable them: separate article.
10. Admin panel. Change the default “admin” login, enable two-factor authentication, remove test accounts created by the developers (or change their passwords), check who has administrator rights. Enable automatic updates for the CMS and plugins, or agree who does them.
11. Backups. Ask the host or agency: how often, where, and has anyone ever tried to restore one. A backup nobody has tested is a wish, not a backup.

Does it work: forms, analytics, consent

12. Contact form: send a test enquiry. From your phone, not from the agency’s computer. Check that the e-mail arrived, to whom, that it did not land in spam, and that the “Thank you” message appears on the site. The usual failures: the host blocks PHP mail, the destination address is the developer’s mailbox, or the domain lacks SPF/DKIM so everything goes to spam.
13. SPF, DKIM, DMARC for the domain. If the site sends e-mail (forms, shop, newsletter), the domain needs these three DNS records, otherwise Gmail and Outlook reject or flag the messages. How to check: send a form e-mail to a Gmail account → “Show original” → three lines saying PASS.
14. Analytics. Google Analytics / Tag Manager / ad pixel: is the code on every page, does it register visits in real time, and is the ID not a leftover from staging or the previous site? How to check: open the site on your phone and watch the “Realtime” report.
15. Cookie consent. The banner must actually block analytics and advertising scripts until consent, offer “Reject” as easily as “Accept”, and work with the keyboard. A fake banner with analytics firing underneath is a regulatory risk and a source of customer complaints. How to check: incognito window, F12 → Network, reload: before you click consent there should be no requests to Google Analytics or Facebook.
16. Conversion goals. If you pay for ads, send a test enquiry and check that the conversion appears in Google Ads / Analytics. Without it the ad algorithm optimises blind.

Phone, speed, accessibility

17. PageSpeed score on mobile. A new site built on a new template is often slower than the old one: animations, heavy fonts, uncompressed photos from the shoot. How to check: pagespeed.web.dev, “Mobile” tab; LCP under 2.5 s is the target. Why sites are slow on mobile and what to do: here.
18. Images. A 4000×3000 px photo displayed in a 400 px box is the single most common cause of a slow page. Check the home page weight (PageSpeed will say “Properly size images”) and whether the CMS generates WebP/AVIF versions.
19. Tappability on a phone. Go through the site with your thumb: menu, form, phone and map buttons. Links too close together and text that needs zooming are criteria Google uses to lower the mobile rating.
20. Basic accessibility. Text contrast, alt text on images, labels on form fields, keyboard operability. For shops and booking sites this has also been a legal requirement in the EU since 2025: who is covered and where to start. How to check: the “Accessibility” score in PageSpeed / Lighthouse and the list of failures under it.

Content and formalities

21. Company details. Full legal name, address, registration or VAT number, e-mail and phone in the footer or on the contact page: a legal requirement for businesses in most EU countries, and for customers a sign that the company exists. Check that the phone number is clickable (tel:) and that the map leads to the right address.
22. Terms and privacy policy. Current, with the new domain name, describing the tools actually in use (analytics, forms, newsletter). Copy-paste from the old site usually lists tools that are gone and omits the ones that are there.
23. Link previews and favicon. Paste the site address into a message on WhatsApp, LinkedIn or Slack: a title, description and image should appear (Open Graph tags). The favicon should show in the tab and on a phone’s home screen after “Add to home screen”. Small things, but they make the first impression in every shared link.
24. Placeholder text and typos. Search the whole site for “Lorem ipsum”, “Post title”, “Insert here”, “example.com” and the template’s phone number. Check the tab titles (<title>) on several pages; often they are all identical or read “Home – New site”.

After a week

Go back to Search Console: the “Pages” report shows how many URLs Google has indexed and why it skipped the rest (most often: redirects, duplicates, “Discovered – currently not indexed”). The “Core Web Vitals” report starts showing data from real users once there is enough traffic. Compare the number of form enquiries and calls with the period before the launch. A drop after a new site is usually not “a slow season”, it is one of the points above.

Whose job is this

Most of these points are formally the contractor’s responsibility, but in practice nobody checks them unless the client asks. Good practice: put this list into the contract as acceptance criteria and walk through it together before the final payment. An agency that asks for this itself is a good sign.