Checklist: 47 checks before launching your website

The 47 checks we perform before moving a website to production: redirects, indexing, Core Web Vitals, accessibility, and Spanish legal requirements. In PDF.

Before going live, you must verify 47 points across eight blocks: backup and environment, content and URLs, redirects, indexing, performance, accessibility, Spanish legal obligations, and handover. It is completed in full, in order, and with an assigned responsible person for each line. A launch is a checklist, not a leap of faith.

A launch almost always goes wrong for the same reason: no one wrote the list. DNS is changed on a Thursday afternoon, the site loads, everyone sighs in relief, and three weeks later, organic traffic has dropped by half because the testing robots.txt traveled to production intact.

This is the list we use. It is designed to be printed, hung on a wall, and crossed off by hand. We publish the whole thing because a checklist kept hidden protects no one.

Regulations and thresholds verified as of 08-27-2026: Core Web Vitals thresholds (web.dev), AEPD cookies guide (May 2024 version), Law 34/2002 (LSSI-CE) arts. 10 and 22, Law 11/2023 on accessibility, and Google Search Central documentation on migrations and indexing. Recheck the legal lines if you launch more than six months after this date.

How to use this list

Each line has three states: green, red, or "not applicable." There is no amber. A half-finished check is a red check.

Each line also has a name and surname next to it. Not a team: a person. And a specific cutoff time.

We perform it twice: once at T-7 days, with margin to fix whatever comes up, and again at T-0, just before moving the DNS. The first pass finds the underlying issues; the second, those introduced by someone on the last day.

Industry standard: The average Spanish studio launches when "the client gives the go-ahead on the design" and leaves the technical checks for later, with the site already live and traffic coming in. Our criteria: We launch when all 47 lines are green. For us, the design go-ahead is just one more line, not a substitute for the other 46.

Block 1 · Before touching anything (6 checks)

• Full backup of the old site: database, files, and server configuration, downloaded and restored in a testing environment to confirm that the backup is functional
• Dump of the current URL map with its traffic and incoming links, exported to a file, not a browser tab
• Record of positions and traffic from the last 12 months saved as a baseline: without a baseline, there is no way to prove whether the redesign has worked
• Launch window agreed upon in writing, outside of weekly peak traffic hours and with at least one business day ahead
• Rollback plan written on one page: who executes it, which commands, how long it takes
• Access to the repository, DNS panel, hosting, and CMS in the client's hands before the launch, not after

The sixth one is the most debated and the one we negotiate the least. The day something goes down, that access must already exist.

Block 2 · Content and URLs (8 checks)

• Every new page has its equivalent in the old map, or an explicit decision that it is being removed
• Unique title tags on all indexable pages, reviewed one by one, not generated in bulk
• Meta descriptions written for at least the 20 pages with the most traffic
• One H1 per page, and the H1 must state what the page does
• Images with real alternative text; decorative ones with empty alt
• No filler text or test content: global search for "lorem", "test", "example", and the project's codename
• Internal links pointing to final URLs, without going through redirects
• URLs in lowercase, without accents, without session parameters, and with a unique criterion for the trailing slash

A page that disappears without anyone having decided it is not cleaning up: it is a loss. Every URL that drops from the new map needs a signature behind it and a line in the redirection table.

Block 3 · Redirects (6 checks)

This is where positioning is lost, and it is lost in silence. Google publishes three specific instructions for a migration with a URL change: use permanent server-side redirects, "301 and 308"; keep them "for at least one year"; and redirect directly to the final destination, without chains.

• Complete redirection table, old URL to new URL, reviewed line by line and not by wildcard
• All return 301 or 308, verified with a real request, not with theoretical configuration
• Zero chains: no redirect points to another redirect
• No redirect leads to the homepage by default; if there is no equivalent, it is a 410 or a page with a useful alternative
• Domain variants resolved: with and without www, HTTP to HTTPS, in a single hop
• Change of Address requested in Search Console only if the domain or subdomain changes; not necessary for moving from HTTP to HTTPS or for changing www

Google also warns about how long this takes: "a small or medium site might take a few weeks to move most of its pages, and large sites take longer." If someone promises you that traffic won't drop a single point, they are selling you a certainty that Google's documentation does not provide.

Block 4 · Indexing and crawling (7 checks)

• Production robots.txt reviewed by hand: no Disallow: / inherited from the testing environment
• No important page carries noindex; global search for the tag and the X-Robots-Tag header
• The testing environment is password-protected, not just by robots.txt
• XML sitemap generated, with final URLs and 200 code, and submitted in Search Console
• Canonical tags pointing to the definitive URL and in HTTPS
• Valid TLS certificate, no mixed content, and automatic renewal verified
• Structured data validated with the rich results test, no critical errors

The second and third lines contradict each other if done incorrectly, and that contradiction is responsible for many discreet disasters. Google states it bluntly: for the noindex rule to work, "the page or resource must not be blocked by a robots.txt file." If you block the URL in robots.txt, the crawler never reads the noindex and the page may continue to appear. Blocking and deindexing are not the same: blocking prevents reading, deindexing requires reading.

Block 5 · Performance (5 checks)

Core Web Vitals thresholds are public and do not admit interpretation: LCP below 2.5 seconds, INP below 200 milliseconds, and CLS below 0.1, measured at the 75th percentile of loads and separating mobile and desktop.

• The three metrics within threshold on key templates: homepage, listing, product page, contact
• Measurement taken on mobile and with limited network, not on the studio laptop with fiber
• Images in modern format, with declared dimensions and lazy loading outside the first screen
• Fonts with font-display defined and preload of the font in the first text block
• Weight budget per template agreed upon in writing and verified in the last deployment

Measuring on a single device is not measuring: it is confirming a bias.

Block 6 · Accessibility (5 checks)

Law 11/2023 transposed the European Accessibility Act in Spain, whose effective application deadline was June 28, 2025, with a transitional regime for certain products and services set out in its single transitional provision. This is no longer a quality extra: for a large part of e-commerce, it is an obligation with a passed deadline.

• Full keyboard navigation, with visible focus on all interactive elements
• Text contrast verified with a tool, including text over images
• Forms with associated labels and errors announced in text, not just in color
• Videos with subtitles and accessible controls; nothing that plays with automatic sound
• Consistent heading structure and automatic validation passed, knowing that automatic validation detects part of the problem, not everything

An automatic reviewer does not certify compliance: it reduces the number of obvious flaws. The keyboard test is done by a person, with their hands.

Block 7 · Legal obligations in Spain (6 checks)

• Legal notice with the information from art. 10 of Law 34/2002: name, address, tax ID (NIF), registration data, and direct contact methods
• Privacy policy with legal basis, purposes, deadlines, and exercise of rights, and updated register of processing activities
• Cookie banner with the option to reject on the same layer and at the same level as accepting, as required by the AEPD guide
• No cookie wall that conditions access to the service on accepting non-essential cookies
• Analytics and pixels blocked until consent is given; verified with the network inspector, not with the tool's settings
• Prices displayed expressly indicating whether they include VAT; the general rate applicable to design and web development services is 21% (Law 37/1992, art. 90)

There is a tension here between sources worth naming, because almost no page dealing with this topic mentions it. Art. 22.2 of the LSSI-CE admits that consent may be provided "through the use of appropriate browser parameters" when technically feasible. The AEPD guide, much more recent and aligned with the GDPR, requires informed, granular consent with rejection at the same level as acceptance. In practice, the criteria that will be applied to you in an inspection is the AEPD's. Comply with the most demanding, not the most convenient.

Block 8 · Handover and first hours (4 checks)

• Code, design source files, and documentation delivered and located in a place the client controls
• Forms and payment gateway tested from end to end with a real submission and charge, with the email arriving in the correct inbox and not in spam
• Active monitoring: downtime, 404 errors, and server errors with automatic notification from the first hour
• Handover session recorded and saved, so your team can continue without us

What we measure with this list

— = data being measured; we will publish it once we have our own sample.

And a figure that we will publish as soon as we have a sufficient sample: still being measured.

We do not put an example number there. A made-up number in a checklist contaminates everything else.

How this fits into our workflows

The 30 days of support after the launch exist precisely for this: for the things that no list catches. And the price for that phase is closed before starting, without surprise hours.

A website is not published: it is put into production. They are two different acts, and only one of them leaves a verifiable trace.

We didn't write this list to sell launches: we wrote it so you can audit yours, with us or without us. Download it and perform blocks 3 and 4 today on the site you already have live: fifteen minutes, the robots.txt in front, and the redirect table to the side. If you get more than three red lines, send us your URL map and the launch date you have in mind; we will respond in less than 24 business hours with which block to close first and in what order.

Frequently asked questions

Can I launch with a red check?

Yes, if it is a conscious and written decision, with a correction date. What is not acceptable is launching without knowing which ones are red.

How long does it take for traffic to recover after a migration?

Google indicates that a small or medium site takes a few weeks to move most of its pages, and large sites longer. If someone guarantees zero loss, they are guaranteeing something that Google's own documentation does not state.

Is it enough to run an automatic analyzer?

No. An analyzer detects obvious performance and accessibility flaws. Redirects, handover, and the legal part are checked by hand, line by line.

Does this list work for a website made with WordPress or a builder?

It works entirely. How each line is executed changes, not which ones need to be checked. In a builder, some lines depend on what the platform lets you touch, and it is better to know that limitation before choosing it, not during launch week.

Can we use the checklist without hiring you?

Yes. It is published and downloadable in PDF, without registration. If you find more red lines than you can close on your own, tell us what you have in front of you.

Keep reading

• Redesigning your website without losing traffic or positioning: how it is done in phases and what to measure before and after
• When to redesign your website: 7 measurable thresholds, not "7 signs"
• What are Core Web Vitals and when does it pay off to optimize performance
• Web accessibility in Spain after the European Accessibility Act: who it binds and what it demands
• Access to the repository: why the client must have it from day one

Transparency note. Some of our own data in this guide is still being measured on real projects, with a single method. We will publish it with its sample size and date range once the sample is large enough; until then, every figure you see carries its source and date of consultation.

Sources

• https://web.dev/articles/vitals — Core Web Vitals thresholds: LCP 2.5s, INP 200 ms, CLS 0.1, measured at the 75th percentile and separating mobile and desktop
• https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes — 301/308 redirects, keep them for at least 1 year, avoid chains, when to use Change of Address, recovery deadlines
• https://developers.google.com/search/docs/crawling-indexing/block-indexing — the noindex rule does not work if the URL is blocked in robots.txt
• https://www.aepd.es/guias/guia-cookies.pdf — Guide on the use of cookies, May 2024 version: rejection on the same layer and at the same level, prohibition of cookie walls, consent not exceeding 24 months, exempt cookies
• https://www.boe.es/buscar/act.php?id=BOE-A-2002-13758 — Law 34/2002 LSSI-CE, art. 10 (mandatory general information: name, address, tax ID, registration data, prices) and art. 22.2 (consent for storage devices; admits browser parameters, which contrasts with the AEPD guide)
• https://www.boe.es/buscar/act.php?id=BOE-A-2023-11022 — Law 11/2023, of May 8: transposition of Directive (EU) 2019/882, effective application deadline of June 28, 2025, and single transitional provision on products and services