The Technical Checklist Every Website Should Pass Before It Ships

A website can look completely finished and still be technically broken in ways nobody notices until it matters. The visual layer is the part every stakeholder reviews. The technical layer underneath is the part that decides whether the site is fast, findable, secure, accessible, and observable, and it usually ships unreviewed because no one is looking directly at it.

This checklist covers what should be true of any production website before it goes live, and, more importantly, why each item earns its place. A checklist without reasons gets followed until it becomes inconvenient. A checklist with reasons gets followed because the team understands the specific cost of skipping an item. Run it before launch, and run it again after every significant change.

Largest Contentful Paint should land under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. These three Core Web Vitals are not arbitrary numbers. They are the thresholds Google uses as a ranking signal and the points at which user-perceived performance crosses from acceptable to frustrating. A site that fails them loses organic traffic and converts the traffic it keeps at a lower rate.

Every image should be served in a modern format such as WebP or AVIF, sized responsively for the device requesting it, and given explicit width and height attributes. The format and sizing reduce the bytes transferred, which is the single largest lever on load time for most sites. The explicit dimensions reserve layout space before the image arrives, which is what stops content from jumping as the page loads and is the most common cause of a failing CLS score.

JavaScript should be on a budget and split by route, so a visitor downloads the code for the page they are on rather than the entire application. JavaScript is the most expensive resource a browser handles, because it must be downloaded, parsed, and executed on the main thread. Unsplit bundles are the usual reason a page paints quickly but feels unresponsive for a second or two afterward, which is exactly what a poor INP score measures. Fonts should be preloaded and declared with font-display swap, so text appears immediately in a fallback face instead of staying blank until the web font arrives.

The rendering strategy should be chosen per page type, not adopted wholesale for the entire site. Static generation suits marketing and content pages, where the HTML can be built once and served from a CDN edge with no server work per request. Server rendering suits pages that are personalized or change on every request. Client rendering suits authenticated application views behind a login. The wrong choice is expensive in both directions: statically rendering a personalized page serves stale content, and client-rendering a marketing page hands search engines an empty shell and the visitor a slow first paint.

Static and cacheable assets should be served from a CDN with correct cache-control headers, and text responses should be compressed with Brotli or gzip. The CDN places content geographically close to the visitor, which removes most of the network latency that a single server location would otherwise add. Cache headers let browsers and edge nodes avoid re-fetching things that have not changed. Compression reduces transfer size for HTML, CSS, and JavaScript by a large margin at negligible cost. All three are standard, cheap, and still routinely missing.

Every page needs a unique, descriptive title tag and meta description. These are what search engines display in results and what largely decides whether a ranked page is actually clicked. Duplicated or templated titles across pages cause search engines to treat the pages as interchangeable and rank none of them well.

The HTML should be semantic, with a single h1 per page and a heading hierarchy that does not skip levels. Search engines and screen readers both use heading structure to understand what a page is about and how it is organized. A page built entirely from generic div elements is legible to a sighted human and close to meaningless to everything else that reads it.

The site needs a canonical tag on every page, an XML sitemap, and a robots.txt that does not accidentally block what should be indexed. Canonical tags tell search engines which URL is authoritative when the same content is reachable by multiple paths, which prevents the ranking signal from being split. The sitemap and robots file govern what gets crawled at all. A single overzealous robots.txt rule has removed entire sites from search results, and it usually goes unnoticed for weeks.

Structured data should be added wherever the page type supports it: organization, product, article, FAQ, breadcrumb. This JSON-LD markup is how a page becomes eligible for rich results, the enhanced listings that take up more space and earn a higher click-through rate than a plain text link. URLs should be readable and stable, and internal links should not point at 404s or run through chains of redirects, each of which wastes crawl budget and leaks a little ranking signal.

The entire site must be served over HTTPS, with HTTP requests redirected and an HSTS header instructing browsers to refuse the insecure version in future. HTTPS is now a baseline expectation: browsers label plain HTTP pages as not secure, and any form submitted over HTTP can be read in transit. HSTS closes the brief window during that first redirect where a downgrade attack is still possible.

A set of security response headers should be present: a Content-Security-Policy that constrains where scripts and resources may load from, X-Content-Type-Options to stop MIME-type sniffing, a frame-ancestors policy to prevent clickjacking, and a sensible Referrer-Policy. Each closes a specific, well-documented class of attack. A strong Content-Security-Policy in particular is the most effective single defense against cross-site scripting, because it limits the damage even when a malicious script is injected.

No secret, API key, or credential should ever be present in the client-side bundle, because anything shipped to the browser is readable by anyone who opens developer tools. All user input should be validated and sanitized on the server regardless of any client-side checks, since client validation is a usability feature and not a security boundary. Public forms and API endpoints should be rate-limited to blunt automated abuse, and dependencies should be scanned for known vulnerabilities as part of the build, because most real-world compromises now arrive through an outdated package rather than original code.

Every interactive element must be reachable and operable by keyboard alone, with a visible focus indicator showing where the keyboard currently is. A meaningful share of users never use a mouse, whether by preference, motor impairment, or because they rely on a screen reader. A control that only responds to a mouse click is effectively invisible to them. This is also a legal exposure: accessibility lawsuits are now common, and an inaccessible site is a standing liability rather than a missing nicety.

Text must meet a contrast ratio of at least 4.5 to 1 against its background, every meaningful image needs appropriate alt text, and every form field needs a programmatically associated label. Contrast decides whether low-vision users, and anyone reading in bright sunlight, can make out the page at all. Alt text is the only thing a screen reader can convey about an image. An unlabeled field is announced as an unnamed edit box, which makes a form close to impossible to complete without sight. A prefers-reduced-motion media query should disable non-essential animation for users whose system has requested it, since motion can trigger genuine physical discomfort.

The site needs analytics that capture not only page views but the conversion funnel: which steps visitors reach, where they drop, and which calls to action they interact with. Page-view counts confirm that traffic happened. Event and funnel tracking reveals what the traffic actually did, which is the only data that can guide a real improvement. A site without it is optimized by opinion.

Client-side error monitoring should be in place, so JavaScript exceptions in real users' browsers are reported rather than failing silently. A bug that breaks a form on one browser version can suppress conversions for weeks, and without error monitoring the first visible signal is a quiet revenue decline that nobody can explain. Uptime monitoring should alert the team when the site is unreachable, ideally before a customer is the one to report it.

Real-user monitoring should record actual Core Web Vitals from real visitors, not only lab scores from a single test run. Lab numbers are measured on fast hardware and good networks, while real users span a wide range of both, and the gap between the two is often large. Server logs should be structured and retained, because when an incident happens, logs are the difference between a diagnosis in minutes and a guess that takes days.

Forms are where most websites actually convert, and they are also where the most revenue quietly leaks. Every form needs server-side validation with clear, specific, inline error messages, so a visitor who makes a mistake is told exactly what to fix rather than left staring at a generic failure. Vague errors are a common and measurable cause of abandonment among visitors who were otherwise willing to complete the form.

Form submissions must be delivered reliably and stored, not merely emailed to an inbox where a single mail filter or mail outage loses leads with no trace. Submissions should be persisted to a database or CRM as the source of truth, with notification treated as a secondary channel. Forms also need spam protection that does not punish real users, visible success and error states that confirm what happened, and error messaging that is announced to assistive technology rather than only shown visually.

The site should deploy through an automated pipeline that runs the test suite and a build check before anything reaches production, with a staging environment kept separate from production. Manual deploys are how untested code and broken builds reach live users. A pipeline makes the safe path the default path. There should also be a fast, rehearsed way to roll back, because the question is never whether a bad deploy will happen but how quickly it can be undone.

Production needs regular, tested backups, because a backup that has never been restored is a hope rather than a safeguard. The site should serve its own custom 404 and 500 pages that keep the visitor oriented and offer a way forward, instead of a raw server error. Any configuration that differs between environments, and every secret, should be supplied through environment variables, never committed into the repository.

None of these items is exotic, and none requires a large budget. Together they are the difference between a site that merely renders and one that is genuinely production-grade: fast, discoverable, secure, usable by everyone, and observable when something goes wrong.

The reason the list is worth writing down is that every item on it is invisible until it fails, and by then it fails in front of customers, search engines, or attackers. A site does not stay production-grade on its own. It passes this checklist on launch day and then drifts, one unreviewed change at a time, unless the team makes running it again a habit.