Website Launch Checklist: 52 Items – 2026

Launching a website feels a lot like opening the doors of a brand new shop on a busy high street. If the shelves are half-stocked and the card reader does not work, the first customers who walk in will leave and probably never come back. The same thing happens online. A missing SSL certificate, a broken navigation link, or a forgotten robots.txt file can undo weeks of development work in seconds. That is exactly why pressing the “publish” button without a thorough website launch checklist is a gamble most businesses cannot afford to take. Over the years, managing dozens of web projects for companies across the UK and US, I have catalogued the most common mistakes, the frequently missed details, and the “we really should have caught that” moments into a single reference document. Fifty-two items. Eight categories. Every one of them pulled from real launches, real failures, and real fixes.

You do not need to read this list from top to bottom in a single sitting. Jump to the category that matches where you are in the project, and tick items off as you complete them. One piece of advice though: open this checklist at least 48 hours before your scheduled launch. The things that slip through during last-minute reviews are always the ones that matter most.

Technical Infrastructure (Items 1-8)

This is where the foundation of your website gets built. Hosting choice, domain configuration, server settings.. these are the invisible decisions that determine everything about your site’s future. Whether a site will be fast or slow, stable or crash-prone, scalable or boxed in, it all gets decided at this layer. Skipping this section is like pouring a concrete floor without checking the ground underneath it.

1. Is the hosting plan confirmed and the server location correct?

If your target audience is in the UK, your server should sit in London or at least within Western Europe (Frankfurt, Amsterdam). Targeting the US? Go with a data centre on the East or West Coast, depending on where your customers cluster. Picking a server on the wrong continent and assuming “we will just use a CDN” is a common trap. A CDN (Content Delivery Network) speeds up static files, but database queries still travel back to the origin server. Are you starting on shared hosting, using a VPS (Virtual Private Server), or going with managed WordPress hosting? Let your traffic expectations guide that decision. Running an ecommerce site that expects 50,000 monthly visitors on a shared hosting plan is like opening a supermarket with a single till.

2. Are domain redirects and DNS records configured?

Pick one canonical version of your domain, either www or non-www, and set up a 301 redirect from the other. DNS propagation can take 24 to 48 hours, so do not leave this until launch day. Check your MX records (for email), CNAME records, and A records. If you are working with an existing domain, test every current redirect individually to confirm nothing has broken. A single misconfigured DNS record can knock your email offline, and you might not notice until a client tells you their messages are bouncing.

3. Is the SSL certificate active and properly configured?

In 2026, launching without SSL is practically impossible; browsers flag unencrypted sites with a “Not Secure” warning that sends visitors running. But just installing a certificate is not enough. Check for mixed content issues, where a page loads over HTTPS but pulls in a single image or script over HTTP. That one HTTP resource breaks the padlock icon in the browser bar. Choose the right certificate type for your project: DV (Domain Validation) works fine for a standard corporate site, while an EV (Extended Validation) certificate adds an extra layer of trust for ecommerce stores handling card payments in GBP or USD.

4. Are staging and production environments separated?

Editing a live website is the digital equivalent of rewiring a house while people are living in it. A staging environment lets you test changes before pushing them to production. If your hosting panel offers a one-click staging feature, use it. If it does not, set up at least a local development environment with a tool like LocalWP or DDEV. The few minutes it takes to create a staging site will save hours of panicked debugging when something breaks on the live site at 2 AM.

5. Is your server-side language running a current version?

If you use WordPress, you need PHP 8.2 or higher. Older PHP versions create security vulnerabilities and drag down performance. Upgrading from PHP 7.4 to 8.2 alone can cut page load times by 15 to 20 percent. Before upgrading, check plugin compatibility. Some older plugins clash with newer PHP versions, throwing fatal errors that take the entire site down. The same principle applies to Node.js, Python, or whatever stack your site runs on: outdated runtimes are both slower and less secure.

6. Has the database been optimised?

During development, databases accumulate junk: unnecessary post revisions, spam comments, expired transient data, orphaned metadata. All of it bloats the database and slows down queries. Clean it up before going live. On WordPress, tools like WP-Optimize handle this with a few clicks. Pay special attention to the wp_options table. If it is loaded with autoloaded entries from deactivated plugins, your page load time will suffer noticeably. A healthy wp_options table should have fewer than 500 autoloaded rows in most cases.

7. Are cron jobs and scheduled tasks configured?

Does your site need tasks to run automatically? Backups, transactional emails, stock updates, cache clearing – all of these rely on scheduled jobs. WordPress has its own wp-cron system, but it only fires when someone visits the site, which makes it unreliable for time-sensitive tasks. Set up a real server-side cron job instead. On most hosting panels, this takes less than five minutes. If you are using a managed host like Kinsta or WP Engine, check whether they already handle this for you.

8. Are error pages and server response codes correct?

When someone visits a page that does not exist, does the server return a 404 status code, or does it serve the page with a 200? A soft 404, where the server says “everything is fine” while showing a “page not found” message, confuses search engines and wastes your crawl budget. Similarly, check that 301 and 302 redirects are behaving as intended. Use a tool like Screaming Frog to crawl the site and flag any unexpected response codes before launch.

Design and User Experience (Items 9-17)

Once the technical foundation is solid, the focus shifts to the layer that visitors actually see and touch. Design is not just about looking good. It is about usability. If a visitor cannot find what they need within three seconds, the design has failed, no matter how polished the colour palette looks. The items below cover everything from mobile responsiveness to accessibility, and each one has a measurable impact on bounce rates, session duration, and conversions.

9. Has mobile responsiveness been tested on every page?

In the UK, roughly 60 percent of web traffic comes from mobile devices. In the US, the number hovers around 55 percent. Mobile compatibility is not optional; it is the baseline. Testing only the homepage is not enough. Check inner pages, blog posts, form pages, the 404 page, the privacy policy, everything. Chrome DevTools device emulation is a decent starting point, but always test on a real phone as well. The emulator does not replicate touch interactions, scroll momentum, or the way iOS Safari handles fixed-position elements differently from Chrome on Android.

10. Is the navigation menu clear and functional?

Does every link in the main menu work? Do dropdown menus open correctly on mobile without overlapping content? Keep top-level menu items to seven or fewer. If you need more, switch to a sub-menu or mega menu structure. A visitor should be able to reach the homepage or any critical page from anywhere on the site in two clicks at most. Test the hamburger menu on mobile thoroughly. It is one of the most common sources of usability complaints, often because the close button sits too close to other tappable elements.

11. Do forms work and validate input correctly?

Contact forms, registration forms, newsletter sign-ups, quote request forms. Test all of them with real data. Does the email actually arrive? Are error messages clear and specific, or do they just say “invalid input” without explaining what went wrong? When someone submits an empty form, does validation kick in? What does the user see after a successful submission: a thank-you page, a confirmation message, nothing at all? These details seem minor, but they directly affect your conversion rate. A form that works but feels broken will cost you leads.

12. Has the 404 page been customised?

The default 404 page is the fastest way to lose a visitor. A custom 404 page should include links to the homepage and your most popular pages, a search box, and a friendly message that acknowledges the error without being patronising. Good 404 pages also include a way for the user to report the broken link. The cost of designing a proper 404 page is practically zero. The cost of losing every visitor who hits a dead link is considerably higher.

13. Have typography and font loading been optimised?

If you use Google Fonts, load only the weights you actually need. I regularly see sites loading Roboto in Light, Regular, Medium, Bold, and Black, while the design only uses Regular and Bold. Every extra font file adds to the page load time. Add the font-display: swap declaration to prevent FOIT (Flash of Invisible Text), the issue where text remains invisible until the custom font finishes loading. For UK and US audiences on fast broadband connections, this might seem trivial, but on a 4G mobile connection on the underground or in a rural area, it makes a real difference.

14. Do images have proper alt text and appropriate dimensions?

Every image should have a meaningful alt attribute. “IMG_2847.jpg” or “image1” are losses for both accessibility and SEO. Image dimensions matter too: uploading a 4000×3000 pixel photo straight from a camera will destroy your page speed. Resize images to their display dimensions, compress them, and serve them in WebP format. For hero images above the fold, consider using the <picture> element to serve different sizes for different viewports. A 1200px-wide hero image on a 375px phone screen wastes bandwidth that the visitor is paying for.

15. Are CTA buttons prominent and tappable?

What is the purpose of your site? What action do you want visitors to take? The answer should be reflected in your call-to-action buttons. Buttons should stand out from the rest of the page through colour and size contrast. On mobile, maintain a minimum tap target of 44×44 pixels, which is Apple’s guideline and Google’s recommendation. Replace generic labels like “Learn More” with specific action phrases that tell the visitor exactly what will happen when they click.

16. Have accessibility standards been met?

WCAG (Web Content Accessibility Guidelines) 2.2 Level AA should be your minimum target. Is the colour contrast ratio sufficient? Can a user navigate the entire site using only a keyboard? Does a screen reader interpret the page structure correctly? In the UK, the Equality Act 2010 requires websites to be accessible to people with disabilities, and enforcement has increased in recent years. In the US, ADA (Americans with Disabilities Act) compliance lawsuits have surged, with over 4,000 web accessibility cases filed in 2025 alone. Beyond legal requirements, accessible sites perform better in search rankings because search engine optimisation and accessibility share many of the same principles.

17. Are the favicon and browser tab details configured?

Small detail, big impression. A site without a favicon shows the generic blank page icon in the browser tab. That signals “unfinished” to anyone who notices, and more people notice than you might think. Create a 32×32 pixel favicon along with an Apple Touch Icon (180×180) and an Android manifest.json file. When someone has twenty tabs open, your favicon is how they find your site. Spend fifteen minutes on this. It is one of the highest-return tasks on the entire list.

Content (Items 18-25)

Content is the heart of any website. The technical infrastructure can be bulletproof and the design can look stunning, but at the end of the day, a visitor is reading text, looking at images, and watching videos. If the content is incomplete, outdated, or riddled with errors, the site feels half-finished regardless of how well everything else works.

18. Is all page copy finalised?

“Lorem ipsum” or “text goes here” placeholders should never appear on a live site. This sounds obvious, but under deadline pressure, it happens far more often than anyone wants to admit. Open every single page, read every paragraph, and do not forget the small print in the footer. Check the copyright year. Check the company name. Check that the telephone number in the header matches the one on the contact page. I once saw a site go live with placeholder text on the About page that read “insert founder story.” It stayed up for two weeks before anyone noticed.

19. Have spelling and grammar errors been corrected?

Spelling mistakes on a professional website undermine credibility instantly. Tools like Grammarly, LanguageTool, or the built-in spell checker in Google Docs catch the obvious errors, but no automated tool replaces a second pair of human eyes. Have someone other than the original writer proofread all copy. Common issues for UK/US audiences include inconsistent spelling conventions (colour vs.color, optimise vs. optimize). Pick one standard and stick to it throughout the site. If your audience is primarily British, use British English. If it is American, use American English. Do not mix them.

20. Are legal pages ready?

Privacy policy, cookie policy, terms of service, acceptable use policy. In the UK, the Data Protection Act 2018 (which incorporates UK GDPR) requires a privacy policy that explains how you collect, store, and use personal data. In the US, requirements vary by state, but the CCPA (California Consumer Privacy Act) applies if you serve California residents. Ecommerce sites also need returns policies, shipping information, and terms and conditions for purchases. Get these pages reviewed by a solicitor or attorney. Templates copied from the internet rarely cover the specifics of your business and offer weak legal protection. Budget between $200 and $500 (or around £150 to £400) for a professional legal review. That is a fraction of what a data protection fine would cost.

21. Does the cookie consent banner work properly?

UK GDPR and the Privacy and Electronic Communications Regulations (PECR) require clear cookie consent. The banner should not just have an “Accept All” button; it must offer a genuine way to decline or manage preferences. Google Analytics should not fire until consent has been granted. If you have implemented Google Consent Mode v2, test that it sends the correct consent signals. Use a tool like CookieYes or Cookiebot to manage compliance. Check that the banner appears for first-time visitors, remembers returning visitors’ choices, and does not block critical page content on mobile screens.

22. Are contact details accurate and up to date?

Phone number, email address, physical address, social media links. If any of these are wrong or outdated, visitor trust drops immediately. Does clicking the phone number initiate a call on mobile? Does the email link open the user’s mail client? Does the embedded map show the correct location? For businesses with a Google Business Profile, the address on your website must match the one in your listing. Inconsistencies between your site and directory listings confuse search engines and can hurt your local SEO rankings.

23. Do all images and media files load correctly?

Are images displaying properly on every page? Are there any broken image links? Do embedded videos play? Do images overflow the screen on mobile? Test across different device and browser combinations. Pay particular attention to images inside blog posts and product pages, where content editors often upload images without checking dimensions. If images look blurry on Retina displays, consider serving 2x resolution alternatives using the srcset attribute. A blurry product image on an ecommerce site can kill a sale faster than a slow checkout flow.

24. Have copyright and licensing requirements been verified?

Does every image, font, and software component on the site have a valid licence? Confirm that stock photos carry commercial-use licences. Google Fonts are free and open source, but premium typefaces require purchased licences. Icon libraries like Font Awesome have free tiers, but some icons sit behind paid plans. Copyright infringement claims are rising in both the UK and the US. A font licence that costs $50 is a lot cheaper than a $5,000 settlement letter from a licensing enforcement company, and those letters arrive more often than most people realise.

25. Is the blog or news section set up?

If content marketing is part of your strategy, the blog infrastructure needs to be ready before launch. Category structure, tag system, author profiles, related posts section, social sharing buttons. Publish at least three to five blog posts before going live. An empty blog page looks like an abandoned shop window. Those initial posts also give search engines something to index from day one and provide content for your launch announcement on social media.

SEO (Items 26-34)

Is your site ready for search engines? Fixing SEO issues after launch is like building a house and then trying to pour the foundation underneath it. Address as much as possible before the site goes live, because the first impression your site makes on Google’s crawlers sets the tone for months of indexing behaviour.

26. Does every page have a unique title tag and meta description?

Title tags should be 50 to 60 characters. Meta descriptions should sit between 120 and 155 characters. Both must be unique for every page. If every page shares the same title, Google will treat the site as poorly structured, which it is. Place your primary keyword near the beginning of the title. The meta description is not a direct ranking factor, but it directly affects click-through rate from search results. Write it like ad copy: specific, benefit-driven, and honest about what the page contains.

27. Is the URL structure clean and meaningful?

URLs should be short, descriptive, and human-readable. “yourcompany.com/services/website/” is a good URL. “yourcompany.com/?p=1247” is a bad one. In WordPress, set the permalink structure to “Post Name.” Avoid unnecessary folder depth; keep URLs to three or four segments at most. Remove stop words where possible (“and,” “the,” “of”) but keep the URL readable. A clean URL structure helps both users and search engines understand what a page is about before they even visit it.

28. Has an XML sitemap been created and submitted to Google?

An XML sitemap tells search engines which pages exist on your site and how they are structured. Plugins like Yoast SEO and Rank Math generate these automatically, but before launch, verify that the sitemap lists the correct pages. Draft pages, archive pages, and thin content pages should be excluded. Submit the sitemap to Google Search Console and Bing Webmaster Tools. Check it again a week after launch to confirm that the pages you want indexed are actually being picked up.

29. Is the robots.txt file configured correctly?

This is one of the most frequently missed items during the transition from development to production. During development, it is common practice to add “Disallow: /” to robots.txt to prevent search engines from indexing an unfinished site. If you forget to remove that line before launch, Google will not index your site and you will not appear in any search results. This is not a hypothetical scenario. I have personally seen an ecommerce site disappear from Google for three weeks because nobody checked the robots.txt file before going live. One line of text, three weeks of lost revenue. Always verify this file.

30. Are canonical tags correctly placed?

The same content can sometimes be accessible through multiple URLs. URL parameters, filters, sorting options, and pagination can all generate dozens of duplicate pages. A canonical tag tells search engines “the definitive version of this page lives at this URL.” Every page should have a self-referencing canonical tag, or one that points to the preferred version. Without canonical tags, search engines have to guess which version to index, and they do not always guess correctly. This leads to diluted domain authority and unpredictable ranking behaviour.

31. Is the heading hierarchy used correctly?

Each page should have one H1, followed by H2s and H3s in a logical order. Jumping from H1 directly to H4 breaks the hierarchy and confuses both screen readers and search engine crawlers. A common mistake is wrapping the site logo in an H1 tag on every page. Every page, including the homepage, needs its own unique H1 that clearly describes the page’s content. Think of headings as a document outline. If you removed all the body text and only the headings remained, would the structure of the page still make sense?

32. Has schema markup (structured data) been added?

Organization, LocalBusiness, BreadcrumbList, FAQPage, and Product are among the most useful schema markup types. Structured data helps your pages appear as rich snippets in search results, which increases visibility and click-through rates. Use Google’s Rich Results Test to verify that your schema is valid. Incorrect schema can be worse than no schema at all, because Google may interpret it as a spam signal. At minimum, add Organization schema to your homepage and BreadcrumbList schema to every page with breadcrumb navigation.

33. Has the internal linking structure been established?

Pages should link to each other in a meaningful way. Orphan pages, pages that receive no internal links from anywhere on the site, tend to be treated as unimportant by search engines. Make sure your most important pages are accessible from the main menu, footer, or sidebar. Create natural cross-links between blog posts and service pages. Internal links guide both users and crawlers through your site, and they distribute link equity across your pages. A well-planned internal linking structure can do more for your rankings than most off-page SEO tactics.

34. Have Open Graph and Twitter Card meta tags been added?

These tags control how your pages look when someone shares them on social media. If og:title, og:description, and og:image are not defined, the platform will pull whatever it can find, and the result usually looks broken or unappealing. Image dimensions should be 1200×630 pixels for Facebook and LinkedIn, and 1200×600 for Twitter (now X). Every page should ideally have its own Open Graph image. At minimum, set a default OG image so no share ever goes out with a blank preview.

Security (Items 35-40)

Hacking a website is easier than most site owners assume. WordPress sites are among the most targeted platforms globally because their popularity makes them a high-value target for automated attacks. Security investment needs to happen before a breach, not after. The cost of prevention is always a fraction of the cost of recovery, both in money and in reputation.

35. Is an automated backup system in place?

Automatic backups are non-negotiable. Daily database backups and weekly full-site backups should be the minimum standard. Backups must not be stored only on the same server as the site. Send copies to an external storage service like Amazon S3, Google Cloud Storage, or even a dedicated Google Drive folder. Run a restore test at least once before launch. Discovering that your backup file is corrupted when you actually need it is the worst possible timing. Budget around $5 to $20 per month (roughly £4 to £16) for reliable backup storage. It is some of the cheapest insurance you will ever buy.

36. Is a security plugin or WAF (Web Application Firewall) active?

For WordPress, tools like Wordfence, Sucuri, or Solid Security provide protection against brute force attacks, SQL injection, and XSS (cross-site scripting). A CDN and security layer like Cloudflare adds DDoS (Distributed Denial of Service) protection as a front line of defence. Configure the firewall rules before launch, not after the first attack. Most WAF providers offer a free tier that covers the basics, with paid plans starting around $10/month (about £8/month) for more advanced features like real-time IP blacklisting and malware scanning.

37. Has the default admin username been changed?

Sites that use “admin” as a username are the easiest targets for brute force attacks, because the attacker already knows half of the login credentials. Change the username to something unique. Passwords should be at least 16 characters long and include a mix of uppercase letters, lowercase letters, numbers, and special characters. Two-factor authentication (2FA) should be mandatory for all admin accounts. Use an authenticator app rather than SMS, as SIM-swapping attacks have made SMS-based 2FA less reliable than it used to be.

38. Are WordPress core, plugins, and themes up to date?

The vast majority of WordPress security vulnerabilities come from outdated software. Update WordPress core, all plugins, and the active theme to their latest versions before launch. Deactivating unused plugins is not enough. Delete them completely. A deactivated plugin still has its files on the server, and vulnerabilities in those files can still be exploited. If a plugin has not been updated by its developer in over a year, find an alternative. Abandoned plugins are ticking time bombs.

39. Are file permissions set correctly?

On Linux servers, file permissions should be set to 644 for files and 755 for directories. The wp-config.php file, which contains your database credentials, should be set to 400 or 440. Anyone being able to read this file is a security disaster waiting to happen. Check . htaccess permissions as well. Incorrect file permissions are one of the most common vectors for WordPress exploits, and they are one of the easiest to fix.

40. Is the login page protected?

Changing the WordPress login URL from the default /wp-admin/ to a custom path is a simple but effective measure. Add login rate limiting so that after a set number of failed attempts, the IP address gets blocked. Add reCAPTCHA or a similar bot protection layer to the login form. These three steps together block roughly 95 percent of automated attack attempts. For sites that handle sensitive data or process payments, consider restricting admin access to specific IP addresses or requiring VPN access for backend login.

Performance (Items 41-45)

Page speed is a direct ranking factor in Google’s algorithm. But the real issue is not rankings. A slow site loses visitors, tanks conversion rates, and wastes advertising spend. If you are paying for Google Ads traffic and sending those clicks to a page that takes five seconds to load, you are burning money. Performance is not just a technical metric. It is a business outcome.

41. Are Core Web Vitals scores within target ranges?

Google’s Core Web Vitals consist of three metrics that measure real-world user experience:

For LCP (Largest Contentful Paint), optimising the hero image is usually the biggest lever. For INP (Interaction to Next Paint), reduce heavy JavaScript execution and defer non-critical scripts. For CLS (Cumulative Layout Shift), always define width and height attributes on images and embeds. A fast loading speed is not just a technical achievement. It is a direct signal to visitors that you respect their time.

42. Has a CDN been configured?

A CDN distributes your static files (images, CSS, JavaScript) across servers worldwide, serving them from the location closest to each visitor. Cloudflare’s free plan alone makes a noticeable difference. For UK audiences, Cloudflare has Points of Presence in London, Manchester, and Edinburgh. For the US, there are dozens of PoPs coast to coast. After setting up the CDN, configure caching rules properly. A misconfigured CDN can actually make performance worse by serving stale content or bypassing the cache entirely.

43. Are browser caching headers set?

Define Cache-Control and Expires headers for static files. Set CSS and JavaScript files to cache for one year, and images for six months to one year. When files change, use cache busting by appending a version number to the filename (e.g., style.v2.css or style.css?v=2). This means returning visitors do not re-download files that have not changed, which dramatically reduces load times for repeat visits. Check your headers using the Network tab in Chrome DevTools or a tool like GTmetrix.

44. Have CSS and JavaScript files been minified and combined?

Minification strips unnecessary whitespace, comments, and line breaks from code files. On its own, this typically reduces file sizes by 20 to 30 percent. If you have multiple CSS or JavaScript files, combining them into fewer files reduces the number of HTTP requests the browser needs to make. On WordPress, plugins like WP Rocket or Autoptimize handle this automatically. But proceed with caution: combining JavaScript files sometimes causes conflicts and breaks functionality. Always test every page after enabling minification and concatenation.

45. Have unused plugins and scripts been removed?

Are there plugins installed during development that never made it into the final site? Every active plugin loads additional CSS and JavaScript files, even on pages where those files are not needed. The difference between a WordPress site with 30 plugins and one with 12 is visible to the naked eye. Review your Google Tag Manager container as well: remove unused marketing pixels, deprecated analytics snippets, and test tags that were never meant to go live. Every unnecessary script is a drag on performance and a potential security risk.

Analytics and Tracking (Items 46-49)

You cannot manage what you do not measure. Rather than launching your site and wondering “how many people are visiting?” a week later, set up tracking from day one so you have data from the very first visitor. The difference between a site with analytics from launch and one that adds tracking two weeks later is two weeks of data you can never get back.

46. Has GA4 (Google Analytics 4) been installed and verified?

Setting up GA4 is not just about pasting a tracking code into the header. You need to configure events correctly. Page views, form submissions, button clicks, scroll depth, file downloads – verify that each event fires as expected. Use GA4’s DebugView to test in real time. Turn on Enhanced Measurement, but understand which events it tracks automatically so you do not create duplicates. If your site processes transactions, configure ecommerce events with proper data layer values so you can track revenue, not just traffic. Revenue data is where analytics stops being interesting and starts being useful.

47. Is Google Tag Manager configured correctly?

Google Tag Manager (GTM) lets you manage all tracking codes from a single dashboard. GA4, Google Ads conversion tags, Meta Pixel, LinkedIn Insight Tag, and any other marketing scripts should all be deployed through GTM rather than hardcoded into the site. Use GTM’s Preview mode to confirm that every tag fires on the correct trigger. If you run an ecommerce site, configure the Data Layer to pass transaction data, product information, and cart values. A properly set up GTM container saves hours of developer time whenever a new tracking requirement comes in.

48. Has the site been added to Google Search Console?

Search Console is a free tool that shows how Google sees your site. Verify your domain using DNS or HTML file verification. Submit your sitemap. Monitor the Index Coverage report from the first week. If there are errors in the transition to production, this is where you will spot them first. Use the URL Inspection tool to check that your most important pages have been indexed. Set up email alerts so you are notified immediately if Google detects a spike in crawl errors or a drop in indexed pages.

49. Are advertising pixels and conversion codes working?

If you plan to advertise on Google Ads, Meta (Facebook/Instagram), LinkedIn, or any other platform, install conversion tracking before launch. If conversion tracking is not working properly, you will have no way of knowing which campaigns, ad groups, or keywords are generating results, and you will be spending your budget blind. Use browser extensions like Meta Pixel Helper and Google Tag Assistant to verify that pixels fire correctly. Run test conversions and confirm that the data appears in each advertising platform’s dashboard. For Google Ads, verify that conversion values are being passed correctly, especially if you are tracking different values for different form types or products.

Final Checks (Items 50-52)

Everything looks good? These last three items tie together the work you have done across the other 49 items. They are your final quality gate before pressing the launch button.

50. Has cross-browser testing been completed?

Test in Chrome, Safari, Firefox, and Edge. Chrome dominates market share in both the UK and the US, but Safari has a significant share thanks to iPhone and Mac users, often accounting for 25 to 30 percent of a site’s mobile traffic. Each browser renders fonts slightly differently, handles CSS properties with varying levels of support, and executes JavaScript with different engines. Tools like BrowserStack or LambdaTest let you test across dozens of browser and device combinations without needing physical hardware. Pay particular attention to Safari on iOS, which has historically been the most likely browser to introduce unexpected layout issues.

51. Do social media sharing previews look correct?

Test your homepage and several inner pages using Facebook’s Sharing Debugger and Twitter’s Card Validator. Does the correct image, title, and description appear? On the first share, caching issues are common. Use the “Scrape Again” button in Facebook’s debugger to clear the cache. Test on LinkedIn using the Post Inspector as well. A broken or missing share preview does not just look unprofessional. It actively reduces the chance that people will click through, which means every social share of your site underperforms until you fix it.

52. Is the post-launch action plan ready?

Launching a website is not the finish line. It is the starting gun. Prepare a list of tasks for the first 48 hours: submit indexing requests in Google Search Console, announce the launch on social media, verify analytics data is flowing, and re-test all forms with real submissions. Do you have a system for reporting bugs? How will you collect feedback from early visitors? Will someone be monitoring uptime during the first week? These questions need answers before launch, not after the first complaint arrives. Schedule a review meeting for one week after launch to assess performance data, identify any issues that slipped through, and plan the next round of improvements.

Checklist Summary Table

For those who want to see all 52 items at a glance, here is how they break down by category, priority, and timing:

Building a website launch checklist might feel bureaucratic. But a single missed item can spiral into days of post-launch firefighting. Being invisible on Google for three weeks because nobody checked the robots.txt file. Chrome showing a “Not Secure” warning because the SSL certificate lapsed between staging and production. Losing potential customers because form validation was never tested with real data. Every one of these scenarios is real, and every one of them is preventable.

I would recommend transferring this list into a Google Sheets spreadsheet or a Notion board, assigning a responsible team member and a completion date to each item, and integrating it into your project management workflow. If you are working as a team, assign each category to a different person to speed up the process. For agencies managing multiple launches per quarter, turn this into a reusable template that gets pulled out at the start of every project.

One final point: this website launch checklist is not a one-time document. It should be reopened for every new site project, every major update, and every redesign. Web technologies change, Google’s expectations evolve, security threats take new forms, and browser standards shift. The checklist needs to keep pace. Review and update it at least twice a year, and add lessons learned from each completed project as new items. The list gets better every time you use it.

Frequently Asked Questions