Website Launch Checklist: SEO, Security and Speed

A website launch checklist is a list of things you test before the domain points at the new site and again in the first week after it does. Common trouble spots are forms that silently fail, pages left set to noindex, missing HTTPS, oversized images and DNS records set up wrong. Work through the groups below, then copy the plain-text list further down to tick off. A browser, a phone, a second email address and a terminal are enough. If you wrote a brief, such as one from the web developer project brief template, check the site against it.

What should you check on content and forms before launch?

Start with what a visitor touches first. Click every link in the header, the footer and the body of each page, and fix anything that goes nowhere. Open the site on a real phone as well as in a resized browser window. Test every form as if you were a customer. Submit it with valid data, with missing fields, and with a long message and an odd email address. Check that the confirmation message appears and that the email arrives in the right inbox, not in spam. If the form sends mail from your own domain, check that the SPF and DKIM records for your sending service are set up, since mail without them is more likely to be filtered. Create a custom 404 page that links back to the home page, and visit a made-up address to see it. Add the legal pages your business needs, usually a privacy policy and terms. Laws differ by country, so have someone qualified in yours review the wording. Finally, remove placeholder text and sample data. A leftover "lorem ipsum" paragraph is easy to miss.

Which SEO checks matter before you go live?

Search engines cannot rank pages they may not index, so first check that no block was left over from development. Staging sites often carry a noindex tag or a robots.txt rule that disallows everything. Both must be gone on the production site. Google's guide to blocking indexing also explains that a noindex tag only works if the page is not blocked in robots.txt, because Google has to fetch the page to see the tag. For a private staging site, password protection is safer than either. For each important page, check that the title and meta description are unique and describe that page. Give each page a clear main heading (H1). Set a canonical URL on pages that could be reached at more than one address, so search engines know which version you prefer. A canonical that points to the page itself is fine. Technical SEO for Next.js shows how to set these in code, and the on-page SEO checklist covers the wider page-level list. If someone else builds the site, questions to ask about SEO-friendly web development covers what to confirm with them. Generate a sitemap.xml that lists only the pages you want indexed, using your final https address, and reference it from robots.txt with a Sitemap line. The robots.txt file must sit at the root of your domain, and the sitemap usually does too. If you are replacing an old site, make a list of its important addresses and redirect each one to the closest matching new page with a permanent redirect (301 or 308). Sending every old address to the home page is a weak substitute. Redirects keep existing links from other sites working. Add analytics if you use it, verify the domain in Google Search Console and submit the sitemap there.

How do you make the site fast enough at launch?

Speed problems at launch are usually images. Check that photos are compressed, sized for the space they fill and served in a modern format where your platform supports it. A 4000 pixel wide photo in a 400 pixel slot wastes the visitor's data. Lazy-load images that sit far down the page, but not the large image at the top, which should load as early as possible. Use few font families and weights, and make sure text shows while the font loads. Then measure. Run the home page and one deep page through PageSpeed Insights or Lighthouse and read the three Core Web Vitals (loading, responsiveness, layout stability). Core Web Vitals explained describes each one. Lab scores vary between runs, so look for large problems and ignore small differences. Static files such as images, scripts and stylesheets should be cached by the browser or a CDN. The headers command further down shows the cache-control value.

What security checks belong on a launch checklist?

Serve everything over HTTPS, and redirect plain HTTP to HTTPS. Check that no page loads a script, image or font over plain HTTP, because browsers may block it or show a warning. Keep secrets out of the code repository. API keys, database passwords and signing keys belong in environment variables on the host. If a secret was ever committed, replace it, because deleting the file leaves it in the history. Look at the security headers your site sends. OWASP's Secure Headers Project lists the common ones and what each does. Strict-Transport-Security, X-Content-Type-Options and Referrer-Policy are sensible starting points. Two of them need care. Strict-Transport-Security (HSTS) makes browsers use only HTTPS for your domain until its max-age runs out, so turn it on after HTTPS works on every page, start with a short max-age, and add includeSubDomains or preload only when every subdomain is ready. A strict Content-Security-Policy can block scripts and styles you rely on, so try it first with the Content-Security-Policy-Report-Only header and read the reports before you enforce it. Put rate limiting or a bot check on forms and login pages so one script cannot flood them. Confirm that backups run and that you know how to restore one. Update the CMS, plugins, framework and dependencies before launch and decide who does it afterwards, since an outdated site is easier to attack. Use strong, unique passwords and two-step sign-in on admin areas, and remove accounts you created for testing.

Does accessibility belong on a launch checklist?

Yes, and the basics are quick. Every meaningful image needs alt text that describes it, and decorative images should have an empty one. Check text contrast, especially grey text on white and text over photos. Try the whole site with only the keyboard. You should reach every link, button and form field with the Tab key, see where focus is, and operate menus without a mouse. Give each form field a visible label, since placeholder text disappears once someone starts typing. The W3C guide to preliminary accessibility checks walks through these tests on a real page. It does not replace an audit, but it catches common problems.

How do domain and DNS settings work at launch?

DNS is the address book that tells browsers which server holds your site. For a typical small site you add an A record on the root domain (example.com) pointing at an address your host gives you, and a CNAME record on www pointing at a hostname your host gives you. Some hosts ask instead for an ALIAS record on the root, or for you to switch to their nameservers. Copy the exact values from the host's dashboard. If the domain also handles email, keep the MX records, or mail stops arriving. When you change nameservers, recreate the existing MX and TXT records (including SPF and DKIM) at the new DNS provider first. Remove records left over from earlier setups, such as registrar parking pages, forwarding rules and stale A records. They can send some visitors to the wrong place. A day or two before launch, lower the TTL on the records you will change. The TTL is how long other servers cache a record, and a short one speeds up the switch. After you save the change, wait: propagation can take from a few minutes to a day or two, and some people will see the old site meanwhile. Most hosts issue an HTTPS certificate once the domain points at them, so a certificate error right after a change often clears by itself. If it does not, check that the records are correct and that no extra record, such as an old AAAA record (IPv6), points somewhere else. I set up my own domain, fawazisrar.com, for this portfolio in the same general way. Pick one main address, with or without www, and permanently redirect the other to it.

What should you copy into your own launch checklist and how do you test it?

The items are numbered so you can refer to them when you talk to a developer. Remove what does not apply.

Text

CONTENT AND FORMS
1. Every link in header, footer and body works.
2. Site checked on a real phone and one other browser.
3. Every form tested: valid, empty, long input, odd email.
4. Form emails arrive in the right inbox and not in spam.
5. Custom 404 page exists and links home.
6. Privacy policy and terms pages added and reviewed.
7. Placeholder text, test accounts and sample data removed.

SEO
8. noindex removed from production, staging protected or kept out of results.
9. Unique title and meta description on every page.
10. Clear H1 on every page.
11. Canonical URL set on every page.
12. sitemap.xml loads and lists only pages to be indexed.
13. robots.txt loads at the root, has no leftover Disallow: / rule, points to the sitemap.
14. Old addresses redirect to matching new pages.
15. Analytics installed.
16. Domain verified in Google Search Console, sitemap submitted.

PERFORMANCE
17. Images compressed, correctly sized, top image not lazy-loaded.
18. Fonts limited and text visible while they load.
19. Core Web Vitals checked on home page and one deep page.
20. Static files cached (check cache-control).

SECURITY
21. HTTPS everywhere, HTTP redirects to HTTPS.
22. No mixed content warnings.
23. Secrets stored as environment variables, none in the repository.
24. Security headers set and checked with curl, HSTS only after HTTPS works everywhere.
25. Rate limiting or bot check on forms and login.
26. Backups running and restore tested.
27. Software, plugins and dependencies updated.
28. Test accounts removed, admin uses strong password and two-step sign-in.

ACCESSIBILITY
29. Alt text on meaningful images.
30. Text contrast checked.
31. Whole site usable with keyboard only.
32. Every form field has a visible label.

DOMAIN AND DNS
33. Root domain and www set from the host's exact values (A or ALIAS, CNAME, or nameservers).
34. Old parking and forwarding records removed, MX records kept.
35. TTL lowered before the change, propagation waited out, certificate issued.
36. One main address chosen, the other redirects to it.

FIRST WEEK
37. Check hosting and error logs daily.
38. Check Search Console page indexing report for problems.
39. Crawl the site for broken links and fix them.
40. Test forms again and confirm emails still arrive.
41. Recheck speed on real pages.

Three curl commands check the live site from a terminal. Replace example.com with your own domain. They run as written in Linux, macOS, WSL and Git Bash. Windows PowerShell has no grep or head, and plain curl there is an alias for a different command.

Bash

# 1. Home page headers: status, redirect target, security headers, caching
curl -s -D - -o /dev/null https://example.com | grep -iE "^(HTTP|location|strict-transport|content-security|x-content-type|referrer-policy|cache-control|x-robots-tag)"

# 2. Redirects: print every hop from an old or http address
curl -sL -D - -o /dev/null http://www.example.com/old-page | grep -iE "^(HTTP|location)"

# 3. Sitemap and robots.txt are reachable
curl -sL https://example.com/sitemap.xml | head -20
curl -sL https://example.com/robots.txt

In the first command, an x-robots-tag header containing noindex blocks indexing. A robots meta tag sits in the page HTML and will not show here, so check the page source too. In the second, each redirect appears as a status line followed by a location line. You want 301 or 308 for a permanent move, ideally in one hop. In the third, the sitemap should list real addresses on your domain, and robots.txt should include a Sitemap line.

What should you do in the first week after launch?

Read the host's error logs, try the forms again, and ask someone who has not seen the site to complete the main task on a phone. Real visitors find what testing misses. After a few days, open Search Console and see which pages Google has found, which it skipped and why. Indexing is not instant. If an important page is excluded, check for a stray noindex tag, a wrong canonical URL or a redirect loop. Click through the site again to find broken links, since content edits after launch often introduce them, and recheck speed on the pages people visit. Then add a calendar note for updates and backup checks.

Planning a project like this?

I am Fawaz Israr, a full stack developer in Rahim Yar Khan, Pakistan. I am a final-year Computer Science student at KFUEIT and I work in web development at Hadi Dev Lab. If you want a second pair of eyes on a launch or need a site built, message me on WhatsApp or by email. You can read about me or look at my work, including My-Shop, a custom gift builder store. Cover photo from Unsplash.