Website Design Checklist: 50 Things Before You Launch

Launching a website without a systematic review is like publishing a book without proofreading — you will find the mistakes right after it goes live. This checklist covers every critical checkpoint across design, content, SEO, performance, security, and analytics. Work through each item before you flip the switch, and you will launch with confidence instead of regret.

Whether you are a business owner reviewing a new site your agency built, or a developer doing your own final QA pass, these 50 items represent the hard-won lessons of hundreds of real launches. Some take five minutes. Others require deeper technical work. All of them matter.

Design and Branding (Items 1–8)

Your visual presentation is the first thing visitors judge — often before they read a single word. These checks ensure your brand shows up correctly and consistently across every screen.

1. Logo Placement and Quality — Your logo belongs in the upper-left corner of every page (or centered on mobile), and it must be a high-resolution vector (SVG) or 2x PNG so it stays crisp on Retina and high-DPI displays. Click the logo on every page template to confirm it links back to the homepage. Check that it does not get clipped, distorted, or overwhelmed by surrounding elements.

2. Color Consistency — Open your brand style guide and verify that every hex code in the live CSS matches exactly. Browsers and monitors handle slight variations differently, and a button that renders as teal on your laptop can look seafoam green on a client's monitor. Use your browser's DevTools color picker on your primary buttons, headings, and backgrounds to cross-reference against the approved values.

3. Typography Hierarchy — Your heading levels (H1 through H4) should create a clear visual scale — each level noticeably smaller and lighter than the one above. Body copy needs to sit at least 16px with a line-height between 1.5 and 1.7 for comfortable reading. Load the site on your phone and check that no text is smaller than 14px without pinch-to-zoom required.

4. Responsive Design at All Breakpoints — Resize your browser from 320px wide (small phones) all the way to 2560px (large monitors) and watch for layouts that break, images that overflow, or text that stacks in unexpected ways. Do not just test the three standard breakpoints — drag the window edge continuously. Real user devices exist at every width, not just the ones your CSS targets.

5. Whitespace and Visual Breathing Room — Crowded pages create anxiety; whitespace creates trust. Check that sections have at least 60–80px of vertical padding, that body text lines are no wider than 70 characters, and that no two competing elements are fighting for attention simultaneously. If your eye does not know where to land first on any given page, the layout needs more space.

6. Visual Hierarchy and Focal Points — Every page should have one dominant visual element that anchors the eye — typically a large headline, a hero image, or a bold CTA. Verify that secondary elements support rather than compete with this focal point. A quick test: blur your screen slightly and see if the most important element still stands out. If it does not, adjust the size, weight, or contrast.

7. Brand Consistency Across Pages — Navigate through every unique page template and check that colors, fonts, icon styles, and photography treatments are unified. A site that looks like three different designers worked on it independently erodes trust. Pay special attention to interior pages, blog posts, and error pages — these often get styled inconsistently.

8. Favicon — The favicon is a small detail with disproportionate impact on credibility. Verify that a 32x32 PNG favicon displays correctly in browser tabs and that a 180x180 Apple touch icon exists for iOS home screen saves. Test by bookmarking the site and checking how it appears in your bookmarks bar. A missing or broken favicon is a visible signal that a launch was rushed.

Pro tip: The most common design oversight at launch is not a missing element — it is an inconsistency. Set up your style guide as a living document and have someone other than the designer do the visual QA. Fresh eyes catch inconsistencies that creators become blind to.

Content and Copy (Items 9–16)

Design draws people in; copy is what converts them. Every word on your site carries strategic weight. These checks ensure your content is clear, accurate, and positioned to build trust.

9. Headline Clarity — Your homepage H1 needs to answer "what do you do and who is it for?" within three seconds. Read it out loud to someone unfamiliar with your business. If they cannot tell what you sell without reading further, rewrite it. Jargon, clever wordplay, and brand taglines all fail this test when used as the primary headline.

10. Value Proposition — Below the headline, you need a supporting sentence or short paragraph that explains the specific benefit you deliver and why your approach is different. Check that this appears above the fold on desktop and within two scrolls on mobile. Vague statements like "we help businesses grow" do not qualify — be specific about what you actually do.

11. Calls to Action (CTAs) — Every page should have at least one clear CTA, and it should be visible without scrolling on desktop. Check that CTA button text is action-oriented ("Get Your Free Quote" is better than "Submit") and that clicking each CTA takes users exactly where they expect to go. Test all forms to confirm submissions route correctly and trigger appropriate confirmation messages.

12. Error-Free Copy — Run every page's text through a spell checker and then read it manually — spellcheckers miss homophones and grammatical errors. Pay special attention to the homepage, service pages, and any page where trust is being established. One "their/there" confusion or missing apostrophe on a pricing page can undermine the credibility you have built with your design.

13. Contact Information — Your phone number, email address, and physical address (if applicable) should appear in the header or footer of every page, not just the contact page. Check that phone numbers are click-to-call on mobile (wrapped in tel: links) and that your address, if present, matches your Google Business Profile exactly — character for character, including abbreviations.

14. Social Proof — Before launch, verify that testimonials, case studies, client logos, or review counts are real, current, and properly attributed. Outdated testimonials from three years ago can backfire if clients recognize them as stale. If you are using star ratings, confirm they pull from a live, verifiable source rather than being hardcoded numbers.

15. About Page — Check that your About page tells a genuine story rather than reciting corporate boilerplate. It should include real names, real faces, and a clear explanation of why you exist. Team photos need to load at the correct aspect ratio and resolution. If you link to LinkedIn profiles, verify those links open correctly and the profiles are up to date.

16. Privacy Policy and Terms of Service — These are legal requirements, not optional extras. If your site collects any data — through contact forms, cookies, or analytics — you need a privacy policy that discloses what you collect and how you use it. Verify the links to these documents appear in your footer and are accessible from any page. For US businesses collecting data from California residents, CCPA compliance is mandatory.

Pro tip: Read your entire site as if you are a skeptical prospective customer who has never heard of you. Note every moment where you felt confused, unconvinced, or unsure what to do next. These friction points are your highest-priority content edits.

Navigation and UX (Items 17–24)

A website that is hard to navigate will be abandoned, regardless of how good the design or content is. These checks cover the full user experience from entry to conversion.

17. Main Navigation Structure — Your main nav should have no more than seven items, and each label should be clear and predictable. Hover over every dropdown to check that sub-menus appear correctly and do not get cut off at the edge of the screen. On pages with long navigation, verify that the active page is visually highlighted so users always know where they are.

18. Mobile Menu — Open the site on an actual phone — not just a browser resized to mobile width — and test the hamburger menu. Verify it opens and closes correctly, that all links are tappable without precision tapping, and that the menu closes when you navigate to a new page. Test with both iOS Safari and Android Chrome, as they handle fixed positioning and overflow differently.

19. Breadcrumbs on Deep Pages — For any site with more than two levels of navigation, breadcrumbs are essential for both usability and SEO. Check that interior pages, blog posts, and product pages display breadcrumbs that accurately reflect the site hierarchy and that each breadcrumb link navigates correctly. This is often skipped on blog templates and service sub-pages.

20. Site Search — If your site has more than 20 pages or a content-heavy blog, search functionality is critical. Test your search with a misspelled query, a very short query (one letter), and a query with no results. Each edge case should return a helpful response rather than an error or empty page. Check that the search field is easily findable, especially on mobile.

21. Custom 404 Page — Navigate to a URL that does not exist (e.g., /doesnotexist) and verify that your 404 page loads, not a default server error page. A good 404 page acknowledges the problem, provides navigation back to main sections, and optionally offers a search field. Confirm the 404 page actually returns an HTTP 404 status code — not a 200 (which creates an SEO "soft 404" problem).

22. Loading States and Transitions — If any part of your site fetches data dynamically (forms, search, comments, live pricing), verify that a loading indicator appears while data is being fetched. Users who click a button and see nothing happen will click it again — often multiple times — leading to duplicate submissions or frustration. Skeleton screens are better than spinners for most cases.

23. Form Validation and Error Messages — Submit every form on the site with invalid data: an email address without the @ symbol, a phone field with letters, required fields left blank. Check that errors appear inline next to the problematic field (not just at the top of the form), that error messages explain what is wrong in plain language, and that valid fields do not get cleared when the form fails validation.

24. Scroll Behavior and Anchor Links — If your site uses smooth scrolling or anchor links in the navigation, test each one carefully. Common failures include anchor links that land slightly above the intended section (being hidden behind a sticky header), smooth scroll that does not work in Safari without a polyfill, and "back to top" buttons that do not appear until the user has scrolled a meaningful distance.

Pro tip: Record a real user navigating your site for the first time using a tool like Hotjar or Microsoft Clarity. Five minutes of observation from a real session reveals UX issues that no amount of developer testing will surface.

SEO Fundamentals (Items 25–32)

SEO is not magic — it is a checklist of technical requirements that search engines use to understand and rank your content. Miss any of these, and you are leaving organic visibility on the table from day one. At Spearlance, SEO fundamentals are built into every site we design rather than bolted on afterward, because retrofitting SEO to a poorly structured site is far more expensive than getting it right up front.

25. Title Tags — Every page needs a unique title tag between 50 and 60 characters that includes the primary keyword and your brand name. View the page source (Ctrl+U) and search for the <title> tag on each page type — homepage, service pages, blog posts, and landing pages. Duplicated or missing title tags are one of the most common and damaging SEO oversights at launch.

26. Meta Descriptions — While meta descriptions are not a direct ranking factor, they are your ad copy in search results and directly affect click-through rates. Every page should have a unique meta description between 150 and 160 characters that summarizes the page content and includes a soft call to action. Check them by viewing source or using a browser extension like SEO Meta in 1 Click.

27. Heading Hierarchy — Each page should have exactly one H1 tag (the primary headline), followed by H2s for main sections, and H3s for subsections. Run the developer tools element inspector on several pages and verify that headings are not being used for visual styling purposes — a common mistake where developers use H4 or H5 for smaller decorative text, breaking the semantic structure that search engines rely on.

28. Image Alt Text — Every image needs an alt attribute. Decorative images should have an empty alt (alt=""), and content images should have descriptive alt text that explains what is in the image and, where natural, includes the relevant keyword. Use browser DevTools to inspect image elements, or run the page through an accessibility checker like axe DevTools, which will flag missing alt attributes automatically.

29. XML Sitemap — Your sitemap.xml file must exist at the root of your domain (yourdomain.com/sitemap.xml) and include every indexable page. Verify it loads correctly, does not include redirect URLs, and is listed in your robots.txt file. Then submit it to Google Search Console. If your site generates its sitemap dynamically, test what happens when a new page is added — it should appear in the sitemap within 24 hours.

30. Robots.txt — Navigate to yourdomain.com/robots.txt and review every directive carefully. This file controls which pages search engines can crawl. Common disasters include accidentally disallowing / (which blocks your entire site), forgetting to include the sitemap URL, or leaving staging environment rules in place after going live. Every line of this file should be intentional.

31. Canonical URLs — Canonical tags tell search engines which version of a URL is the "official" one when multiple URLs serve similar content. Check that every page includes a self-referencing canonical tag, that pagination uses canonical tags correctly, and that your site does not serve both http:// and https:// versions, or both www. and non-www versions. All variants should redirect to one canonical version.

32. Structured Data (Schema Markup) — Schema markup helps search engines understand your content and enables rich results in search — star ratings, FAQ dropdowns, local business info, and more. Validate your structured data using Google's Rich Results Test. At minimum, a local business site should have LocalBusiness schema with accurate NAP (Name, Address, Phone) data. Blog posts should include Article schema with author and date information.

Pro tip: SEO audits done post-launch reveal problems that were always there — but now they are indexed with those problems. Run a crawl with Screaming Frog or Ahrefs Site Audit before launch and treat the critical issues as launch blockers, not nice-to-haves.

Performance and Speed (Items 33–38)

Page speed is both a ranking factor and a conversion factor. A one-second delay in page load time reduces conversions by 7%. These checks address the most impactful performance levers before your site goes live.

33. Image Optimization — Images are the single largest contributor to slow page loads on most websites. Check that every image is served in WebP or AVIF format (not JPEG or PNG), sized to the largest it will actually display (not scaled down in CSS), and compressed without visible quality loss. Run your homepage through Google PageSpeed Insights and look at the "Avoid serving images in legacy formats" and "Properly size images" diagnostics.

34. Code Minification and Bundling — Your production build should minify all JavaScript and CSS files, removing whitespace, comments, and long variable names. Most modern build tools (Vite, Next.js, Webpack) handle this automatically in production mode, but verify by viewing source and checking that your .js and .css files are minified. Also check that you are not loading multiple separate CSS or JS files that could be bundled together.

35. Lazy Loading for Below-the-Fold Content — Images and videos that appear below the fold should not load until the user scrolls toward them. Add loading="lazy" to all <img> tags except the hero image (which should load eagerly, as it is above the fold and affects Largest Contentful Paint). For iframes — especially YouTube embeds — use a facade or lazy-loading technique to prevent render-blocking.

36. CDN Configuration — If your site serves visitors from multiple geographic regions, a CDN (Content Delivery Network) ensures static assets are served from a server geographically close to each visitor. Verify your CDN is configured for images, CSS, JavaScript, and web fonts. Check that CDN cache headers are set with appropriate TTLs — at least one week for versioned assets. Test from a different city using a tool like WebPageTest.

37. Core Web Vitals — Google's Core Web Vitals are three specific performance metrics that directly affect your search ranking: LCP (Largest Contentful Paint, should be under 2.5 seconds), INP (Interaction to Next Paint, should be under 200ms), and CLS (Cumulative Layout Shift, should be under 0.1). Run your site through PageSpeed Insights and address every metric that falls in the "needs improvement" or "poor" range before launch.

38. Browser Caching — Returning visitors should load your site significantly faster than first-time visitors. Check your server response headers to confirm that static assets include a Cache-Control header with a max-age of at least one week (604800 seconds). For assets with fingerprinted filenames (which change when the file changes), you can safely set max-age to one year. Use the Network tab in DevTools to verify cached assets load from memory on subsequent page loads.

Pro tip: Run your site through WebPageTest with "Start Render" film strip view enabled. Watch frame-by-frame as your page loads. The first frame where your hero content is visible should come within 2 seconds on a standard 4G connection. If your site shows a white screen for more than 1.5 seconds, that is a user experience emergency that will hurt both conversions and SEO.

Security (Items 39–43)

Security is not optional, and the consequences of a breach — data loss, reputation damage, legal liability — far outweigh the cost of prevention. These five checks address the most critical security requirements for any production website.

39. SSL Certificate — Every page of your site must load over HTTPS. Navigate to the HTTP version of your homepage (http://yourdomain.com) and confirm it automatically redirects to HTTPS. Click the padlock in your browser's address bar and verify the certificate is valid, issued by a trusted authority, and does not expire within 30 days. Set up automatic renewal through your hosting provider or Let's Encrypt — expired SSL certificates take sites down without warning.

40. Server-Side Form Validation — Client-side validation (the kind that happens in the browser) is a user experience feature, not a security measure. It can be bypassed in seconds by anyone with basic technical knowledge. Every form submission must be validated again on the server before being processed, stored, or used to trigger any action. Verify that your backend rejects malformed submissions even when the request bypasses your frontend entirely.

41. XSS Prevention — Cross-Site Scripting (XSS) attacks inject malicious scripts into your pages through user-supplied content. Check that every location where user input is displayed — comment sections, search results, form confirmation pages — properly escapes HTML characters before rendering. If you use a modern framework like React, this is handled automatically for JSX expressions, but direct DOM manipulation using innerHTML bypasses this protection and should be avoided.

42. Dependency Audit — Run npm audit (or the equivalent for your package manager) and review every high and critical severity vulnerability. Third-party packages are one of the most common attack vectors in modern web applications. Update vulnerable packages before launch, and remove any packages you are not actually using — dead dependencies are security debt. Note: some vulnerabilities in devDependencies do not affect production, but high-severity vulnerabilities in production dependencies are launch blockers.

43. Backup Strategy — Before launch, verify that automated backups are configured for both your database and any uploaded files. You should be able to restore your site to a working state from 24 hours ago within 30 minutes. Test this by actually doing a restore to a staging environment — not just trusting that backups exist. Common failure modes include backups that run but write to the same disk as the data they are backing up, and backups that have never been tested for restoration.

Pro tip: Add your domain to a security monitoring service like Security Headers (securityheaders.com) before launch. It takes 30 seconds and will flag missing HTTP security headers like Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security — headers that cost nothing to add but prevent entire categories of attacks.

Analytics and Tracking (Items 44–48)

You cannot improve what you cannot measure. These tracking checks ensure that from your first visitor onward, you have the data to understand what is working and where users are dropping off. This is an area where Spearlance builds in proper tracking architecture from the start — because retroactively piecing together historical data after a failed launch is painful and often impossible.

44. Google Analytics 4 — Verify that your GA4 property is correctly installed and that data is flowing into the right property (not a test or old UA property). Open the GA4 Realtime report and navigate through several pages of your site — you should see your own sessions appear within 30 seconds. Confirm that page_view events fire for every page, that your measurement ID matches what is in your GA4 admin panel, and that you have not accidentally double-tagged the site (which inflates all metrics).

45. Google Search Console — Submit your sitemap to Google Search Console and verify property ownership before launch. This is the tool that tells you how Google sees your site — which pages are indexed, which have errors, and which search queries are driving traffic. Set it up before launch so the baseline data starts accumulating from day one. Check that your site is verified with a method that will survive future code changes (DNS verification is the most resilient).

46. Conversion Tracking — Define your conversions before launch and verify each one fires correctly. Common conversions include form submissions, phone clicks, email clicks, file downloads, video plays, and scroll depth. Test each conversion path manually while watching your analytics debug view to confirm the event fires with the correct parameters. Broken conversion tracking means you will not be able to calculate ROI from any future advertising spend.

47. Heatmaps and Session Recording — Tools like Microsoft Clarity or Hotjar record real user sessions and generate heatmaps showing where users click, how far they scroll, and where they rage-click in frustration. Install at least one of these before launch so you have behavioral data from real users from the first day. Clarity is free and respects privacy requirements — it is worth installing on every site regardless of budget. Verify the tracking code loads on all page types, not just the homepage.

48. Error Monitoring — JavaScript errors and server errors that users encounter never get reported back to you unless you have error monitoring in place. Tools like Sentry capture real errors in real sessions with stack traces, affected browsers, and user counts. Configure it to alert you when a new error affects more than 10 users in an hour. Without this, you will learn about breaking bugs from frustrated clients rather than from your own monitoring dashboard.

Pro tip: Create a launch-day analytics baseline document: record your Domain Authority, current indexed page count, and any existing traffic numbers before you switch the domain. Post-launch, the inevitable fluctuations in search visibility become impossible to contextualize without a documented baseline to compare against.

Pre-Launch Final Checks (Items 49–50)

These final two items are deliberately last — they require that everything else is already correct before they are meaningful. Do not attempt these until you have worked through the previous 48 items.

49. Cross-Browser and Cross-Device Testing — Your site must work correctly in Chrome, Safari, Firefox, and Edge at minimum. Do not assume that something working in Chrome means it works everywhere — Safari in particular has significant CSS quirks, especially around position: sticky, gap in flexbox on older iOS, and scroll behavior. Test on at least two real physical devices (an iPhone and an Android phone), not just browser emulators. Use BrowserStack or a similar service if you do not have access to enough physical devices. Specifically test: all forms, all navigation, all modals/drawers, hover states, and animations. Check that nothing is visually broken and no console errors appear on any browser.

50. DNS, Hosting, and Go-Live Checklist — The actual cutover from staging to production is the highest-risk moment of any launch. Before you change your DNS, confirm the following in order: your production environment has all necessary environment variables set (not just the ones that work on staging), your database connection strings point to production (not a shared staging database), email sending is configured with a production API key and a verified sending domain, all redirects from old URLs to new URLs are in place and tested, your CDN cache is cleared and pre-warmed, and your SSL certificate will auto-provision at the new domain. After changing DNS, set a reminder to check the site every hour for the first four hours — DNS propagation is not instant, and issues often surface during the propagation window when some users see the old site and some see the new one. Document the exact time your DNS change was made — this timestamp is critical context for interpreting any anomalies in your analytics data post-launch.

Pro tip: Do not launch on a Friday. Seriously — this is the most consistently violated piece of launch advice in the industry, and the consequences are always the same: something breaks over the weekend, the people who can fix it are unavailable, and Monday morning is a crisis instead of a celebration. Tuesday through Thursday morning launches give you a full business day to monitor and respond to issues before the weekend.

After the Launch

A completed checklist is a launch floor, not a finish line. The real work begins once real users arrive and real data starts flowing. Monitor your Core Web Vitals in Google Search Console over the first 28 days (the window CrUX uses for field data). Watch your error monitoring dashboard daily for the first two weeks. Run a fresh crawl through your SEO tool of choice after the first full indexation cycle to catch anything that slipped through pre-launch.

The sites that perform best six months after launch are not always the ones that launched perfectly — they are the ones where the team stayed disciplined about monitoring the data and acting on what it told them. Treat this checklist not as a one-time document but as a recurring quarterly audit. SEO requirements change, browser capabilities evolve, and dependencies accumulate new vulnerabilities. A site that was fully optimized at launch will drift if nobody checks.

Every item on this list represents a real problem that has caused real launches to fail. Work through it methodically, document what you find, and fix what is broken before you flip the switch. Your future self — the one who does not have to explain to a client why the contact form was broken for two weeks — will thank you.