Website Launch Checklist: 45 Things to Check Before Your Site Goes Live

Damjan Dulović · Oct 19, 2026 · 16 min read

Most websites don't fail on design. They fail on the boring details nobody checks before launch: a link shared on WhatsApp shows no preview, a broken URL lands on a default white "Not Found" page, Google indexes the staging domain, the contact email ends up in spam, and the favicon is still the framework logo.

This is the website launch checklist I go through before any site goes live — client projects, SaaS landing pages, app pages and my own portfolio. When I rebuilt vhirty.com, I went through every item on this list: one shared Open Graph image, a custom 404 page, a sitemap, canonical URLs, redirects from the old site, structured data and an llms.txt file for AI assistants. None of it is visible on the homepage. All of it matters.

The list is grouped by area, so you can use it as a pre-launch website checklist, a technical SEO checklist, or a QA checklist for a website handoff.

The first time most people see your website is not on your website. It's a link preview in Slack, iMessage, LinkedIn, X, Discord, WhatsApp or Telegram. If that preview is empty, the click usually doesn't happen.

1. Open Graph image (OG image)

The Open Graph image is the picture that appears when someone shares your link. Without it, platforms either show nothing or pick a random image from the page.

Size: 1200 × 630 px (1.91:1 ratio) works everywhere.
Format: JPG or PNG. Keep the file small — under 1 MB loads reliably in every preview crawler.
Keep important text away from the edges. Some platforms crop to a square or a slightly different ratio.
Use an absolute URL in the tag (https://yourdomain.com/og.jpg), not a relative path. Crawlers don't resolve relative URLs reliably.

You have two strategies: one shared OG image for the whole site, or a generated image per page. Per-page images (with the post title rendered on them) look great, but they add a build step and more things to maintain. On vhirty.com I started with per-page images and switched to a single textured OG image for every page — new blog posts get a good preview without any extra work. For a small site, a portfolio or a product landing page, one strong image is usually enough.

2. Open Graph meta tags

The image alone is not enough. Every page needs the full set:

<meta property="og:title" content="Page title" />
<meta property="og:description" content="One-sentence summary" />
<meta property="og:image" content="https://yourdomain.com/og.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:url" content="https://yourdomain.com/page/" />
<meta property="og:type" content="website" />
<meta property="og:site_name" content="Your Brand" />

Use og:type article for blog posts. Add og:image:alt so the image has a text description.

3. Twitter / X card tags

X reads Open Graph tags as a fallback, but set the card type explicitly or you may get a tiny thumbnail instead of a large image:

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:site" content="@yourhandle" />

4. Test every preview before launch

Don't assume the tags work. Check them with the LinkedIn Post Inspector, Facebook's Sharing Debugger and by pasting the link into a private chat with yourself. Preview crawlers cache aggressively — if you change the OG image after the first share, the old one may stick for days. The debuggers let you force a re-scrape.

One trap: if your OG tags point to the production domain but the site is still on a staging URL, previews won't work until the real domain is connected. That's expected — just don't forget to test again after launch.

Part 2: Favicons and app icons

5. A complete favicon set

The default framework favicon is the fastest way to make a site look unfinished. In 2026, you need surprisingly few files:

favicon.ico (32 × 32) for older browsers and some tools that request it directly
icon.svg — a scalable favicon, which can even adapt to dark mode with a media query inside the SVG
apple-touch-icon.png (180 × 180) for iOS home screen bookmarks
192 × 192 and 512 × 512 PNGs referenced from a web app manifest

6. Web app manifest

A manifest.webmanifest file tells Android and desktop browsers your site name, icons, theme color and background color. Even if your site isn't a PWA, it controls how your site looks when someone adds it to their home screen. Add a maskable icon version with enough padding so Android doesn't crop your logo.

7. Theme color

<meta name="theme-color"> colors the browser UI on mobile. Set separate values for light and dark mode with the media attribute if your site supports both.

Part 3: Error pages

8. Custom 404 page

Every site gets broken links: old URLs, typos, links from other sites that changed. A default 404 page is a dead end. A good custom 404 page:

Clearly says the page doesn't exist (no clever copy that hides the message)
Keeps the full navigation and footer, so the visitor isn't trapped
Offers one or two obvious next steps: home, blog, search, or your most popular page
Matches the design of the rest of the site

It's also one of the few places where you can have some fun. The 404 page on vhirty.com is a glass card over a giant faint "404", with a dot grid that lights up around the cursor. Small detail, but it turns an error into something people actually remember.

9. The 404 page must return a real 404 status code

This is the technical part that most people miss. If your "not found" page returns HTTP status 200, search engines treat it as a real page — this is called a soft 404. Google flags it in Search Console and it can pollute your index with junk URLs.

Check it with the browser's Network tab or with curl -I https://yourdomain.com/this-does-not-exist. You want to see 404, not 200. Static hosts (Cloudflare, Netlify, Vercel, GitHub Pages) each have their own way of serving 404.html with the correct status — verify it on the live deployment, not just locally.

10. A 500 / error page

Server errors happen. If your site has any backend, API routes or server rendering, make sure the error page is designed too, and that it doesn't leak stack traces or environment details.

Part 4: On-page SEO basics

11. Unique title tag on every page

The <title> is still one of the strongest on-page SEO signals and it's what people see in the search results and the browser tab. Rules:

Unique per page
Roughly 50–60 characters so it doesn't get cut off
Main keyword near the start, brand at the end: Website Launch Checklist | Vhirty

12. Meta description

The meta description doesn't directly affect rankings, but it heavily affects click-through rate. Write one per page, around 150–160 characters, that tells the searcher exactly what they get. Google rewrites it sometimes; a good one gets rewritten less.

13. One H1 and a logical heading structure

One H1 per page that matches the page's topic, then H2 and H3 in order. Headings are how both search engines and screen readers understand the structure of the page.

14. Descriptive URLs

/blog/website-launch-checklist/ beats /blog/post?id=482. Short, lowercase, words separated by hyphens. Pick one convention — with or without a trailing slash — and stick to it everywhere.

15. Image alt text

Every meaningful image needs an alt attribute that describes it. Decorative images get an empty alt="" so screen readers skip them. Alt text helps accessibility, image search and context for search engines.

16. Internal links

New pages with no internal links pointing to them are hard to discover — for users and for crawlers. Link related posts to each other, link from the blog to your product pages, and link product pages to the relevant guides.

Part 5: Technical SEO and indexing

17. XML sitemap

A sitemap.xml lists every URL you want indexed. Generate it automatically on every build so new pages are never forgotten. Only include canonical, indexable URLs — no redirects, no 404s, no noindex pages. A single sitemap file can hold up to 50,000 URLs.

18. robots.txt

robots.txt tells crawlers what they're allowed to crawl and where your sitemap is:

User-agent: *
Allow: /
 
Sitemap: https://yourdomain.com/sitemap.xml

Important: robots.txt blocks crawling, not indexing. If you want a page kept out of Google, use a noindex meta tag instead — and don't block that page in robots.txt, or Google will never see the noindex.

19. Canonical URLs

Every page should have a <link rel="canonical"> pointing to its own preferred URL. This prevents duplicate content issues when the same page is reachable through several URLs (with and without trailing slash, with tracking parameters, through www and non-www).

20. www vs non-www, HTTP vs HTTPS

Pick one version of your domain and 301-redirect everything else to it. http://, https://www. and https:// should all end up on exactly one URL. Test all four combinations.

21. Staging and preview environments must not be indexed

The classic disaster: Google indexes your staging domain and it competes with your real site. Keep preview deployments on noindex (or behind auth) until launch. On vhirty.com, the new site ran on a workers.dev address with indexing switched off until the real domain was connected — then the switch flipped on. Make sure you actually flip it. Forgetting to remove noindex at launch is one of the most common SEO mistakes there is.

22. Redirects from old URLs

Redesigning or migrating a site? Every old URL that had traffic or backlinks needs a 301 redirect to its new equivalent. Without redirects you lose the SEO value those pages built up and everyone following old links hits your 404 page. Crawl the old site (or export URLs from Search Console) before you take it down, and map every important URL.

23. Structured data (Schema.org / JSON-LD)

Structured data helps search engines understand what a page is: an organization, a person, an article, a software application, a product, an FAQ. Add JSON-LD for at least:

Organization or Person on the homepage
Article / BlogPosting on blog posts
SoftwareApplication on app pages
BreadcrumbList where it makes sense

Validate it with Google's Rich Results Test and the Schema.org validator.

24. Google Search Console and Bing Webmaster Tools

Verify the domain in both on launch day and submit your sitemap. Search Console shows indexing problems, soft 404s, Core Web Vitals data and which queries bring you traffic. Bing Webmaster Tools matters more than people think — Bing's index also powers several other search engines and AI assistants.

25. llms.txt and AI discoverability

More and more people ask ChatGPT, Claude or Perplexity instead of searching Google. An llms.txt file in the root of your site gives AI assistants a clean, plain-text summary of who you are, what you do and which pages matter. It's a young, informal standard, but it costs ten minutes to write. I added one to vhirty.com describing what I build and who it's for, so an assistant asked "who can build a Play Store app for me" has something clear to read.

Part 6: Performance and Core Web Vitals

26. Core Web Vitals targets

Google measures real-user performance with three Core Web Vitals:

LCP (Largest Contentful Paint): under 2.5 seconds
INP (Interaction to Next Paint): under 200 ms
CLS (Cumulative Layout Shift): under 0.1

Run PageSpeed Insights and Lighthouse on your most important pages — on mobile, not just desktop.

27. Image optimization

Images are usually the biggest part of a page. Serve modern formats (WebP or AVIF), resize to the size you actually display, lazy-load images below the fold, and always set width and height so the layout doesn't jump while they load. Don't lazy-load the hero image — that hurts LCP.

28. Fonts

Self-host your fonts or preload the critical ones, use font-display: swap, and only load the weights you actually use. Four font weights you never use is pure page weight.

29. JavaScript weight

Heavy animation libraries, WebGL backgrounds and third-party scripts add up fast. Test the site on a mid-range phone, not your laptop. During the vhirty.com build I tried several animated hero backgrounds and dropped the ones that lagged — beautiful doesn't matter if the page stutters.

30. Caching and CDN

Static assets with hashed filenames should be cached for a long time (Cache-Control: public, max-age=31536000, immutable). HTML should be cached briefly or revalidated so updates show up. Serving from a CDN edge — Cloudflare, Vercel, Netlify — makes the site fast globally, not just near your server.

Part 7: Security

31. HTTPS everywhere

Every page and every asset over HTTPS, with automatic certificate renewal. Mixed content (an HTTP image on an HTTPS page) breaks the padlock and sometimes the page itself.

32. Security headers

A few HTTP headers block whole classes of attacks. At minimum:

Strict-Transport-Security (HSTS) — forces HTTPS
Content-Security-Policy — controls which scripts and resources can load
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy — disables browser features you don't use (camera, microphone, geolocation)
frame-ancestors in your CSP to prevent clickjacking

Check your score at securityheaders.com.

33. No secrets in the frontend

API keys, tokens and private environment variables must never ship in the client bundle. Search your built JavaScript for anything that looks like a key before launch. If a key leaked, rotate it — deleting the file is not enough.

34. Forms and spam protection

Contact forms attract bots within days. Add rate limiting and a bot check (Cloudflare Turnstile, a honeypot field, or both). Or skip the form entirely: on vhirty.com I removed the contact form and just show the email address with "Write an email" and "Copy address" buttons — no form backend to secure, no mail service to maintain.

35. security.txt

A /.well-known/security.txt file tells security researchers how to report a vulnerability. It's a short file with a Contact: and an Expires: field (RFC 9116). Small effort, looks professional.

Part 8: Accessibility

Unplug your mouse and use the site with Tab, Shift+Tab, Enter and Escape. Every interactive element must be reachable, focus must be visible, and menus and modals must be closable with Escape.

37. Color contrast

Normal text needs a contrast ratio of at least 4.5:1 against its background (WCAG AA), large text 3:1. Light grey text on white looks elegant in Figma and unreadable on a phone in sunlight.

38. Language attribute and semantic HTML

Set <html lang="en"> (or the right language) so screen readers pronounce the content correctly. Use real buttons for actions and real links for navigation — not clickable divs.

39. Reduced motion

If your site has big animations, page transitions or parallax, respect prefers-reduced-motion. Some users get physically sick from motion.

Part 9: Legal, privacy and analytics

40. Privacy policy

If you collect any data — analytics, forms, newsletter, cookies — you need a privacy policy. For apps published on Google Play and the App Store, a public privacy policy URL is mandatory anyway.

If you have visitors from the EU and you use cookies or trackers that aren't strictly necessary, you need consent before setting them. The simplest way to avoid the cookie banner entirely: use cookieless, privacy-friendly analytics.

42. Analytics installed and verified

Install analytics before launch, not a week after — you lose the launch-day data otherwise. Then verify it actually records visits from the live domain. Cloudflare Web Analytics, Plausible and Umami are lightweight options that don't need a cookie banner.

Part 10: Email, monitoring and launch day

43. Domain email: SPF, DKIM and DMARC

If your domain sends email — contact replies, transactional email, newsletters — set up SPF, DKIM and DMARC DNS records. Without them, your emails land in spam or get rejected, and anyone can spoof your domain. Test with a mail-tester service before launch.

44. Uptime monitoring and error tracking

You should find out your site is down before your users do. Set up a free uptime monitor that checks the homepage every few minutes and alerts you. If the site has a backend, add error tracking so production errors don't silently pile up.

45. Final launch-day pass

On launch day, with the real domain connected:

Click every link in the navigation and footer
Test on a real iPhone and a real Android phone, not just responsive mode
Share a link in a chat app and check the preview
Request a URL that doesn't exist and confirm the 404 page and status code
Confirm noindex is gone and robots.txt allows crawling
Submit the sitemap in Search Console and Bing Webmaster Tools
Check that analytics records your own visit
Run Lighthouse one more time on the live URL

The short version: website launch checklist

FAQ

What should I check before launching a website?

At minimum: link previews (Open Graph image and tags), favicon, a custom 404 page with a real 404 status, unique titles and meta descriptions, a sitemap, robots.txt, canonical URLs, redirects from old URLs, HTTPS, mobile performance, analytics and a privacy policy. The full list above covers 45 items.

What size should an Open Graph image be?

1200 × 630 pixels, a 1.91:1 ratio, as JPG or PNG. Keep important content away from the edges and the file reasonably small so preview crawlers load it reliably.

Does a custom 404 page help SEO?

The design itself doesn't improve rankings, but it keeps visitors on your site instead of leaving. What matters for SEO is that the page returns a real HTTP 404 status code. A "not found" page that returns 200 is a soft 404 and Google reports it as an error.

Do I need a sitemap for a small website?

It's not strictly required for a small, well-linked site, but it costs nothing when generated automatically and it helps new pages get discovered faster. Submit it in Google Search Console on launch day.

What is llms.txt?

A plain-text file in the root of your site that summarizes your site for AI assistants like ChatGPT, Claude and Perplexity. It's an informal, emerging convention, not an official standard, but it's a cheap way to make your site easier for AI tools to understand and recommend.

If you're launching a website, a SaaS landing page or an app and want it built with all of this handled from day one, that's exactly what I do. Have a look at my work or reach me at collab@vhirty.com.

Part 1: Link previews and social sharing