The Complete Website Publishing Checklist: 70+ Things to Check Before You Go Live

A developer pushed a site live on a Friday afternoon. Clean code, fast load times, everything tested. He closed his laptop and went home.

Monday morning, the client called. The contact form had been collecting submissions all weekend and sending every one of them to test@localhost. Forty-three leads, gone. Including one from a company that would have been their biggest deal of the quarter.

That’s how website launches break. Not with one big disaster, but with one small thing nobody double-checked. A placeholder email in a form handler. A typo in the hero. A staging noindex tag is sitting quietly on production.

The fix is a checklist. Over 70 items grouped into 16 categories, the framework technext.it uses on every client launch, written up in full so any team can run it.

Let’s get into it.

How to Use This Checklist

A few ground rules before you start:

• Work through the sections in order. They build on each other. No point running a performance audit on a site that still has placeholder copy.
• Do a full pass on staging first. Production is never the place to debug.
• Split the work on team projects. SEO to one person, accessibility to another, performance to a third. It moves faster and nothing falls through the cracks.
• Keep a known-issues log. Some items will ship anyway — that’s fine. Just write them down so they don’t quietly disappear after launch.

Now to the checks.

1. Content and Copy

This is the layer visitors actually see, so it’s the one stakeholders notice first. Get it right before you touch anything else.

Proofreading and Placeholder Removal

Read every page out loud. It’s tedious, and it catches things your eyes skim over — awkward phrasing, missing words, sentences that trail off. After that, search the codebase for “Lorem ipsum,” “TODO,” “FIXME,” and whatever default strings your CMS generates. Check image alt text while you’re at it. Placeholders love hiding there.

Legal Pages

At a minimum, you need:

• A Privacy Policy
• Terms of Service (if you’re collecting payments, signups, or user data)
• A cookie notice (required across the EU, UK, and a growing number of other regions)

Free generators like getterms.io or Termly are fine for simple sites. If you’re handling sensitive data or running a regulated business, pay a lawyer.

Footer, 404 Page, and Favicons

Your footer needs a copyright line, real contact info, and working social links. Your 404 page should point people back to something useful — not leave them staring at a dead end. And your favicons should include retina and device-specific sizes, not just a blurry 16×16 that looks like it’s from 2012.

Print Stylesheet and Author Attribution

For long-form content, a print stylesheet is the kind of small touch readers notice without knowing why. Blog posts and articles also need correct author attribution — both visible on the page and baked into the metadata.

How to Use This Checklist

A few ground rules before you start. Work through the sections in order, because they build on each other and there’s no point running a performance audit on a site that still has placeholder copy in the hero section. Do a full pass on staging first, since production is never the place to debug. On team projects, split the work. Hand SEO to one person, accessibility to another, performance to a third. Things move faster that way, and fewer items slip past everyone at once.

Keep a known-issues log as you go. Some items will ship anyway, and that’s fine, but write them down so they don’t quietly disappear the day after launch.

Now to the checks.

1. Content and Copy

This is the layer visitors see first, which means it’s also the layer stakeholders notice first. A broken animation usually gets forgiven, but a typo in the headline doesn’t.

Proofreading and Placeholder Removal

Read every page out loud. It feels silly, but it catches what your eyes skim past, clunky phrasing, missing words, sentences that trail off. Then search the codebase for “Lorem ipsum,” “TODO,” “FIXME,” and whatever default strings your CMS leaves behind. Check image alt text too. Placeholders hide there, and nobody thinks to look.

Legal Pages

At a minimum, you need three: a Privacy Policy, Terms of Service if you’re collecting payments or signups or any kind of user data, and a cookie notice, which is required across the EU, UK, and a growing list of other regions. Free generators like getterms.io or Termly work fine for a marketing site, but for anything handling sensitive data or running in a regulated industry, pay a lawyer. The cost is small next to the fine.

Footer, 404 Page, and Favicons

The footer is easy to phone in, but three things need to be right: a copyright line, real contact info, and working social links. Click every one before launch. The 404 page is where people land when something breaks, so give them a way out, a search bar, a link home, a few popular pages, instead of a dead-end “ERROR” screen. And favicons get noticed when they’re wrong, so ship retina and device-specific sizes, not a blurry 16×16 from 2012.

Print Stylesheet and Author Attribution

Nobody prints websites often, but when they do, usually a recipe, a boarding pass, or a long article, a print stylesheet is the difference between a clean page and fourteen pages of navigation and sidebar clutter. For blog posts, get author attribution right in two places: visible on the page for readers, and in the metadata for Google. One builds trust, the other feeds search results.

2. SEO Foundations

Google needs to find the site, make sense of it, and decide where to rank it. Skip this section and your launch-day traffic never arrives.

Page Titles and Meta Descriptions

Every page gets its own title tag, kept under 60 characters so search results don’t chop it off mid-sentence. Meta descriptions run 150 to 160 characters and should read like an ad, a reason to click, not a dry summary of what’s on the page. Titles like “Home” or “Page 2” are the fastest way to tell the world nobody bothered to check.

Heading Hierarchy

One H1 per page. H2s for main sections. H3s for subsections. Don’t skip levels. Screen readers and search engines both depend on this structure, and both get confused when it’s broken.

Sitemap, Robots.txt, and 301 Redirects

Three files that tell search engines how to navigate your site. The XML sitemap at /sitemap.xml lists every page you want Google to find. The robots.txt file sits at the root and tells crawlers what they can access, plus where to find the sitemap. And if you’re replacing an old site, 301 redirects point each old URL to its new home, passing the SEO value along with it.

That last step is the one most teams skip, and it’s the one that hurts rankings most when it goes wrong. Every old URL turns into a 404, and years of SEO work disappear overnight.

Removing Staging Noindex Tags

Staging sites carry a <meta name=”robots” content=”noindex, nofollow”> tag so Google doesn’t index them by accident. That tag has to come off in production. Don’t trust the build system to handle it, view source on the live page and confirm it’s actually gone.

3. Analytics and Tracking

If you’re not measuring what happens after launch, you can’t improve any of it. This is the part everyone plans to set up properly and then somehow doesn’t.

Google Analytics 4 Setup

Install GA4 through Google Tag Manager when you can. A few extra minutes now saves hours later when you’re adding new tags. Once it’s live, check that data is flowing within 24 hours. A quiet dashboard on day one usually means something didn’t wire up right.

Search Console Verification

Verify the domain in Google Search Console and submit your sitemap. Turn on email alerts for coverage issues and manual actions, so Google tells you when something breaks instead of you spotting it weeks later in a traffic drop.

Conversion Events and Marketing Pixels

Tag the actions that matter to the business: form submissions, purchases, signups, and demo requests. Pageviews alone don’t pay the bills. If you’re running paid ads, add the Meta Pixel, LinkedIn Insight Tag, or whatever platforms you’re on, and double-check the event IDs. A pixel firing the wrong event is worse than no pixel at all.

Cookie Consent and Compliance

GDPR, CCPA, and the growing list of similar laws all say the same thing: tracking scripts wait for consent before firing. A banner that loads everything regardless of what the visitor clicks isn’t compliance; it’s a liability with a friendlier skin on top.

4. Social and Sharing

When someone drops a link to the site in Slack, LinkedIn, or a group chat, what shows up in the preview?

• Open Graph tags for Facebook, LinkedIn, Slack, and most messaging apps
• Twitter Card tags for X
• Share images at the right sizes — 1200×630 is the safe default
• Social profile links pointing to real, active accounts, not placeholders

Test the share previews on the actual platforms. Facebook’s Sharing Debugger and LinkedIn’s Post Inspector both help.

5. Code Quality and Markup

Clean code isn’t about chasing perfection. It’s about shipping something that won’t quietly fall apart six months from now.

• Run HTML through validator.w3.org
• Run CSS through jigsaw.w3.org/css-validator
• Open the JavaScript console — zero errors on load
• Click through internal and external links and confirm they resolve
• Minify and bundle CSS and JS in production

Document known issues instead of pretending they don’t exist. “This validator warning is safe to ignore because X” is a perfectly good answer.

6. Accessibility (WCAG)

Treat this section as non-negotiable. Accessibility is a legal requirement in many regions, a real SEO signal, and — more importantly — the right thing to do.

Semantic HTML and ARIA Landmarks

Use <nav>, <main>, <header>, <footer>, and <article>. Add ARIA roles only where native HTML doesn’t cover the job.

Keyboard Navigation and Focus States

Tab through the entire site. Every interactive element has to be reachable, and every focused element has to have a visible outline. If you stripped the default focus styles with CSS, put them back — differently if you want, but put them back.

ALT Text and Form Labels

• Meaningful images get alt text that describes the purpose, not just the picture
• Decorative images get alt=””
• Every form input has a <label> tied to it with a for and an id

Color Contrast and Testing Tools

WCAG AA asks for 4.5:1 contrast on normal text and 3:1 on large text. Scan every page with WAVE, axe DevTools, or Lighthouse.

Graceful No-JavaScript Fallback

Core content and navigation should still work with JavaScript disabled. Progressive enhancement has been the right model for twenty years, and it hasn’t aged.

7. Cross-Device Testing

IE9–11 are retired as of 2026. Focus on what real visitors actually use.

Desktop

• Chrome, Firefox, Safari, Edge — current and previous stable versions
• Windows and macOS

Mobile

• iOS Safari and Chrome
• Android Chrome and the stock browser

Tablet and large resolutions

• iPad portrait and landscape
• Android tablets
• 1440p, 4K, and ultrawide monitors

BrowserStack and Sauce Labs handle the combinations you can’t test locally.

8. Functionality Testing

Every interactive thing on the site needs to actually do its job.

• Form submissions land in the right inbox or database
• Required fields and input limits trigger the validation you expect
• Confirmation pages or thank-you events fire after submission so you can track them
• Site search returns relevant results — test it with real queries, not just “test.”
• Third-party integrations (chat, newsletter, booking) work end-to-end with real accounts

A form that silently sends to a dev inbox nobody checks is one of the most expensive bugs a launch can ship. You won’t notice until a client asks why nobody replied to their enquiry last week.

9. Performance Optimization

Slow sites lose visitors, and Core Web Vitals are a ranking factor. Here’s what to work through.

• Compress images and serve WebP or AVIF with fallbacks
• Minify and bundle CSS and JS
• Turn on Gzip or Brotli compression at the server
• Load only the font weights and character sets you use, with font-display: swap
• Run Lighthouse and PageSpeed Insights, record a baseline, fix anything critical
• Put Cloudflare, Fastly, or a similar CDN in front, with sensible cache headers

Aim for a Lighthouse Performance score above 85 on mobile. Below 50 and something is seriously wrong — usually an unoptimized image or a render-blocking script.

10. Security

Security is easier to build in on day one than to retrofit after something goes wrong.

• SSL certificate installed, HTTPS forced with 301 redirects
• Admin URLs changed from the defaults (/wp-admin, /admin, /login)
• Default usernames like “admin” removed
• Staging environments locked behind a password or IP restriction
• Security headers in place — CSP, HSTS, X-Frame-Options, X-Content-Type-Options
• Backups and rollback plan tested, not just configured

Before launch, scan the site with securityheaders.com and ssllabs.com. Aim for an A on both.

11. Launch Day

The actual moment of going live. Keep it short and boring — boring is the goal.

1. Flip DNS or deploy to production during a low-traffic window
2. Check that SSL resolves cleanly on the live domain, with no mixed-content warnings
3. Remove noindex from production
4. Smoke-test the top five pages and every form

Don’t push any other changes on launch day. If something breaks, you want to know exactly which deployment caused it.

12. Post-Launch Checks (First 48 Hours)

Launch isn’t the finish line. The first two days are when most problems surface.

• Submit the sitemap to Google Search Console
• Confirm analytics is receiving live traffic
• Search the live site for staging URL leaks — hardcoded links to staging domains hiding in images, CSS, or content
• Monitor error logs for 500s, 404s, and JavaScript exceptions
• Watch Core Web Vitals in Search Console for real-user performance data
• Announce the launch on social, email, and anywhere else your audience lives

Check back at the 24-hour and 48-hour marks. Fix whatever the data surfaces.

Common Mistakes to Avoid

Launches that go wrong tend to fail in the same five ways.

• The noindex that stayed on. Zero organic traffic for a month before anyone thinks to look.
• Test submissions going to a dev inbox. Leads pile up in a Slack channel nobody reads anymore.
• Placeholder images in production. Stock photos with watermarks. Grey “Image coming soon” tiles in the hero.
• Missing SSL on subdomains. www.site.com loads fine. site.com throws a browser warning and kills trust in two seconds.
• Forgotten 301 redirects. Every URL Google had indexed from the old site now returns a 404.

Each one is preventable with a checklist.

Wrapping Up

A website launch isn’t a moment. It’s a process, and treating it like a checklist instead of a finish line is what separates the calm launches from the painful ones.

Work through this guide once, and you’ll start spotting the patterns. Work through it ten times, and it becomes muscle memory — the panic-filled launch day you used to dread turns into a quiet two-hour pass on staging, and then you ship.

Bookmark this page. Come back to it on your next launch.

Download the full checklist as a PDF to print, hand to your team, or drop into your project management tool.

Planning a new site or a replatform? technext.it handles website launches end-to-end — from the first wireframe through to the 48-hour post-launch review. Get in touch if you want a team that already treats this checklist as the starting line, not the goal.