# Website Checklist The complete, no-fluff checklist for launching and maintaining a website: SEO, performance, accessibility, security and more. # Website Checklist: The Complete Launch and SEO Guide The complete website checklist Whether you're launching your first site or your fiftieth, it's easy to miss something—a missing meta description, a robots.txt still set to Disallow: / , an SSL certificate nobody renewed. This is a practical, evergreen reference: twenty-five focused checklists covering everything from pre-launch content to post-launch maintenance, migrations, WordPress-specific gotchas, email deliverability and multilingual SEO—written for freelancers, agencies and small-business owners who want a working site, not a science project. 💡 Bookmark this page. Every checklist below is a standalone reference you can come back to at any stage of a project—before launch, on launch day, mid-migration, or six months in when something needs a refresh. Before you launch Pre-launch checklist Content, design and technical basics to confirm before you go live. Content checklist Planning, writing and structuring content that actually serves readers. On-page SEO checklist Titles, meta descriptions, headings, images and internal links. Technical SEO checklist Crawlability, indexing, structured data and site architecture. Search visibility & specialized SEO Structured data & schema checklist Choosing schema types, writing valid JSON-LD, and testing rich results. Local SEO checklist Google Business Profile, NAP consistency, citations and reviews. International & multilingual SEO hreflang, language targeting, translation quality and localized content. E-commerce checklist Product pages, checkout trust signals, and store-specific SEO. Speed, images & accessibility Performance & Core Web Vitals Speed, LCP, INP, CLS, and how to measure them. Image optimization checklist Formats, compression, responsive images and lazy loading, done right. Mobile & responsive checklist Responsive design, viewport, touch targets and mobile testing. Accessibility checklist Semantic HTML, contrast, keyboard access and screen readers. Security, privacy & email Security checklist HTTPS, headers, backups, updates and login protection. Privacy & cookie consent checklist GDPR/CCPA basics, cookie banners and privacy-by-design. Email deliverability checklist SPF, DKIM, DMARC and keeping transactional email out of spam. QA & cross-browser testing checklist A structured pass across browsers, devices and edge cases. Go live and convert Launch day checklist The final run-through, step by step, for go-live day. Analytics & tracking setup Search Console, analytics, tag management and privacy. Conversion & forms checklist Lead-capture forms, friction, trust signals and UX basics. Post-launch maintenance The ongoing routine that keeps a site healthy after launch. Special projects & reference Site migration & redesign checklist Replatforming or redesigning without losing rankings or traffic. WordPress checklist The platform-specific gotchas: updates, plugins, performance and security. Common mistakes The pitfalls that quietly sink otherwise-good launches. FAQ Quick answers to the questions we hear most. About this site What this resource is, and the standards behind it. How to use this site Each checklist is grouped into short, focused sections so you can jump straight to what you need—copy the relevant section into your own project-management tool, or just work top to bottom. None of it assumes a specific CMS, host or page builder; the principles apply whether you're hand-coding HTML or running the most popular website platform on the market. Where something is genuinely platform-specific—like the WordPress checklist —it's called out separately rather than mixed into the general advice. Start with the pre-launch checklist if you're planning a new site, the migration checklist if you're replatforming or redesigning an existing one, or jump to common mistakes if you want the fast version of what tends to go wrong. --- # Pre-Launch Checklist: What to Confirm Before Going Live Pre-launch checklist This is the master run-through for the weeks before launch—the point where content, design and technical setup all have to come together. Work through each section; nothing here is optional for a professional launch, though the depth you go into will vary by project size. If this is a redesign or replatform of an existing site rather than a brand-new one, read this alongside the site migration checklist , which covers the extra risk a migration adds on top of everything here. Content & copy Every page has final, proofread copy—no lorem ipsum or placeholder text left anywhere, including footers and legal pages Every page has a unique, descriptive tag and meta description (see the SEO checklist ) Contact information (phone, email, address) is accurate and consistent everywhere it appears All internal links point to the correct final URLs, not placeholder or staging links Spelling, grammar and tone have been checked by a second person, not just the writer Dates, prices, names and any factual claims have been double-checked for accuracy Placeholder testimonials, sample reviews or stock "team member" bios have been replaced with real content or removed Any downloadable files (PDFs, brochures, price lists) are the final versions and open correctly Design & branding The site is tested and looks correct on the major current browsers, not just the one the designer uses (see the QA & cross-browser checklist ) Layout, spacing and images look correct across desktop, tablet and mobile widths (see the mobile checklist ) Favicon, logo and brand colors are in place and consistent across every page and browser tab All images are final, properly cropped, and have descriptive alt text (see the accessibility checklist ) Broken or missing images have been checked for on every page, not just the homepage Print styles, if the site needs them (invoices, receipts, printable pages), have been checked in an actual print preview Domain, DNS & email The production domain is registered, pointed at the correct host, and DNS has had time to propagate before launch day MX records (and SPF/DKIM/DMARC records, if this domain also sends email) are correct and haven't been accidentally overwritten by a hosting migration—see the email deliverability checklist A www vs. non- www decision has been made and the non-preferred version redirects to the preferred one Domain registration and DNS management logins are documented and accessible to whoever needs them, not locked in one person's personal account Domain renewal is set to auto-renew, or a calendar reminder exists well ahead of the expiry date Technical setup HTTPS is active with a valid SSL/TLS certificate, and HTTP requests redirect to HTTPS (see the security checklist ) A custom, on-brand 404 error page exists and links back into the site robots.txt exists and is not accidentally blocking the whole site with Disallow: / An XML sitemap exists and lists the correct, final URLs Forms have been tested end-to-end, including the confirmation message and any notification email (see the forms & conversion checklist ) Redirects are in place for any URLs that are changing from a previous version of the site (see the technical SEO checklist ) Structured data has been added where relevant and validated (see the structured data checklist ) Analytics and Search Console are ready to go live the moment the site does (see the analytics checklist ) Legal & compliance A privacy policy is published and accurately describes what data the site actually collects A cookie/consent notice is in place if the site uses cookies or trackers that require it in your audience's jurisdiction (see the privacy & cookie consent checklist ) Terms of service or terms of use are published if the site sells anything or has user accounts Any required accessibility, ADA or industry-specific disclosures are in place for your market Copyright and trademark ownership of all site content, code and imagery is confirmed—stock images and fonts are properly licensed for the intended use ⚠️ None of this is legal advice. Requirements vary by country, state and industry—confirm what actually applies to your business with a qualified professional, especially around privacy law and accessibility compliance. Final QA pass Every navigation link and button has been clicked at least once The site has been reviewed on a real phone and a real tablet, not just a browser's device-simulation mode Search functionality, if present, returns sensible results for common queries The site loads correctly with cache cleared, in a private/incognito window A second person who wasn't involved in building the site has reviewed it end to end Every form field validation message has been triggered on purpose to confirm it's clear and helpful The site has been checked at a slow, throttled network speed, not just on a fast office connection A structured pass has been run against the QA & cross-browser checklist rather than relying on an unstructured final click-through Team sign-off Whoever is accountable for the launch has explicitly reviewed and approved the finished site, not just skimmed it Everyone with a stake in the outcome—client, stakeholders, support staff—knows what "launched" actually means and when it will happen A rollback plan exists in case something goes wrong on launch day (see the launch day checklist ) Once this is done, move on to analytics & tracking setup and the launch day checklist . --- # Content Checklist: Planning and Writing That Works Content checklist Good technical SEO gets a page found; good content is why anyone stays, trusts the site, and comes back. This checklist covers planning, writing, structuring and maintaining content that actually earns its place. Planning Every page has a clear purpose and a clear answer to "who is this for, and what do they need from it?" Content is planned around real questions and needs your audience has, not just keywords to target There's no unnecessary duplicate or near-duplicate content across multiple pages competing with itself Each page has one clear primary topic rather than trying to cover everything at once A content inventory or sitemap exists so nobody is guessing what pages already exist before writing something new Content gaps are identified deliberately—questions customers actually ask that the site currently doesn't answer anywhere Content is planned across the buyer's journey—some pages need to introduce a topic to someone unfamiliar with it, others need to help someone who already knows what they want compare options or decide Content briefs & workflow Before writing starts, there's a clear brief—purpose, audience, primary topic, and what "done" looks like—so a writer isn't guessing at scope A single owner is responsible for each piece of content, even on projects with multiple contributors, so nothing falls into a gap between people Content goes through an actual review step before publishing, not straight from first draft to live Fact-checking is a distinct step from proofreading—checking that claims are true is a different task from checking that sentences are well-formed Reusable templates or briefs exist for repeating content types (product pages, location pages, blog posts) so quality doesn't depend entirely on whoever happens to be writing that day Writing quality Content is written for the reader first—clear, direct language over jargon or filler Claims, statistics and facts are accurate and, where it matters, sourced or attributed Content is genuinely useful on its own—it doesn't exist purely as a vehicle for keywords or ads Tone is consistent with the brand and appropriate for the audience Long pages are broken into scannable sections with descriptive subheadings A consistent style guide (spelling conventions, capitalization, terminology) is followed across contributors, so the site doesn't read like it was written by five different people ⚠️ Never invent statistics, prices, testimonials or authoritative-sounding claims to make content look more substantial. Thin, honest content beats padded, fabricated content—both for trust and for search engines that increasingly penalize low-value, AI-generated filler. Trust & expertise signals Content that gives advice—medical, legal, financial or otherwise consequential—is written or reviewed by someone genuinely qualified, and that's made clear Author information is present where it adds credibility, and it's accurate—not a fabricated byline Sources for factual claims are real, checkable, and actually say what they're cited as saying Contact information and a genuine "about" page are easy to find, so a skeptical reader can verify who's behind the site Content is dated (published and, where updated, last-reviewed) so readers can judge whether it's current On-page content elements Each page opens with a clear summary of what it covers, rather than making readers hunt for the point Important information isn't buried below unrelated content or excessive introductions Calls to action are clear and tell the reader exactly what to do next Content is scannable—short paragraphs, lists and headings rather than dense walls of text Where a table, comparison or step list genuinely fits the content better than prose, it's used instead of forcing everything into paragraphs Multimedia Images, video and other media genuinely support the content, not decoration for its own sake All media has appropriate alt text or captions (see the accessibility checklist ) Media files are optimized for size and don't slow the page down (see the image optimization checklist ) Video content has captions or a transcript where practical Content types & formats The mix of content types (evergreen reference pages, timely posts, product/service pages, FAQs) matches what the audience actually needs, not just what's easiest to produce FAQ-style content answers real questions in plain language, and is marked up with structured data where genuine (see the structured data checklist ) If the site targets more than one language or region, translated content reads naturally and isn't a raw, unedited machine translation (see the international SEO checklist ) Content maintenance Content with dates, prices or facts that change over time is reviewed on a regular schedule Outdated statistics, expired offers or old screenshots are updated or removed Broken outbound links to other sites are checked periodically and fixed or removed Old, thin pages that no longer serve users are consolidated, improved or retired rather than left to rot A record is kept of when each important page was last substantively reviewed, so "probably fine" isn't the only evidence it's current See post-launch maintenance for how content review fits into an ongoing routine, and on-page SEO for how content structure supports search visibility. --- # On-Page SEO Checklist: Titles, Tags and Internal Links On-page SEO checklist On-page SEO is the set of choices you control directly on each page—as opposed to technical SEO (crawlability, site structure) or off-page factors like backlinks. Get these right on every page, not just the homepage. Keyword & search-intent research Each page is built around what real searchers are actually trying to accomplish, not just a phrase you'd like to rank for Search intent behind a topic is understood before writing—someone searching to compare options needs a different page than someone ready to buy Existing top-ranking pages for a target topic are reviewed to understand what searchers evidently expect to find there, not to copy them One page is built to be the strongest answer for a given topic, rather than several thin pages competing with each other for the same search intent Keyword research informs the topic and structure of a page; it never dictates unnatural, repeated phrasing stuffed into the copy Title tags Every page has a unique <title> tag—no two pages share the same title The primary keyword or topic for the page appears naturally near the front of the title Titles are descriptive and specific rather than generic ("Blue Wool Coats" beats "Products") Titles are written for a human reader first, not stuffed with repeated keywords Titles are a reasonable length so they don't get awkwardly truncated in typical search results Meta descriptions Every important page has a unique, written meta description—not a copy-pasted default The description summarizes the page's actual content and gives someone a reason to click No meta description is duplicated across multiple pages Descriptions avoid clickbait that doesn't match the page's actual content 💡 A meta description doesn't directly affect rankings, but it's often what shows in search results—a weak one costs clicks even when the ranking is fine. Headings & content structure Each page has exactly one <h1> that describes what the page is about Headings are used in a logical order (h1, then h2s, then h3s within those) rather than skipped or chosen for font size Headings describe the content that follows them, not vague labels like "More Info" Body content is organized into scannable sections rather than one long unbroken block of text Images Every meaningful image has descriptive alt text (empty alt="" for purely decorative images) Image file names are descriptive rather than generic ( navy-wool-coat.jpg instead of IMG_4821.jpg ) Images are compressed and appropriately sized for the space they're displayed in (see the image optimization checklist ) URL structure URLs are short, readable and describe the page ( /blue-wool-coats/ rather than /p?id=48291 ) URLs use hyphens to separate words, not underscores or spaces URL structure is decided early and kept stable—changing URLs after launch means setting up redirects URLs avoid unnecessary parameters, session IDs or duplicate paths to the same content Internal linking Important pages are reachable within a few clicks from the homepage Body content links to other genuinely relevant pages on the site using descriptive link text (not "click here") Orphan pages—pages with no internal links pointing to them—have been checked for and fixed Navigation menus reflect the site's actual priority pages, not just an alphabetical dump Anchor text varies naturally across links to the same page rather than repeating one exact phrase every time, which reads as unnatural to both people and search engines A reasonable number of genuinely relevant internal links appear in body content—enough to help navigation and topic understanding, not so many that the page reads as a link farm Duplicate content & canonicalization Near-identical pages (printer versions, tracking-parameter variants, staging leftovers) are consolidated with a canonical tag—see the technical SEO checklist Content isn't republished verbatim across multiple pages of the same site purely to target slightly different keywords Syndicated or cross-posted content links back to the original source, and the site doesn't rely primarily on content published elsewhere first Social preview tags Open Graph tags (title, description, image) are set so shared links look correct on social platforms and in chat apps A dedicated social-share image is used where practical, rather than an undersized logo that gets awkwardly cropped Social preview appearance has actually been tested by pasting a live URL into a platform's link-preview tool, not just assumed correct Structured data Relevant Schema.org structured data is added where it applies—Article, Product, LocalBusiness, FAQPage and so on (see the dedicated structured data checklist ) Structured data has been validated with Google's Rich Results Test or a Schema.org validator before launch Structured data accurately reflects the visible content on the page—it isn't used to claim something the page doesn't actually say Once on-page basics are covered, move to the crawlability and indexing side of things in the technical SEO checklist , and don't skip the content checklist —no amount of on-page tuning fixes thin or unhelpful content. --- # Technical SEO Checklist: Crawlability and Indexing Technical SEO checklist Technical SEO makes sure search engines can actually find, crawl, understand and index your pages. A site can have brilliant content and still be invisible in search if the technical foundation is broken. Crawlability & indexing robots.txt exists at the domain root and doesn't accidentally block pages you want indexed An XML sitemap exists, lists current URLs, and is referenced from robots.txt The sitemap has been submitted in Google Search Console (and Bing Webmaster Tools, if relevant to your audience) Pages that should be indexed don't carry a stray noindex tag left over from staging Pages that genuinely shouldn't be indexed (internal search results, thank-you pages, staging duplicates) are marked noindex deliberately Very large sites split sitemaps into multiple files with a sitemap index, since a single sitemap has practical size limits ⚠️ The single most common technical-SEO disaster at launch: a site built on a staging subdomain with a sitewide noindex or a blanket Disallow: / in robots.txt—and nobody removes it when the real domain goes live. Check this explicitly in the launch day checklist . Canonical tags Every page has a self-referencing canonical tag, or points to the correct canonical version if duplicate content exists The site is consistently accessible at one version of the domain—not indexable at both www and non- www , or both http and https Parameter-based duplicate URLs (sorting, filtering, tracking parameters) canonicalize back to the clean version Site architecture The site follows a logical, shallow hierarchy—important pages aren't buried many clicks deep A clear navigation and, where useful, breadcrumb structure helps both users and search engines understand page relationships Category and hub pages exist to group related content, rather than leaving pages disconnected Pagination on long listings uses clear, crawlable links rather than infinite scroll with no fallback for crawlers Redirects & error handling Old URLs from a previous version of the site 301-redirect to their new equivalents, not to a generic homepage There are no unnecessary redirect chains (URL A → B → C should be A → C directly) Redirects preserve the query string or fragment where the target page still needs that information, rather than dropping it silently Broken internal links (404s) have been crawled for and fixed before launch A proper 404 status code is returned for missing pages—not a 200 status on a page that says "not found" (a "soft 404") A full crawl of the site has been run with a site crawler (such as Screaming Frog SEO Spider, which is free for small sites) to catch broken links, redirect chains and orphan pages before they're found the hard way Structured data & rich results Applicable Schema.org markup is implemented (Organization, WebSite, Article, Product, FAQPage, BreadcrumbList, etc.)—see the structured data checklist Markup is tested with Google's Rich Results Test and free of errors Structured data is kept in sync when the visible page content changes—stale markup describing removed content is a real risk International & crawl-budget considerations Sites targeting more than one language or region use hreflang correctly rather than relying on browser auto-translation alone—see the international SEO checklist On very large sites, low-value URLs (endless filter combinations, internal search results) are kept out of the crawlable, indexable set so crawlers spend their time on pages that matter Server response codes are checked for consistency—pages don't flip between 200 and 404/500 depending on load or caching state JavaScript rendering & crawlability Content that needs to be indexed doesn't depend entirely on client-side JavaScript running successfully—critical text and links are present in, or reachable from, what a crawler actually receives Pages have been checked with a tool's "rendered HTML" or fetch-and-render view (Search Console's URL Inspection tool shows this) to confirm what's actually being indexed matches what a visitor sees Internal links are real <a href> elements, not JavaScript click handlers on non-link elements that a crawler can't follow Content that loads only after a user interaction (a click to "load more", an infinite-scroll trigger) has a crawlable fallback, such as paginated links, so it isn't invisible to search engines Search Console & monitoring The site is verified in Google Search Console under the correct property Coverage and indexing reports are checked after launch for crawl errors Core Web Vitals reports in Search Console are reviewed periodically (see the performance checklist ) Manual actions and security-issue reports are checked, especially after any major site change Pair this with the on-page SEO checklist for content-level optimization, and see analytics & tracking setup for getting Search Console and analytics wired up correctly. If you're moving an existing site rather than launching a new one, the site migration checklist covers the redirect and monitoring work in far more depth. --- # Structured Data Checklist: JSON-LD and Rich Results Structured data & schema checklist Structured data is a standardized way of describing what's actually on a page—this is a product with this price, this is an article by this author, this is a business at this address—so search engines (and other tools that read the web) can understand it with certainty instead of guessing. Done well, it can unlock richer search result displays; done carelessly, it can describe a page inaccurately, which is a real risk, not just a wasted opportunity. Choosing the right format JSON-LD is used rather than older microdata or RDFa approaches—it's the format search engines document and recommend, and it lives in a single script block instead of being scattered through HTML attributes Structured data is placed as a self-contained script rather than split awkwardly across the page Only genuinely applicable schema types are used—there's no benefit, and real risk, in bolting on a type that doesn't actually describe the page Core, near-universal types Organization : name, logo and URL for the business behind the site, usually included site-wide WebSite : the site's name and URL, optionally with a sitelinks search box definition if the site has real internal search BreadcrumbList : matches the visible breadcrumb trail on the page exactly—position and labels included Content-specific types Article / BlogPosting : headline, author, publish and modified dates that match what's actually visible on the page Product : accurate price, currency, availability and, where genuine, aggregate rating—see the e-commerce checklist LocalBusiness (or a more specific subtype): name, address, phone and hours that match the site and Google Business Profile exactly—see the local SEO checklist FAQPage : only used for content that is genuinely presented as a question-and-answer list on the page, with the exact visible question and answer text Event : accurate date, time, location and status (scheduled, postponed, cancelled) kept current as an event approaches or passes Recipe , Review , JobPosting and other niche types: used only where the site genuinely publishes that content type, with every required property filled in accurately Accuracy & maintenance Structured data is generated from the same data source as the visible page content wherever possible, so the two can't quietly drift apart Price, availability, ratings and dates in markup are never more favorable than what a visitor actually sees on the page Markup is regenerated or reviewed whenever the underlying content, pricing or inventory system changes Fabricated or padded review/rating data is never added purely to try to unlock a rich result—this violates search engine guidelines and is exactly the kind of thing that draws a manual action ⚠️ Structured data that claims something the page doesn't actually show—an inflated rating, a price that doesn't match checkout, an availability status that's wrong—isn't just a technical error. It's misleading users and it violates the guidelines of every major search engine that supports rich results. Testing & validation Every page type with structured data has been tested individually with Google's Rich Results Test General schema validity (not just Google's supported subset) is checked with the Schema.org validator Markup is spot-checked after any template or CMS update, since a single broken include can silently break structured data sitewide Search Console's relevant enhancement reports are checked periodically for new errors, not just at initial launch See the on-page SEO checklist and technical SEO checklist for how structured data fits into the broader picture, and the local SEO and e-commerce checklists for the schema types most specific to those site types. --- # Core Web Vitals Checklist: Speed, LCP, INP and CLS Performance & Core Web Vitals checklist Speed affects everything downstream—how long visitors stay, whether forms get completed, and how search engines evaluate the page experience. This checklist covers the fundamentals and Google's Core Web Vitals metrics specifically. What Core Web Vitals measure LCP (Largest Contentful Paint): how long it takes the largest visible element (usually a hero image or heading) to render INP (Interaction to Next Paint): how responsive the page feels when a visitor clicks, taps or types CLS (Cumulative Layout Shift): how much visible content unexpectedly shifts around while the page loads Images & media Images are compressed and served at a size appropriate to where they're displayed—not a 4000px-wide image shown at 400px Modern, efficient image formats are used where supported, with fallbacks for older browsers (see the dedicated image optimization checklist ) Images and iframes below the fold are lazy-loaded so they don't compete for bandwidth with what's immediately visible Every image has explicit width and height (or an aspect-ratio) so the browser reserves space before it loads—this alone prevents most layout shift Video is not set to autoplay large files unnecessarily, especially on mobile connections Code & asset optimization CSS and JavaScript are minified for production Unused CSS and JavaScript are trimmed rather than shipped on every page regardless of need Render-blocking scripts are deferred or loaded asynchronously where possible Web fonts are limited in number and variant, and use a strategy that avoids invisible text while loading Third-party scripts (widgets, chat tools, ad tags) are audited—each one is a real performance cost, and unused ones should be removed Critical above-the-fold CSS is prioritized so the visible part of the page can render without waiting on the entire stylesheet Server & backend performance Time to first byte has been measured specifically, separate from front-end asset loading—a slow server delays everything downstream regardless of how optimized the front end is Database queries behind dynamic pages are checked for obvious inefficiency, especially anything that scales badly as content grows Server-side or edge caching is used for pages and data that don't need to be regenerated on every single request Hosting has adequate capacity for expected traffic—an undersized plan is a common, avoidable cause of slow responses, particularly under any kind of traffic spike Hosting & caching The site uses browser caching so returning visitors don't re-download unchanged assets A content delivery network (CDN) is used to serve static assets closer to visitors, if the audience is geographically spread out Cache invalidation is handled correctly when content changes—visitors shouldn't see stale content indefinitely, nor should every deploy force a full cold cache Resource hints & loading priority The most critical resource for the page's LCP element (a hero image, a key font) is prioritized to load as early as possible Connections to critical third-party origins are established early where the platform supports it, rather than only starting once the browser discovers a reference to them deep in the page Resource hints are used selectively for genuinely critical resources—overusing them for everything defeats the purpose and can slow the page down instead Fonts are preloaded only when they're used above the fold; preloading fonts used further down the page wastes early bandwidth that the visible content needs first Non-critical JavaScript (analytics, chat widgets, below-the-fold interactivity) is deferred so it doesn't compete with the resources the visible page actually needs first Layout stability Ads, embeds and dynamically injected content reserve space in advance rather than pushing the page around when they load Web fonts don't cause a visible layout jump when they swap in Cookie banners and popups are sized and positioned so they don't shift the content underneath Testing & tools Real-world (field) performance is checked in Google Search Console's Core Web Vitals report, which reflects actual visitor data Lab testing tools like Google PageSpeed Insights, Lighthouse (built into Chrome DevTools) or WebPageTest are used to diagnose specific issues Performance is tested on a throttled, mid-range mobile connection, not just a fast office connection Performance is re-checked after any significant redesign, not just at initial launch 💡 Field data (real visitors, from Search Console) and lab data (a single simulated test run) can disagree—field data reflects reality more closely, but lab tools are far better for diagnosing exactly what's slow. Monitoring over time Core Web Vitals are checked on a recurring schedule, not only once at launch, since third-party scripts and content additions tend to erode performance gradually A performance regression after a deploy is treated as seriously as a functional bug, not as an acceptable side effect of shipping features Key pages (homepage, top landing pages, checkout) are monitored specifically, since site-wide averages can hide a badly performing high-traffic page Performance overlaps heavily with technical SEO and with mobile experience —a slow site is disproportionately a slow mobile site. See the image optimization checklist for the single biggest lever most sites have. --- # Image Optimization Checklist: Formats and Compression Image optimization checklist Images are usually the single heaviest thing on a typical web page, and they're one of the easiest things to fix without touching a line of application code. This checklist goes deeper than the general performance checklist specifically on getting images right. Choosing a format Photographic images use a modern, efficient compressed format where the platform and audience's browsers support it, with a JPEG fallback for compatibility Illustrations, logos and images with flat colors or transparency use a format suited to that content (typically SVG for vector graphics, PNG where transparency is needed and the image isn't a vector) Animated content is evaluated for whether it needs to be a heavy GIF at all—a compressed video format is usually dramatically smaller for the same result SVG files used on the site are cleaned of unnecessary editor metadata, which can otherwise bloat an SVG far beyond what the actual graphic needs Compression Every image is run through compression before upload—a free browser-based tool such as Squoosh (from Google's Chrome team) makes this easy to check visually before committing to a setting Compression is checked visually at real size, not just judged by file size alone—the goal is the smallest file with no visible quality loss at the size it's actually displayed Images aren't uploaded at a far larger resolution than any layout on the site will ever display them at A build step or CMS media pipeline handles compression automatically wherever possible, so it doesn't depend on every contributor remembering to do it by hand Responsive images Images that appear at different sizes across breakpoints use srcset / sizes (or an equivalent CMS feature) so mobile visitors aren't downloading a desktop-sized file Art-directed images—where the crop itself should change between mobile and desktop, not just the size—use the <picture> element rather than one fixed crop for every screen size Retina/high-density displays are accounted for without simply doubling every image's size regardless of need Loading behavior Images below the fold are lazy-loaded so they don't compete for bandwidth with what's immediately visible The single largest above-the-fold image (often the page's LCP element) is not lazy-loaded, and is prioritized to load as early as possible Every image has explicit width and height (or a defined aspect ratio) in the markup so the browser reserves space before the file arrives, preventing layout shift ⚠️ Lazy-loading the hero image is a common mistake that actively hurts Core Web Vitals—it delays the page's Largest Contentful Paint instead of speeding it up. Lazy-load what's off-screen; prioritize what's not. Delivery Images are served from a CDN or the host's built-in image delivery, so visitors download from a server close to them Image URLs are cacheable and don't change unnecessarily on every deploy, so returning visitors benefit from browser caching Broken images (wrong path, deleted file, failed upload) are checked for across the whole site, not just spot-checked on a couple of pages Accessibility & SEO Every meaningful image has descriptive alt text; purely decorative images use an empty alt="" (see the accessibility checklist ) Image file names are descriptive rather than generic, which also helps image search discoverability Product and content images intended to appear in image search or rich results are large enough and clear enough to actually be useful there Once images are optimized, re-check the page with Google PageSpeed Insights or Lighthouse and confirm the Largest Contentful Paint improved—for most content-heavy or image-heavy sites, this single checklist has the biggest visible impact on the performance checklist as a whole. --- # Accessibility Checklist: Semantic HTML and Contrast Accessibility checklist Accessibility means people using screen readers, keyboard-only navigation, voice control or low-vision settings can actually use your site. It's also good practice generally—accessible sites tend to be cleaner, more semantic, and easier for search engines to understand too. Semantic HTML & structure Real HTML elements are used for their purpose— <button> for buttons, <nav> for navigation, proper heading tags—rather than styled <div> s pretending to be interactive Heading levels are in a logical, unskipped order (see the SEO checklist ) Page language is declared correctly in the HTML, and any section written in a different language declares that too Landmarks (header, nav, main, footer) are used so screen-reader users can jump between page regions Lists are marked up as actual <ul> / <ol> elements rather than visually styled paragraphs with manual bullet characters Color & contrast Text has sufficient contrast against its background, meeting WCAG AA contrast guidelines at minimum Color is never the only way information is conveyed (for example, error states also use an icon or text label, not just red text) Links are distinguishable from surrounding text by more than color alone (underline, weight, or a clear visual pattern) Contrast has been checked in both light and dark presentations if the site supports both Keyboard navigation Every interactive element—links, buttons, form fields, menus—can be reached and operated using only a keyboard A visible focus indicator is present when tabbing through the page (never removed with outline:none and nothing put in its place) Tab order follows a logical, visual reading order A "skip to main content" link is available for keyboard and screen-reader users to bypass repeated navigation Custom widgets (dropdowns, modals, carousels, tabs) trap and return focus correctly—a keyboard user can never get silently stuck or lose their place ARIA usage ARIA attributes are used to add meaning that native HTML can't express—not as a first resort in place of a native element that already does the job Custom interactive components (custom dropdowns, tab panels, accordions) expose the correct role, state and label so assistive technology announces them correctly Live regions are used sparingly and only where a genuine dynamic update (a form error, a status message) needs to be announced without moving focus ARIA labels are checked for accuracy—a mislabeled control is often worse than an unlabeled one, since it actively misleads Documents & downloadable content PDFs and other downloadable documents that carry meaningful content are checked for basic accessibility—a real heading structure, tagged reading order, and text that's actually selectable rather than a scanned image Where practical, important information isn't locked exclusively inside a PDF with no equivalent presented as an accessible web page Downloadable file type and size are indicated in the link text, so a visitor knows what they're about to open before they click Images & media Every meaningful image has descriptive alt text; purely decorative images use an empty alt="" so screen readers skip them Video content has captions; audio content has a transcript where practical Content doesn't rely on autoplaying audio or video that a visitor can't easily pause or stop Forms Every form field has a properly associated, visible label—not just placeholder text that disappears on input Error messages are specific, programmatically associated with their field, and not conveyed by color alone Required fields are clearly marked, not just implied Forms can be completed and submitted using only a keyboard Related fields (like a billing address) are grouped with a proper fieldset and legend where it aids understanding Data tables Tables used for genuine tabular data use real <table> markup with <th> header cells, not a grid of styled divs Column and row headers are associated with their data cells so a screen reader can announce what each cell relates to Tables are never used purely for visual page layout—that's what CSS layout is for Motion & interaction Content respects a visitor's reduced-motion preference for non-essential animation Timeouts (for forms, sessions) give users a way to extend the time if needed Interactive elements have touch/click targets large enough to hit reliably (see the mobile checklist ) Testing & tools The site has been tested using keyboard-only navigation, unplugging the mouse entirely An automated checker such as WAVE or axe DevTools has been run and flagged issues addressed At least a basic pass has been done with a screen reader to confirm the page makes sense read aloud Automated tools are treated as a floor, not a guarantee—they catch a meaningful minority of real accessibility issues, and manual review still matters Testing has been folded into the general QA & cross-browser checklist rather than treated as a one-off, separate pass ⚠️ Accessibility requirements can carry legal weight depending on your jurisdiction and the nature of your organization. This checklist covers good general practice, not legal compliance—confirm specific obligations with a qualified professional. See also the mobile & responsive checklist for touch-target sizing, and the content checklist for writing clear, plain-language copy that helps every reader, not just some. --- # Mobile Checklist: Viewport, Touch and Responsive Design Mobile & responsive checklist For most sites, mobile is not a secondary experience—it's the primary one. A site that merely "works" on mobile isn't good enough; it needs to be genuinely comfortable to use on a small touchscreen. Responsive fundamentals A correct viewport meta tag is present ( width=device-width, initial-scale=1 ) so mobile browsers don't fake a desktop-width page Layout adapts cleanly across common breakpoints—phone, tablet and desktop widths—without horizontal scrolling Text is legible without the visitor needing to pinch-zoom Content reflows into a single, logical column on narrow screens rather than being squeezed Layout has been checked at the awkward in-between widths, not just the extremes of "phone" and "desktop" Touch targets & interaction Buttons and links are large enough, and spaced far enough apart, to tap accurately with a finger Menus, dropdowns and any hover-based interaction from desktop also work with tap on mobile—nothing depends on a mouse hover to be usable Forms use appropriate mobile input types (email, tel, number) so the correct keyboard appears automatically Sticky headers or footers don't eat up excessive screen space on small devices Swipeable or draggable interface elements have a clear, non-gesture-dependent fallback way to accomplish the same action Mobile navigation patterns A collapsed ("hamburger") menu, if used, is instantly recognizable and opens with a single tap into a clear, scannable list Primary actions and navigation sit within comfortable thumb reach on a typical phone, rather than requiring an awkward stretch to the far top corner for everything Search, if it's a primary way visitors find content, is easy to reach from anywhere in the mobile navigation, not buried several taps deep Bottom navigation bars or fixed action buttons, where used, don't overlap or obscure content as a visitor scrolls Deep navigation hierarchies collapse sensibly on mobile—a visitor should never lose track of where they are in the site on a small screen Mobile content & layout The most important content and calls to action are visible near the top on mobile, not buried below unrelated elements Tables and wide content scroll within their own container rather than breaking the page's layout Pop-ups and interstitials don't cover the whole screen in a way that's hard to dismiss on mobile Images and media scale to fit the screen rather than overflowing or forcing horizontal scroll Mobile forms Forms are shortened to what's genuinely necessary on a small screen—every extra field is more friction on mobile than desktop (see the conversion & forms checklist ) Autofill and autocomplete attributes are set correctly so returning visitors aren't retyping information mobile browsers already have Date pickers, dropdowns and other custom controls use the device's native input where practical, rather than a fragile custom widget that fights the on-screen keyboard Mobile performance Page speed has been tested specifically on a throttled mobile connection, not just desktop broadband (see the performance checklist ) Large, unnecessary assets aren't served to mobile visitors who don't need them Tap responsiveness feels immediate—no noticeable lag between a tap and the resulting action Data usage is treated as a real cost to the visitor, not just a speed metric—unnecessarily heavy pages are a genuine burden on limited or metered mobile data plans Mobile-specific SEO Since indexing is mobile-first for virtually all sites today, the mobile version of a page carries the content and structured data that matters—nothing important is hidden or removed on small screens Interstitials or app-install banners don't block content from being genuinely accessible to a mobile visitor arriving from search Tap-to-call and tap-to-map links work correctly for phone numbers and addresses Testing The site has been checked on at least one real phone and one real tablet, not only a browser's device-simulation mode Both portrait and landscape orientations have been checked where relevant Forms, checkout flows and navigation menus have specifically been tested by hand on a touchscreen The site has been tested on more than one mobile browser, since rendering can differ—see the QA & cross-browser checklist On-screen keyboards have been checked against real forms to confirm they don't cover the field currently being filled in, or the submit button once typing is done 💡 Browser device-simulation tools are useful for a fast first pass, but they don't fully replicate real touch behavior, real network conditions, or how a phone's on-screen keyboard covers form fields. Always finish with a real-device check. Mobile experience overlaps closely with performance and accessibility —a site that's fast and accessible is usually most of the way to being genuinely mobile-friendly too. --- # Website Security Checklist: HTTPS, Backups and Logins Website security checklist Security isn't a one-time setup step—it's an ongoing responsibility. This checklist covers the baseline every site should have, whether it's a simple brochure site or something handling customer data and payments. HTTPS & SSL/TLS The entire site runs on HTTPS with a valid, non-expired certificate HTTP requests redirect to HTTPS automatically—there's no way to view the site insecurely Certificate configuration has been checked with a tool like Qualys SSL Labs' SSL Test for known weaknesses Certificate renewal is automated, or there's a reminder in place well before expiry Security headers A Content-Security-Policy is configured to restrict what scripts and resources a page can load HTTP security headers (such as Strict-Transport-Security, X-Content-Type-Options and a sensible Referrer-Policy) are set Header configuration has been checked with a free scanner such as securityheaders.com Software & dependencies The CMS, plugins, themes and any server software are kept updated with current security patches Unused plugins, themes and integrations are removed rather than left installed and unpatched Dependencies are sourced from reputable, actively maintained providers, not abandoned or unofficial sources Version numbers and stack details aren't unnecessarily exposed in page source or HTTP headers, which makes targeted attacks easier Third-party & script security Every third-party script (analytics, chat widgets, ad tags, embeds) is treated as a real security consideration, not just a performance one—each one runs with access to the page Third-party scripts are loaded from the vendor's own domain, or via a mechanism that verifies the file hasn't been tampered with, where the platform supports it Scripts and integrations that are no longer actively used are removed rather than left connected indefinitely Any embedded forms or checkouts from third parties are confirmed to run over HTTPS with no mixed-content warnings Backups Automated backups run on a regular schedule, covering both the database and files Backups are stored somewhere separate from the live server, not only on the same machine A restore has actually been tested at least once—an untested backup is not a verified backup There's a clear, documented process for who restores a backup and how, before it's ever needed under pressure Backup frequency matches how much data loss would actually be tolerable—a daily backup is not enough for a site taking constant transactions ⚠️ A backup you've never tested restoring is a guess, not a safety net. Schedule at least one real restore test before you need it for real. Login & admin protection Admin and login areas use strong, unique passwords—never defaults left over from setup Multi-factor authentication is enabled for admin accounts wherever the platform supports it The number of people with administrator access is kept to the minimum actually needed Login attempts are rate-limited or otherwise protected against automated brute-force attempts Former employees' or contractors' access is revoked promptly when a project relationship ends Forms & user input Contact and comment forms use spam protection so submissions don't become an unmanageable flood All user input is validated and sanitized server-side, not trusted just because it passed a client-side check File-upload fields, if present, restrict file types and size, and don't allow executable files Environment & secrets management API keys, database credentials and other secrets are kept out of version control entirely—never committed, even temporarily, and never left in a public repository's history Different credentials are used for staging/development and production, so a leaked staging key can't touch live data Secrets are rotated after anyone with access to them leaves the project or if a leak is ever suspected, not left unchanged indefinitely Environment configuration is documented well enough that redeploying or rebuilding the site doesn't depend on one person's memory of which keys go where Third-party API keys are scoped to the minimum permissions they actually need, rather than granted broad access by default because it was easier to set up Incident response There's a written plan for how to respond if the site is compromised—who to contact, how to restore from backup, how to rotate credentials Contact details for the host, DNS registrar and any critical vendors are documented somewhere accessible even if the site itself is down After any incident, a brief review captures what happened and what changes to prevent a repeat, rather than just restoring and moving on Ongoing monitoring Uptime monitoring alerts you if the site goes down Security headers, SSL configuration and software versions are re-checked periodically, not only at launch Unusual admin activity (unexpected logins, unfamiliar new admin accounts, unexpected file changes) is something someone is actually watching for See post-launch maintenance for how security tasks fit into an ongoing routine, privacy & cookie consent for handling personal data responsibly, and email deliverability for the DNS-level security that keeps your domain from being spoofed. --- # Privacy and Cookie Consent Checklist: GDPR/CCPA Basics Privacy & cookie consent checklist Privacy law varies significantly by country, state and audience—this checklist is not a substitute for legal advice, and it can't tell you which specific regulations apply to your business. What it can do is walk through the practical, engineering-level groundwork almost every site needs regardless of exactly which law applies: knowing what data you actually collect, being honest about it, and giving visitors real choices. ⚠️ This page is general practical guidance, not legal advice. Privacy regulation differs by jurisdiction, audience location and business type. Confirm your specific obligations—including whether GDPR, CCPA/CPRA, or another framework applies to you—with a qualified professional. Know what you actually collect There's an accurate, current inventory of every place the site collects personal data—forms, analytics, cookies, chat widgets, embedded third-party content Each data collection point has a genuine, understood purpose—data isn't collected just because a tool made it easy to turn on Third-party scripts and embeds are reviewed for what data they collect on your behalf, since a visitor doesn't distinguish between your code and an embedded widget's Data retention is considered explicitly—how long is information actually kept, and is that period justified Cookie & tracking consent A consent mechanism is in place before non-essential cookies or trackers load, if required for your audience's jurisdiction—not fired automatically on page load with consent as an afterthought Strictly necessary cookies (the ones the site genuinely can't function without) are distinguished from analytics, marketing and other optional trackers Visitors have a genuine, equally easy way to decline optional tracking as to accept it—a consent flow that makes "reject" meaningfully harder to find than "accept" undermines the point of asking at all A visitor's choice is actually respected—declining doesn't just hide the banner while trackers keep firing in the background Consent choices can be reviewed or changed later, not just set once and forgotten Privacy policy accuracy The privacy policy describes what the site actually does, not a generic template that doesn't match reality Every category of data collected, and why, is covered—including data collected by analytics and third-party embeds, not just first-party forms Contact information for privacy questions or data requests is accurate and actually monitored The policy is reviewed and updated whenever a new tool, tracker or data-collection point is added to the site—not just once at launch Data minimization & handling Forms only ask for information genuinely needed for the stated purpose—collecting "just in case" data is a liability, not an asset Personal data submitted through forms is transmitted and stored securely, not emailed in plain text to a personal inbox as the only copy Access to any stored personal data is limited to people who genuinely need it There's a clear, working process for someone to request their data be deleted or corrected, if that applies to your audience Third-party & vendor awareness Every analytics, advertising, chat, form, or embed vendor used on the site is known, not just installed and forgotten Vendor privacy practices are at least glanced at before adopting a new tool, rather than assumed to be fine because everyone uses it Vendors that are no longer actually used are removed, along with whatever data-collection footprint they left behind Pair this with analytics & tracking setup for the practical side of privacy-respecting measurement, and the security checklist for keeping any data you do collect actually safe. --- # Email Deliverability Checklist: SPF, DKIM and DMARC Email deliverability checklist A contact form that emails you, a password reset, an order confirmation—all of it is worthless if the message lands in spam or bounces silently. Deliverability is largely a DNS and reputation problem, and most of it can be checked and fixed before it ever costs you a customer. Core authentication records SPF (Sender Policy Framework) is published as a TXT record listing which servers are authorized to send mail for your domain DKIM (DomainKeys Identified Mail) is configured so outgoing mail is cryptographically signed, letting receiving servers verify it wasn't altered or spoofed DMARC is published, telling receiving servers what to do with mail that fails SPF or DKIM, and where to send reports about it Only one SPF record exists per domain—multiple SPF TXT records is a common, silent misconfiguration that breaks the check entirely Every legitimate sending source—your website's contact form, your email provider, any marketing or transactional email service—is actually included in SPF and set up for DKIM, not just your main mailbox provider ⚠️ A domain migration or hosting change is one of the most common ways SPF/DKIM/DMARC records get silently dropped or overwritten. Re-check these records specifically as part of any DNS or host change—see the site migration checklist . DMARC rollout DMARC starts at a monitoring-only policy so you can see what's actually passing and failing before enforcing anything DMARC aggregate reports are actually reviewed, not just generated and ignored, so legitimate mail that's failing gets fixed before enforcement tightens Policy is only tightened toward rejecting unauthenticated mail once you're confident every legitimate sending source is properly authenticated Sender reputation & content The sending domain and IP have a track record of low spam complaints and low bounce rates—reputation is built over time and can be damaged quickly Transactional email (receipts, password resets, notifications) is kept genuinely separate in tone and volume from marketing email, since the two have very different risk profiles Recipient lists are kept clean—sending to addresses that consistently bounce or never engage drags down deliverability for everyone on the domain Unsubscribe or opt-out requests are honored promptly and completely for any marketing mail Website-specific sending Contact-form and notification emails are sent through a properly authenticated path, not spoofed from an address the sending server isn't authorized to use The "from" address used by automated site email is a real, monitored address where practical, not a no-reply address that silently swallows replies Transactional emails (order confirmations, password resets, receipts) are tested end-to-end and confirmed to actually arrive, not just confirmed to leave the server Testing & monitoring SPF, DKIM and DMARC records are checked with a free DNS lookup tool such as MXToolbox to confirm they're published correctly and consistently A test message is sent and its full authentication result reviewed, not just glanced at for a generic "sent successfully" confirmation Google Postmaster Tools (or an equivalent from a major mailbox provider) is used if mail volume is high enough to get meaningful reputation data from it Deliverability is re-checked after any change to hosting, DNS, or the service actually sending the mail See the security checklist for the broader DNS and domain-security picture, and the site migration checklist for keeping email working through a host or DNS change. --- # QA and Cross-Browser Testing Checklist for Websites QA & cross-browser testing checklist "It works on my machine" is the most expensive sentence in web development. This checklist turns testing from an ad-hoc final click-through into something structured enough to actually catch problems before visitors do. What to test on The site is checked on the current versions of the major browsers your actual audience uses—check analytics for what that mix really is rather than guessing At least one real phone and one real tablet are used, in addition to browser device-simulation modes, since simulation doesn't fully replicate real touch and rendering behavior (see the mobile checklist ) Both a recent and a somewhat older browser version are checked where practical, since not every visitor updates immediately If the site has meaningfully different behavior signed in vs. signed out, both states are tested, not just whichever is more convenient Functional testing Every primary user flow—browsing, searching, filling a form, checking out—is walked through start to finish, not just spot-checked at individual steps Every navigation link, button and interactive element has actually been clicked at least once Form validation is triggered deliberately—submit with fields empty, with invalid input, with unexpected characters—to confirm error handling is clear and correct Search functionality, if present, is tested with a query that should return results and one that genuinely shouldn't, to confirm both cases are handled sensibly Edge cases Very long text (a long name, a long product title) is tested to confirm layouts don't visibly break Empty states are checked—an empty cart, zero search results, a list with nothing in it—since these are often untested and look broken by default Slow and interrupted network conditions are tested, not just a fast, unbroken connection Browser back/forward navigation is tested through multi-step flows like checkout or multi-page forms JavaScript-disabled behavior is at least considered, particularly for content that should be crawlable or usable without it Visual & layout checks Layout is checked at a range of widths, not just the smallest and largest breakpoints—awkward in-between sizes catch real bugs Dark mode and light mode (if the site supports both) are each checked independently, not just visually skimmed Print styles are checked in an actual print preview if any pages are meant to be printed Zoomed-in text (a visitor increasing browser font size) is checked to confirm layout doesn't break Regression testing Before any significant deploy, the core user flows are re-tested, not assumed unaffected because the change looked unrelated A running list of previously-found, previously-fixed bugs is kept and periodically re-checked, since regressions on old fixes are common Changes are tested on a staging environment that mirrors production as closely as practical before going live 💡 A structured test pass doesn't need to be expensive or automated to be valuable. A written checklist that a second person actually works through, every time, catches far more than an unstructured final glance from whoever built the feature. Reporting & tracking issues Bugs found during testing are written down with clear steps to reproduce, not just mentioned in passing and forgotten Each issue is triaged—genuinely blocking for launch, or acceptable to fix after—rather than treated as uniformly urgent or uniformly ignorable Fixed issues are actually re-verified as fixed, not just assumed resolved because a change was made Fold this into the pre-launch checklist before a new site goes live, and into the site migration checklist before replacing an existing one. --- # Launch Day Checklist: The Final Go-Live Run-Through Launch day checklist Everything in the pre-launch checklist should already be done. This is the final, ordered run-through for the actual go-live moment—the small, easy-to-forget steps that turn a finished site into a live one. Before flipping the switch Confirm every item in the pre-launch checklist is genuinely complete, not just planned Take a final backup of the outgoing site (if replacing an existing one) before making any changes Confirm DNS records are correctly configured and, if changing hosts, that TTL values were lowered in advance to speed propagation Double-check the SSL/TLS certificate covers the exact domain and subdomains being used Remove any staging-only noindex tags or password protection left over from development Confirm robots.txt is not still blocking the whole site Confirm email-sending records (SPF/DKIM/DMARC) weren't disturbed by the DNS changes—see the email deliverability checklist Go live Point DNS to the production environment, or make the production site publicly reachable Load the live domain in a private/incognito browser window to confirm it resolves correctly with no leftover cache Confirm HTTPS is active and there are no mixed-content warnings Click through primary navigation, forms, and any checkout or sign-up flow on the live domain itself, not just staging Set up 301 redirects from any old URLs to their new equivalents, if this is a relaunch (see the technical SEO checklist and the migration checklist ) Tell search engines Submit the XML sitemap in Google Search Console (and Bing Webmaster Tools, if relevant) Request indexing for the homepage and any especially important pages Confirm analytics and Search Console are both tracking the correct, live property Cross-check The site has been checked on at least one real phone, in addition to desktop Forms have been tested end-to-end on the live domain, including that notification emails actually arrive Any payment or checkout flow has been tested with a real (or sandbox) transaction, not assumed to work because it worked in staging Search functionality, if present, has been tested with a real query Social sharing previews (Open Graph/Twitter Card images and titles) look correct when a link is shared Team communication Everyone who needs to know the site is live has actually been told, including support or sales staff who might field questions about it A single, clear point of contact is designated for launch-day issues, so problems aren't reported into a void or to three different people at once Anyone with deploy or DNS access is aware the launch is happening, so nobody makes an unrelated change at the same time Timing the launch Launch is scheduled for a time when the team can actually monitor and respond, not the last thing before everyone logs off for a weekend or holiday If the site depends on a third party (payment processor, booking system, external API), their status is checked before launch rather than assumed fine A quiet, low-traffic window is preferred where the business has one, so any issue affects the fewest visitors possible before it's caught Rollback plan A clear, agreed threshold exists for what would trigger rolling back—decided in advance, not improvised under pressure The rollback path itself (reverting DNS, restoring a backup, redeploying a previous build) has actually been rehearsed or at least documented, not assumed to be simple Whoever can authorize a rollback is reachable and knows they may need to make that call quickly After launch Uptime monitoring is active and alerting the right people Analytics is checked within the first 24–48 hours to confirm data is actually flowing Search Console's coverage report is checked over the following days for unexpected crawl errors Performance is spot-checked in the days after launch, since real traffic and real network conditions sometimes surface issues staging never showed Server and application error logs are checked directly in the first day or two, not just inferred from whether anyone happened to complain A short retrospective is held once the dust settles—what went smoothly, what didn't, and what should change for next time—while it's still fresh enough to be useful 💡 Launch day is a good moment to schedule the first recurring check-in from the post-launch maintenance checklist —put it on a calendar immediately, while the site is still front of mind, rather than "whenever there's time." If anything about the launch feels rushed, it's worth revisiting common mistakes before going live rather than after. --- # Analytics Checklist: Search Console and Tracking Setup Analytics & tracking setup checklist You can't improve what you don't measure—but tracking setup is also one of the most common things skipped until after launch, which means you lose your baseline data for the exact period you'll want it most: launch week. Choosing what to measure Metrics tracked actually connect to the site's real goals—leads, sales, sign-ups, support deflection—rather than defaulting to whatever a dashboard shows first Vanity metrics (raw pageviews and visits alone) are treated as context, not as the primary measure of whether the site is succeeding A small set of key metrics is agreed on in advance, so success or failure isn't judged retroactively by whichever number happens to look good Metrics are tied to specific pages or flows where relevant, so a problem can be traced to where it's actually happening rather than only seen in an aggregate number Before you launch An analytics tool is installed and verified as firing correctly before launch day, not added afterward Google Search Console is set up and the site's ownership is verified The XML sitemap is submitted inside Search Console once the live domain is verified Tracking has been tested on a staging environment to confirm it doesn't pollute production data once live Core setup Analytics tracking code is installed on every page, not just a subset A tag management system is used (if your setup benefits from one) so tracking tags can be managed without editing site code directly Internal traffic (your own team's visits) is filtered out or excluded so it doesn't skew reports Cross-domain tracking is configured correctly if your site spans multiple domains or subdomains Goals & conversions Key actions—form submissions, purchases, sign-ups, calls—are set up as trackable conversions or events Conversion tracking has been tested by completing the action yourself and confirming it registers E-commerce tracking is configured correctly if the site sells products (see the e-commerce checklist ) Attribution & campaigns Marketing links (email, social, ads) use consistent, well-structured tracking parameters so traffic sources can actually be distinguished later Attribution settings are understood well enough to interpret reports correctly, rather than treating a single attribution model's numbers as unambiguous truth Referral traffic from payment processors or embedded third-party checkouts isn't accidentally misattributed as a normal external referral Data quality Reported numbers are spot-checked against a real, known event—a test purchase, a known form submission—to confirm tracking actually reflects reality Bot and spam traffic is reviewed for and filtered where the analytics platform supports it Sudden, unexplained jumps or drops in a metric are investigated rather than reported at face value Privacy & compliance A cookie/consent mechanism is in place if required in your audience's jurisdiction, and analytics respects the visitor's choice (see the privacy & cookie consent checklist ) The privacy policy accurately describes what's actually being tracked and why Data is not collected beyond what you actually need and can justify IP anonymization or equivalent privacy-preserving settings are enabled where your analytics tool supports it ⚠️ Privacy and consent requirements vary significantly by country and audience. Confirm what applies to your specific situation with a qualified professional rather than assuming a default configuration is compliant. Reporting to stakeholders Reports are kept simple enough that the people who need the data actually read and use it, rather than a dashboard nobody opens The metrics being reported are the ones that actually matter to the business's goals, not just whatever's easiest to pull Context is included alongside numbers—a metric without an explanation of what changed and why is rarely actionable Ongoing use A regular cadence is set for actually reviewing analytics—collecting data nobody looks at isn't useful Search Console's performance, coverage and Core Web Vitals reports are checked periodically, not just at setup Reports are cross-checked occasionally against a second source to catch tracking that's silently broken Historical data is preserved when switching or upgrading analytics platforms, rather than accepting a clean break that erases the ability to compare against past performance Segment- or channel-level performance (which traffic sources, which pages) is reviewed periodically, not just the site-wide total, since an overall average can hide a channel that's quietly underperforming Pair analytics setup with the technical SEO checklist for Search Console fundamentals, the conversion & forms checklist for what to actually do with the data once you have it, and revisit it as part of post-launch maintenance . --- # Conversion and Forms Checklist: Trust and Friction Conversion & forms checklist Traffic that doesn't convert into a lead, a sale or a signed-up user is traffic that doesn't matter much to the business behind the site. This checklist covers the practical, honest levers for helping visitors actually complete the action a page exists for—not manipulative dark-pattern tactics, which erode trust and often backfire. Clarity of purpose Every important page has one clear primary action it wants a visitor to take, rather than competing calls to action pulling in different directions The value of taking that action is stated plainly—what does the visitor actually get, not just what do they have to do Calls to action use specific, direct language rather than vague filler ("Get your free quote" beats "Submit") Form design Forms ask only for information genuinely needed at that step—every additional field is measurable friction Field labels are always visible, not just shown as placeholder text that disappears once someone starts typing Input types match the data being collected (email, phone, number) so the correct keyboard and validation appear automatically, especially on mobile Multi-step forms show progress clearly, so a visitor knows roughly how much is left Autofill and autocomplete attributes are set correctly so returning visitors and password managers can fill fields reliably Errors & validation Validation errors are specific and explain exactly what to fix, not a generic "invalid input" Errors appear next to the relevant field, not only in a summary block disconnected from the form itself A validation error never silently clears fields the visitor already filled in correctly Submission failures (server error, network drop) show a clear message and don't lose the visitor's entered data Reducing friction A guest or account-free path exists wherever forcing account creation isn't genuinely necessary The number of steps in a checkout or signup flow is only as many as the process genuinely requires Unnecessary confirmation dialogs, extra clicks, or redundant re-entry of information already provided are removed Forms and key conversion paths have specifically been tested on mobile, where friction is felt most acutely (see the mobile checklist ) Trust signals Contact information, business details and any relevant credentials are easy to find, not hidden away Security and privacy are visibly addressed at the point a visitor is asked for sensitive information, not just buried in a linked policy Genuine social proof—real testimonials, case studies, honestly-earned reviews—is used rather than fabricated or exaggerated claims Pricing, costs and next steps are transparent before a visitor commits, not revealed as a surprise at the final step ⚠️ Never fabricate scarcity ("only 2 left!" when that's not true), fake countdown timers, or manufactured urgency. Beyond being dishonest, these dark patterns are increasingly the subject of consumer-protection regulation, and they damage trust the moment a visitor notices. Post-submission experience A clear confirmation appears immediately after submission—a visitor should never wonder whether their action actually worked Automated confirmation emails are tested end-to-end and confirmed to actually arrive (see the email deliverability checklist ) Next steps after conversion are made clear—what happens now, and when Measuring & improving Conversion events are tracked accurately so you can actually see what's working (see the analytics checklist ) Where a form or flow underperforms, the cause is investigated—a session recording or a direct look at where visitors abandon a flow beats guessing Changes to conversion-critical pages are tested deliberately, one meaningful change at a time, rather than several at once with no way to tell which one mattered See the mobile checklist for touch-friendly form design specifics, and accessibility for making sure forms work for every visitor, not just some. --- # Post-Launch Maintenance Checklist: Ongoing Routine Post-launch maintenance checklist Launch is a milestone, not a finish line. A website that isn't maintained slowly degrades—broken links accumulate, plugins go unpatched, content goes stale. This is the ongoing routine that keeps a site healthy long after the launch-day excitement fades. Weekly or biweekly Check uptime-monitoring alerts and confirm nothing has gone unnoticed Skim analytics for anything unusual—a sudden traffic drop, a spike in errors, a form that stopped converting Review and respond to any spam or moderation queues (comments, form submissions) Monthly Apply available software, plugin and theme updates, ideally testing on staging first for anything significant Check for new broken internal or outbound links Review Search Console for new crawl errors, manual actions or security issues Re-run a performance check on key pages and compare against the last check (see the performance checklist ) Confirm backups actually completed successfully—don't assume the schedule ran without checking Quarterly Test restoring a backup to confirm it genuinely works, not just that it exists Review top-performing and worst-performing pages in analytics and Search Console Audit older content for accuracy—outdated prices, dead links to other sites, superseded information Re-check SSL/TLS certificate status and security header configuration Review who has admin access and remove anyone who no longer needs it Re-check SPF/DKIM/DMARC records are still correct, especially if any email tools changed (see the email deliverability checklist ) Annually (or after any major change) Do a full re-run of the SEO , accessibility and security checklists, since standards and the site itself both evolve Reassess whether the site's structure and navigation still reflect current priorities Review legal pages (privacy policy, terms) for continued accuracy Re-evaluate hosting capacity against current and projected traffic Audit dependencies (plugins, libraries, integrations) and remove anything no longer maintained by its provider or no longer actually used Cost & vendor review Hosting, tool and service subscriptions tied to the site are reviewed periodically—it's common for a trial or a one-off project tool to keep billing long after it's stopped being used Each recurring cost is matched to a genuine, current need, not kept on purely out of inertia Vendor contracts and renewal dates are tracked somewhere visible, so a renewal or a price change isn't discovered as a surprise on the invoice Alternatives are periodically considered for any tool that's become notably more expensive or less useful than when it was first chosen Capacity & scaling Hosting resource usage is checked periodically, not only noticed once the site is already struggling under load Any known upcoming traffic spike (a sale, a press mention, a seasonal peak) is planned for in advance rather than discovered mid-event Database and media storage growth is tracked so a slow, creeping resource problem doesn't become a sudden outage Documentation & handover Login credentials, DNS access, hosting details and key vendor contacts are documented somewhere the whole responsible team can reach—not only in one person's head Any custom configuration, non-obvious workaround, or reason something was built a particular way is written down for whoever maintains the site next If responsibility for the site changes hands, a proper handover happens rather than an informal, incomplete one A simple written runbook exists for the most common maintenance tasks (deploying an update, restoring a backup, rotating a credential), so they don't depend entirely on one person's memory under pressure Content freshness Older, high-traffic pages are periodically reviewed and updated rather than left untouched indefinitely Genuinely outdated pages are either refreshed, consolidated, or retired with a proper redirect—not just left live and stale New content additions still follow the standards in the content checklist , not a rushed shortcut version 💡 Put maintenance tasks on an actual recurring calendar reminder rather than relying on memory. The sites that quietly decay are almost never the ones with a written schedule—they're the ones where maintenance was always going to happen "soon." See the security checklist for backup and update specifics, and analytics & tracking for what to actually look at when reviewing performance data. --- # Site Migration Checklist: Replatform Without Losing Rank Site migration & redesign checklist Migrating a domain, replatforming a CMS, or redesigning an existing site carries a specific risk a brand-new launch doesn't: you already have rankings, backlinks, indexed URLs and traffic to lose. This checklist covers the extra work a migration needs on top of everything in the pre-launch checklist . Before you start The reason for the migration is clear—a redesign, a new CMS, a new domain, consolidating multiple sites—since that shapes what actually needs to be preserved A full crawl of the existing site is taken and archived before anything changes, using a site crawler (such as Screaming Frog SEO Spider, free for small sites) to capture every current URL, title, meta description and status code Current analytics and Search Console data is exported and archived as a baseline to compare against after launch A list of the site's highest-traffic and highest-value pages is identified specifically, so they get extra attention and verification later URL & redirect mapping Every old URL is mapped to its new equivalent in a spreadsheet before development starts, not improvised page by page during launch Redirects are 301s (permanent) for genuinely permanent moves, pointing to the single most relevant new page—not a blanket redirect of every old URL to the new homepage There are no unnecessary redirect chains (old URL → interim URL → final URL should be old URL → final URL directly) URLs that no longer have any reasonable equivalent are handled deliberately—either redirected to the closest relevant page or allowed to 404 on purpose, not left as an accidental broken link ⚠️ A missed or mishandled redirect map is the single most common cause of a migration losing search rankings and referral traffic. Budget real time for building and verifying this map—it isn't a five-minute afterthought on launch day. Content & structure changes If page content, headings or structure are changing significantly, the change is deliberate—not an accidental byproduct of a template swap Pages that are being consolidated or removed are redirected to the single best remaining page covering that topic Internal linking is rebuilt for the new structure, not left pointing at old, since-redirected URLs throughout the new site Structured data is re-implemented and re-validated on the new platform, not assumed to carry over automatically (see the structured data checklist ) Technical validation on staging The new site is fully built and tested on a staging environment that's blocked from public indexing before anything goes live Every item in the pre-launch checklist and QA & cross-browser checklist is run against the new site specifically, not assumed carried over from the old one Redirects are tested in bulk before launch, not spot-checked on a handful of pages Sitemap, robots.txt and canonical tags on staging are confirmed correct for when they go live—and confirmed staging itself isn't accidentally left indexable Launch & cutover Take a final backup and export of the outgoing site immediately before cutover Deploy the new site and redirects together—never leave a gap where old URLs 404 before redirects are live Confirm DNS, SSL and email-sending records (SPF/DKIM/DMARC) all survived the change intact—see the email deliverability checklist Spot-check a meaningful sample of redirects on the live domain immediately after cutover, not just on staging Resubmit the sitemap in Google Search Console under the correct property once the new site is live Post-migration monitoring Search Console coverage and performance reports are checked daily for the first couple of weeks, watching specifically for a spike in 404s or a drop in indexed pages Organic traffic and rankings for the previously identified high-value pages are compared against the pre-migration baseline Server logs or analytics are checked for 404s hitting old URLs that weren't caught in the original redirect map, and gaps are patched promptly Any drop in traffic or rankings is investigated immediately rather than dismissed as normal fluctuation—the earlier a migration issue is caught, the easier it is to fix Pair this with the technical SEO checklist for the underlying redirect and indexing mechanics, and the launch day checklist for the general go-live sequence. --- # WordPress Checklist: Updates, Plugins and Security WordPress checklist WordPress powers a huge share of the web, and most of the general checklists on this site apply to a WordPress site exactly as written. This page covers what's genuinely specific to the platform: how its update model, plugin ecosystem and hosting choices create their own set of risks and routines. In keeping with this site's general approach, tool categories are described generically rather than naming specific plugins—the plugin landscape shifts constantly, and the right choice depends on your host and needs. Core, theme & plugin updates WordPress core, the active theme, and every installed plugin are kept on their current, patched versions Updates are tested on a staging copy before applying to production for anything beyond a routine minor release, since a plugin update can break a live site with no warning Automatic updates are considered for security-critical, low-risk updates, with a documented process for reviewing anything higher-risk manually A rollback plan exists (a recent backup, or version control on custom code) before applying any update that touches core functionality Plugin hygiene Every installed plugin serves a genuine, current purpose—plugins installed for a one-off need and forgotten are pure attack surface with no upside Deactivated plugins are actually deleted, not left dormant—a deactivated plugin's code is often still present and can still be a vulnerability New plugins are chosen based on active maintenance and a track record of prompt security updates, not just feature list or popularity alone The total number of plugins is kept as low as the site genuinely needs—each one is both a performance cost and a security dependency Performance A caching solution is in place, appropriate to the hosting environment, so pages aren't regenerated from the database on every single request Image optimization is handled at the CMS level so editors uploading full-size photos doesn't silently degrade site speed over time (see the image optimization checklist ) The theme and page-builder setup are checked for unnecessary bloat—unused blocks, widgets and scripts loaded on every page regardless of need Database tables are kept reasonably tidy—old post revisions, spam comments and abandoned draft content are cleaned out periodically rather than accumulating indefinitely Security hardening The default admin username is never used; every account has a unique, strong login and, where supported, multi-factor authentication Login attempts are rate-limited or otherwise protected against automated brute-force attacks, which specifically and heavily target WordPress's standard login URL File editing from within the WordPress admin is disabled where practical, so a compromised admin account can't be used to directly edit theme or plugin code User roles are assigned deliberately—most accounts don't need full administrator access, and the number of full admins is kept to the minimum genuinely required REST API and XML-RPC access are reviewed for whether they're actually needed as configured, since both are common attack vectors when left wide open unnecessarily Backups Backups cover both the database (posts, pages, settings) and the files (uploads, theme, plugins), since a WordPress site needs both to actually be restorable Backups run automatically on a schedule matched to how often content changes, and are stored somewhere separate from the hosting account itself A restore has genuinely been tested, not just assumed to work because the backup file exists (see the security checklist ) Content & editorial workflow Editor accounts have access appropriate to their actual role, rather than everyone defaulting to administrator for convenience A consistent process exists for reviewing content before publishing, especially on multi-author sites Media library uploads are checked periodically for unused files bloating storage and slowing backups 💡 Most of the value in a WordPress-specific routine is discipline, not exotic configuration: fewer plugins, faster updates, tested backups, and accounts locked down to what people actually need. The general security and maintenance checklists apply in full alongside this one. Everything in the performance , security and maintenance checklists applies to WordPress sites too—this page covers what's genuinely additional, not a replacement for them. --- # Local SEO Checklist: Google Business Profile and NAP Local SEO checklist If your business serves customers in specific places—a shop, a service area, a clinic—local search visibility often matters more than generic national rankings. This checklist covers the fundamentals specific to local search. Google Business Profile A Google Business Profile is claimed and fully verified for the business Business name, address, phone number and hours are accurate and match what's on the website exactly The correct primary and secondary business categories are selected The profile includes accurate photos, a clear business description, and up-to-date hours (including holiday hours) Products or services are listed on the profile where the platform supports it The profile is checked periodically for suggested edits from Google or the public, since incorrect crowd-sourced edits can slip through unnoticed NAP consistency Name, Address and Phone number ("NAP") are identical, character for character, everywhere they appear—website, Google Business Profile, and any directory listings A visible, consistent NAP appears on the website itself, typically in the footer or a dedicated contact page Any old or outdated address/phone listings from a previous location or number have been corrected or removed where possible Local structured data LocalBusiness (or a more specific relevant type) Schema.org markup is added to the site with accurate name, address, phone and hours (see the structured data checklist ) Structured data is validated with Google's Rich Results Test If there are multiple locations, each has its own accurate structured data, not one generic block reused everywhere Local landing pages Businesses with multiple locations have a genuine, individually useful page per location—not a thin, templated page differing only by city name Each local page includes real, location-specific information: address, hours, directions, local service details Local pages are linked from the main navigation or a locations page, not orphaned Multi-location management Each location has its own verified Google Business Profile, not one shared profile trying to represent multiple addresses A consistent process exists for keeping hours, contact details and staffing information current across every location, especially around holidays and closures Location pages are differentiated with genuinely distinct content—local landmarks, service nuances, staff—rather than a single template with only the address swapped Adding, closing or relocating a site is reflected promptly everywhere it's listed, not just on the primary website Citations & directories The business is listed on major, relevant directories with consistent NAP information Outdated or duplicate listings from a previous address, name or phone number have been identified and corrected or removed Industry-specific directories relevant to your business type are considered, not just general-purpose ones Reviews There's a genuine, straightforward process for happy customers to leave a review—not incentivized or fabricated reviews, which violate most platforms' policies and damage trust Reviews, including negative ones, are responded to professionally and promptly Review responses address the actual substance of the feedback rather than a copy-pasted generic reply ⚠️ Never fabricate reviews, buy fake reviews, or offer incentives explicitly for positive-only reviews. Beyond being dishonest, it violates the policies of virtually every major review platform and can get a listing suspended. Local content & link building Content genuinely reflects local relevance—community involvement, local service areas, local events—rather than a generic national page with a city name inserted The site clearly communicates the actual service area or delivery/coverage radius Local link-building focuses on genuine relationships—local news coverage, sponsorships, industry associations—rather than low-quality directory spam Map & "near me" search considerations The business's category, attributes and description are specific enough that it can plausibly surface for genuine "near me"-style searches relevant to what it actually offers Directions, parking information and accessibility details are included where they'd genuinely help someone arriving in person Business hours are kept accurate in real time, including temporary closures—an inaccurate "open now" status sends someone to a locked door and damages trust Location pages load quickly and work well on mobile, since map-based and "near me" searches happen overwhelmingly on a phone, often while someone is already out and about Service-area businesses without a public storefront communicate their actual coverage area clearly, rather than implying a physical location that doesn't genuinely serve walk-in customers Photos on the profile and website are genuine and current—an outdated storefront photo or a since-changed interior undermines trust the moment a visitor arrives Pair this with the general on-page SEO checklist and technical SEO checklist , both of which apply just as much to local sites, and with the international SEO checklist if you serve more than one country or region. --- # International SEO Checklist: Hreflang and Localization International & multilingual SEO checklist Serving more than one country or language adds a layer of technical and editorial complexity on top of everything else on this site. Get it wrong and you risk showing the wrong language to the wrong audience, or splitting your own site's authority against itself. URL structure for languages & regions A clear, consistent URL pattern is chosen for language/region variants—separate country-code domains, subdomains, or subfolders—and used consistently across the whole site Every localized version of a page has its own indexable URL—content isn't swapped dynamically based on browser or IP detection with no distinct URL for each version URL structure decisions are made early, since changing them later means redirect work across every localized page at once hreflang implementation Every localized page includes hreflang annotations pointing to itself and to every other language/region version of that same page hreflang values use correct language codes, and region codes only where the content is genuinely region-specific rather than just language-specific An x-default value is set to indicate the fallback version for visitors who don't match any specific targeted language or region hreflang annotations are reciprocal—if page A points to page B, page B points back to page A—since one-directional hreflang is commonly ignored hreflang is validated after any redesign or migration, since it's easy to silently break during a template change Content localization Content is genuinely translated and adapted for the audience, not a raw, unedited machine translation presented as finished copy A native or fluent speaker reviews translated content before it goes live, particularly for anything customer-facing or making factual claims Region-specific details—currency, units, date formats, local contact information, local regulations—are actually adapted, not just the running text Idioms, examples and cultural references are adapted rather than translated literally, where a literal translation wouldn't make sense to the local audience ⚠️ Auto-translated content presented without review is a common, avoidable source of embarrassing or actively incorrect claims on a site's international pages. If full human review of every page isn't feasible, prioritize the highest-traffic and highest-stakes pages first. Technical & UX considerations A visible, easy-to-find language/region switcher is available on every page, not just the homepage The switcher links directly to the equivalent localized page, not just to the target language's homepage, wherever an equivalent page exists Automatic redirection based on browser language or IP location is avoided, or at minimum never blocks a visitor from reaching a version they explicitly choose Each localized version has its own accurate title, meta description and structured data—not a single set duplicated verbatim across every language Local search & compliance Each targeted region's dominant search engine and its specific requirements are considered, not just Google if the audience genuinely uses something else Local business listings and structured data are localized per region where the business genuinely operates there (see the local SEO checklist ) Legal and privacy pages reflect requirements in each targeted jurisdiction, not just the site's home country (see the privacy checklist ) Monitoring Search Console is set up to allow monitoring indexing and performance per targeted country/language, not just aggregated globally Rankings and traffic are reviewed per region, since a healthy global average can hide one specific market performing poorly hreflang and indexing status are spot-checked periodically, since these are easy to silently break during ordinary site updates Pair this with the technical SEO checklist for the underlying crawlability fundamentals and the content checklist for what makes localized content genuinely useful rather than just technically present. --- # E-Commerce Checklist: Product Pages and Checkout Trust E-commerce checklist Online stores carry everything from the general checklists on this site, plus a set of commerce-specific concerns where small mistakes directly cost sales. This checklist covers what's distinct about running a store. Product pages Every product has a unique, descriptive title and a genuinely useful, non-duplicated description—not just the manufacturer's boilerplate copied across every retailer that sells it Pricing, availability and variant options (size, color) are accurate and clearly displayed Multiple, high-quality product images are provided, including any angles or details a buyer would want before purchasing sight-unseen Product pages clearly show shipping cost or delivery estimate information, or link clearly to where that's explained Related and complementary products are suggested where genuinely relevant, not as generic filler Product structured data Product Schema.org markup is added with accurate price, availability and, where genuine, review/rating data (see the structured data checklist ) Structured data is kept in sync automatically with actual inventory and pricing—stale markup claiming an out-of-stock item is available is a real trust and compliance risk Markup is validated with Google's Rich Results Test Checkout & payment trust Checkout runs entirely over HTTPS with no mixed-content warnings Accepted payment methods are clearly displayed before checkout, not discovered as a surprise at the final step Total cost—including shipping and any fees or taxes—is shown clearly before the final purchase step, not sprung on the customer at the last screen A guest checkout option exists, or the reason an account is required is made clear Trust signals—secure-checkout indicators, clear contact information, recognizable payment logos—are visible during checkout Cart & conversion basics The cart clearly shows item, quantity, price and how to edit or remove items without confusion Checkout has as few unnecessary steps and form fields as the process genuinely requires (see the conversion & forms checklist ) Error messages during checkout (declined card, out-of-stock item) are specific and explain what to do next Cart and checkout have specifically been tested on mobile, where a meaningful share of shopping traffic happens Abandoned cart & lifecycle email Abandoned-cart and post-purchase emails are sent through a properly authenticated path so they actually reach the inbox (see the email deliverability checklist ) Abandoned-cart messaging is genuinely helpful—a reminder with accurate cart contents—rather than manipulative urgency that doesn't reflect real stock levels Order confirmation, shipping and delivery emails are tested end-to-end and confirmed to arrive reliably Fraud & risk basics Payment processing goes through a reputable processor rather than handling raw card data directly on your own server Order review or fraud-screening tools appropriate to your order volume and risk level are in place Refund, chargeback and dispute processes are documented and understood by whoever handles customer service Policies & support pages Shipping information (costs, timeframes, regions served) is published clearly and easy to find A returns and refund policy is published and written in plain language Customer service contact information is easy to find from any page, not buried Policies are accurate and actually match how the business operates—not aspirational copy nobody follows Store-wide SEO Category pages have unique, useful content and aren't just a bare product grid with no descriptive text Out-of-stock or discontinued products are handled deliberately—either kept live with clear status and alternatives, or properly redirected, rather than left as broken dead ends Faceted navigation (filters by size, color, price) doesn't generate large volumes of thin, near-duplicate indexable URLs If the store sells or ships internationally, localized pricing, currency and content follow the international SEO checklist Marketplace & product feed considerations If the store submits a product feed to a shopping platform or marketplace, feed data (price, availability, images, identifiers) matches what's actually on the live page exactly Product feeds are regenerated or refreshed on a schedule that reflects how often pricing and stock actually change, not left stale for long stretches If the store also sells through third-party marketplaces, inventory and pricing are kept genuinely in sync across every channel to avoid overselling or price mismatches Product identifiers (SKUs, barcodes) are consistent across the website, feeds and any marketplace listings, rather than diverging over time Category and attribute mapping between the site and any external feed is checked periodically, since a mismatch can quietly cause products to be misclassified or rejected by a platform Everything in the on-page SEO , performance and security checklists applies to a store as well—an online shop simply has less room for error, since every friction point has a direct cost. --- # Common Website Launch Mistakes and How to Avoid Them Common website launch mistakes Most launch problems aren't exotic—they're the same handful of avoidable mistakes, repeated across countless otherwise-well-built sites. Here's the condensed list of what most often goes wrong, and where to find the full checklist for each. Technical mistakes Leaving a staging noindex tag or blanket robots.txt block in place after going live, which can quietly keep the whole site out of search results for weeks before anyone notices (see technical SEO ) Forgetting redirects when URLs change, breaking every old bookmark, backlink and search listing pointing at the site (see technical SEO and site migration ) No working, tested backup at the moment something actually breaks (see security ) Letting the SSL certificate expire unnoticed, which can lock every visitor out with a browser warning (see security ) Skipping a custom 404 page , leaving visitors stranded on a dead end with no way back Losing SPF/DKIM/DMARC records during a host or DNS change , silently sending every outgoing email straight to spam (see email deliverability ) SEO & content mistakes Duplicate or missing meta descriptions and title tags copied across every page instead of written per page (see SEO checklist ) Thin or padded content written to fill space rather than genuinely help the reader (see content checklist ) Inventing statistics or claims to make content sound more authoritative—a fast way to lose trust once anyone checks Ignoring internal linking , leaving important pages orphaned with no path leading to them Launching, then never updating content again —stale prices, dead outbound links and outdated information accumulate silently Structured data that doesn't match the visible page —an inflated rating or a price that doesn't match checkout (see structured data ) Design & UX mistakes Designing and testing only on desktop , then discovering mobile layout problems after launch (see mobile checklist ) Touch targets too small or too close together to tap reliably on a real phone Intrusive pop-ups that are difficult to dismiss, especially on mobile screens Relying on color alone to convey meaning, which fails for colorblind users and anyone with a low-quality screen (see accessibility checklist ) Forms that ask for more than they need , adding friction that quietly costs conversions (see conversion & forms ) Process mistakes Setting up analytics after launch instead of before, permanently losing the launch-period baseline (see analytics checklist ) No second reviewer checking the site end to end before go-live—the person who built it is the worst-positioned person to catch what they've stopped noticing Treating launch as the finish line rather than the start of an ongoing maintenance routine (see maintenance checklist ) No plan for who handles an incident —a security issue or outage discovered with nobody clear on the next step Migrating or redesigning without a redirect map , discovering broken URLs and lost rankings only after traffic has already dropped (see site migration checklist ) Compliance & communication mistakes Launching a cookie banner that doesn't actually respect the visitor's choice , still firing every tracker regardless of what was declined (see privacy & cookie consent ) Never testing that transactional email actually arrives , discovering only after launch that order confirmations or password resets are landing in spam (see email deliverability ) Nobody outside the build team reviewing the site before launch , so problems obvious to a fresh pair of eyes ship anyway No agreed rollback threshold for launch day , leaving the team improvising under pressure if something does go wrong (see launch day checklist ) Secrets or API keys committed to a public repository , discovered only once something is already abused (see security checklist ) Auto-translated pages published without human review , quietly making incorrect or embarrassing claims to an entire market (see international SEO checklist ) ⚠️ If you only fix one thing after reading this page, check that the live domain isn't still carrying a leftover noindex tag or a Disallow: / in robots.txt from staging. It's the single most common, most damaging, and most avoidable launch mistake on this entire list. Every mistake above links back to its full checklist—work through the pre-launch checklist and launch day checklist to catch these before they happen, not after. --- # About Website Checklist: Our Approach and Standards About Website Checklist Website Checklist is a free, independent reference for the practical work of launching and maintaining a website—covering pre-launch, SEO, performance, accessibility, security and everything in between. It exists because good launches usually come down to not missing the boring, unglamorous details. Who this is for Freelancers and independent developers who want a repeatable launch process Small-business owners managing their own website without a dedicated technical team Agencies looking for a shared checklist to standardize launches across clients Anyone maintaining an existing site who wants a structured way to audit it Teams planning a migration, redesign or replatform who need to know what's genuinely at risk Anyone brought in partway through a project—a new hire, a contractor picking up someone else's site—who needs a fast, reliable way to see what's actually been done and what hasn't The checklists are deliberately organized by concern rather than by role, since the same page often gets used by a developer checking technical details and a business owner sanity-checking the result—both should be able to follow it. Our approach Platform-neutral: the advice applies whether you're hand-coding a site or using any content-management platform—we don't assume or push a specific product. Where something is genuinely platform-specific, like the WordPress checklist , it's called out separately rather than mixed into the general advice; No invented numbers: we don't cite specific statistics we can't stand behind. Where a claim would need a source we don't have, we describe the general, well-established principle instead; Generic over branded: where a category of tool is genuinely useful (a site crawler, an accessibility checker, a speed-testing tool), we describe the category rather than push a specific paid product; well-known free tools are named only when we're confident they're real, current and genuinely useful; Evergreen, not trend-chasing: the fundamentals here—semantic HTML, real HTTPS, genuine accessibility, honest content—don't go out of date the way specific tool recommendations do. What this site is not Not legal, tax or accessibility-compliance advice—requirements vary by jurisdiction and business type, so confirm specifics with a qualified professional; Not affiliated with any hosting provider, CMS, plugin, theme or SEO tool mentioned or implied anywhere on the site; Not a guarantee of search rankings—no checklist can promise that, and anyone who claims otherwise is selling something. Corrections Best practices evolve—particularly around performance metrics, accessibility standards, privacy regulation and search-engine guidance. If something here goes stale, it should be updated rather than left to quietly mislead people; that's the whole point of an evergreen reference. Start with the pre-launch checklist , or see the FAQ for quick answers. --- # Website Checklist FAQ: Quick Launch and SEO Answers FAQ Quick answers to the questions we hear most. Each links to a fuller checklist if you want the whole picture. What's the single most important thing to check before launching a website? Confirm the live site isn't still blocked from search engines by a leftover staging noindex tag or a Disallow: / in robots.txt—see common mistakes and the technical SEO checklist . It's the most common and most damaging launch mistake. What are Core Web Vitals? Google's three page-experience metrics: LCP (how fast the main content loads), INP (how responsive the page feels to interact with), and CLS (how much the layout unexpectedly shifts while loading). See the performance checklist . How often should a website be maintained after launch? Some tasks (uptime checks, spam moderation) are weekly; others (updates, backup verification) are monthly; deeper reviews (full SEO and security re-checks) are quarterly or annual. See the post-launch maintenance checklist for the full cadence. Do I need a sitemap and a robots.txt file? Yes, for essentially every site. An XML sitemap helps search engines discover your pages; robots.txt tells them what not to crawl. Both are covered in the technical SEO checklist . What's the difference between on-page SEO and technical SEO? On-page SEO covers content-level choices on each page—titles, headings, meta descriptions (see the SEO checklist ). Technical SEO covers whether search engines can crawl and index the site at all—sitemaps, redirects, structured data (see the technical SEO checklist ). Is HTTPS actually necessary for a small website? Yes. Browsers actively flag non-HTTPS sites as "not secure," it protects visitor data in transit, and it's effectively a baseline requirement rather than an optional extra today. See the security checklist . What does 'accessible' actually mean for a website? That people using screen readers, keyboard-only navigation, or accessibility settings like larger text or higher contrast can genuinely use the site—not just that it looks fine to a sighted mouse user. See the accessibility checklist . Should analytics be set up before or after launch? Before. Setting it up after launch permanently loses your launch-period baseline data, which you generally can't recreate later. See analytics & tracking setup . Does this site cover e-commerce and local business sites specifically? Yes — see the dedicated e-commerce checklist and local SEO checklist for concerns specific to online stores and location-based businesses. What are SPF, DKIM and DMARC, and do I need them? They're DNS records that let receiving mail servers verify your outgoing email is genuinely from you, rather than spoofed. Without them, contact-form notifications, receipts and password resets are far more likely to land in spam—or be forged by someone else. See the email deliverability checklist . Is this site's advice GDPR or CCPA compliant? This site describes general practical groundwork—knowing what data you collect, honest cookie consent, an accurate privacy policy—that's useful regardless of which specific law applies to you. It is not legal advice and can't tell you which regulations actually apply to your business. See the privacy & cookie consent checklist and confirm specifics with a qualified professional. What's the biggest risk when migrating or redesigning an existing site? Losing search rankings and referral traffic because old URLs weren't properly mapped to new ones with 301 redirects. A missed redirect map is the single most common cause of a migration going badly. See the site migration & redesign checklist . Does WordPress need a different checklist from other platforms? Most of this site's advice applies to WordPress exactly as written. A few things are genuinely platform-specific—plugin hygiene, core/theme update discipline, and WordPress-specific attack vectors like brute-forced logins. See the dedicated WordPress checklist . What's the fastest way to improve a slow website? For most content-heavy sites, image optimization has the single biggest visible impact—compressing images, sizing them correctly, and lazy-loading what's off-screen. See the image optimization checklist and the broader performance checklist . Is any of this legal or compliance advice? No. Privacy, accessibility and consumer-protection requirements vary by jurisdiction and business type. This site covers general best practice; confirm specific legal obligations with a qualified professional. See about this site . ---