Las 47 comprobaciones que pasamos antes de poner una web en producción: redirecciones, indexación, Core Web Vitals, accesibilidad y legal español. En PDF.
Antes de publicar hay que comprobar 47 cosas repartidas en ocho bloques: copia de seguridad y entorno, contenido y URLs, redirecciones, indexación, rendimiento, accesibilidad, obligaciones legales españolas y traspaso. Se pasa entera, en orden y con un responsable por línea. El lanzamiento es una lista de verificación, no un salto de fe.
Un lanzamiento sale mal casi siempre por lo mismo: nadie escribió la lista. Se cambia el DNS un jueves por la tarde, la web carga, todo el mundo respira, y tres semanas después el tráfico orgánico ha caído a la mitad porque el robots.txt de pruebas viajó a producción intacto.
Esta es la lista que usamos nosotros. Está pensada para imprimirla, colgarla en la pared y tacharla a mano. La publicamos entera porque una checklist que se guarda no protege a nadie.
Normativa y umbrales verificados el 27-08-2026: umbrales de Core Web Vitals (web.dev), guía de cookies de la AEPD (versión de mayo de 2024), Ley 34/2002 (LSSI-CE) arts. 10 y 22, Ley 11/2023 de accesibilidad y documentación de Google Search Central sobre migraciones e indexación. Vuelve a comprobar las líneas legales si lanzas más de seis meses después de esta fecha.
Cómo se usa esta lista
Cada línea tiene tres estados: verde, rojo o «no aplica». No hay ámbar. Una comprobación a medias es una comprobación roja.
Cada línea tiene además un nombre y apellidos al lado. No un equipo: una persona. Y una hora concreta de corte.
Nosotros la pasamos dos veces: una a T-7 días, con margen para arreglar lo que salga, y otra a T-0, justo antes de mover el DNS. La primera pasada encuentra los problemas de fondo; la segunda, los que alguien introdujo el último día.
Lo habitual en el sector: El estudio español medio lanza cuando "el cliente da el visto bueno al diseño" y deja las comprobaciones técnicas para después, con la web ya viva y el tráfico entrando.
Nuestro criterio: Nosotros lanzamos cuando las 47 líneas están en verde. Para nosotros el visto bueno al diseño es una línea más, no el sustituto de las otras 46.
Bloque 1 · Antes de tocar nada (6 comprobaciones)
- Copia completa del sitio antiguo: base de datos, archivos y configuración del servidor, descargada y restaurada en un entorno de prueba para confirmar que la copia sirve
- Volcado del mapa de URLs actual con su tráfico y sus enlaces entrantes, exportado a un archivo, no a una pestaña del navegador
- Registro de posiciones y tráfico de los últimos 12 meses guardado como línea base: sin línea base no hay forma de demostrar si el rediseño ha funcionado
- Ventana de lanzamiento acordada por escrito, fuera del pico de tráfico semanal y con al menos un día laborable por delante
- Plan de vuelta atrás escrito en una página: quién lo ejecuta, qué comandos, cuánto tarda
- Acceso al repositorio, al panel de DNS, al hosting y al gestor de contenido en manos del cliente antes del lanzamiento, no después
La sexta es la que más discusión genera y la que menos negociamos. El día que se cae algo, el acceso tiene que existir ya.
Bloque 2 · Contenido y URLs (8 comprobaciones)
- Cada página nueva tiene su equivalente en el mapa antiguo, o una decisión explícita de que desaparece
- Etiquetas
titleúnicas en todas las páginas indexables, revisadas una a una, no generadas en masa - Meta descripciones escritas para las 20 páginas con más tráfico como mínimo
- Un solo H1 por página, y que el H1 diga lo que la página hace
- Imágenes con texto alternativo real; las decorativas, con
altvacío - Sin texto de relleno ni contenido de prueba: búsqueda global de "lorem", "prueba", "ejemplo" y del nombre en clave del proyecto
- Enlaces internos apuntando a URLs finales, sin pasar por redirecciones
- URLs en minúsculas, sin acentos, sin parámetros de sesión y con criterio único sobre la barra final
Una página que desaparece sin que nadie lo haya decidido no es una limpieza: es una pérdida. Cada URL que se cae del mapa nuevo necesita una firma detrás y una línea en la tabla de redirecciones.
Bloque 3 · Redirecciones (6 comprobaciones)
Aquí es donde se pierde el posicionamiento, y se pierde en silencio. Google publica tres instrucciones concretas para una migración con cambio de URL: usar redirecciones permanentes del lado del servidor, "301 y 308"; mantenerlas "durante al menos un año"; y redirigir directamente al destino final, sin cadenas.
- Tabla de redirecciones completa, URL antigua a URL nueva, revisada línea a línea y no por comodín
- Todas devuelven 301 o 308, comprobado con petición real, no con la configuración teórica
- Cero cadenas: ninguna redirección apunta a otra redirección
- Ninguna redirección lleva a la portada por defecto; si no hay equivalente, es un 410 o una página con alternativa útil
- Variantes de dominio resueltas: con y sin
www, HTTP a HTTPS, en una sola salto - Change of Address solicitado en Search Console solo si cambia el dominio o el subdominio; no hace falta para pasar de HTTP a HTTPS ni para cambiar de
www
Google avisa además de cuánto tarda esto: "un sitio pequeño o mediano puede tardar unas semanas en mover la mayoría de sus páginas, y los sitios grandes tardan más". Si alguien te promete que el tráfico no se moverá ni un punto, te está vendiendo una certeza que la documentación de Google no da.
Bloque 4 · Indexación y rastreo (7 comprobaciones)
robots.txtde producción revisado a mano: sinDisallow: /heredado del entorno de pruebas- Ninguna página importante lleva
noindex; búsqueda global de la etiqueta y de la cabeceraX-Robots-Tag - El entorno de pruebas queda protegido por contraseña, no solo por
robots.txt - Sitemap XML generado, con URLs finales y con código 200, y enviado en Search Console
- Canónicas apuntando a la URL definitiva y en HTTPS
- Certificado TLS válido, sin contenido mixto, y renovación automática comprobada
- Datos estructurados validados con la prueba de resultados enriquecidos, sin errores críticos
La segunda y la tercera línea se contradicen si se hacen mal, y esa contradicción es responsable de muchos desastres discretos. Google lo dice sin rodeos: para que la regla noindex funcione, "la página o el recurso no debe estar bloqueado por un archivo robots.txt". Si bloqueas la URL en robots.txt, el rastreador nunca llega a leer el noindex y la página puede seguir apareciendo. Bloquear y desindexar no son lo mismo: bloquear impide leer, desindexar exige leer.
Bloque 5 · Rendimiento (5 comprobaciones)
Los umbrales de Core Web Vitals son públicos y no admiten interpretación: LCP por debajo de 2,5 segundos, INP por debajo de 200 milisegundos y CLS por debajo de 0,1, medidos en el percentil 75 de las cargas y separando móvil y escritorio.
- Las tres métricas dentro de umbral en las plantillas clave: portada, listado, ficha, contacto
- Medición hecha en móvil y con red limitada, no en el portátil del estudio con fibra
- Imágenes en formato moderno, con dimensiones declaradas y carga diferida fuera del primer pantallazo
- Tipografías con
font-displaydefinido y precarga de la fuente del primer bloque de texto - Presupuesto de peso por plantilla acordado por escrito y comprobado en el último despliegue
Medir en un solo dispositivo no es medir: es confirmar un prejuicio.
Bloque 6 · Accesibilidad (5 comprobaciones)
La Ley 11/2023 transpuso en España la directiva europea de accesibilidad, cuyo plazo de aplicación efectiva era el 28 de junio de 2025, con un régimen transitorio para determinados productos y servicios recogido en su disposición transitoria única. Esto ya no es un extra de calidad: para buena parte del comercio electrónico es una obligación con fecha cumplida.
- Navegación completa con teclado, con foco visible en todos los elementos interactivos
- Contraste de texto comprobado con herramienta, incluido el texto sobre imagen
- Formularios con etiquetas asociadas y errores anunciados en texto, no solo en color
- Vídeos con subtítulos y controles accesibles; nada que se reproduzca con sonido automático
- Estructura de encabezados coherente y validación automática pasada, sabiendo que la automática detecta una parte del problema, no todo
Un revisor automático no certifica el cumplimiento: reduce el número de fallos evidentes. La prueba de teclado la hace una persona, con las manos.
Bloque 7 · Obligaciones legales en España (6 comprobaciones)
- Aviso legal con la información del art. 10 de la Ley 34/2002: denominación, domicilio, NIF, datos de inscripción registral y medios de contacto directo
- Política de privacidad con base jurídica, finalidades, plazos y ejercicio de derechos, y registro de actividades de tratamiento actualizado
- Banner de cookies con la opción de rechazar en la misma capa y al mismo nivel que la de aceptar, como exige la guía de la AEPD
- Sin muro de cookies que condicione el acceso al servicio a aceptar las no necesarias
- Analítica y píxeles bloqueados hasta que haya consentimiento; comprobado con el inspector de red, no con la configuración de la herramienta
- Precios mostrados indicando de forma expresa si incluyen IVA; el tipo general aplicable a servicios de diseño y desarrollo web es el 21 % (Ley 37/1992, art. 90)
Aquí hay una tensión entre fuentes que conviene nombrar, porque casi ninguna página que trate este tema la nombra. El art. 22.2 de la LSSI-CE admite que el consentimiento se facilite "mediante el uso de los parámetros adecuados del navegador" cuando sea técnicamente viable. La guía de la AEPD, mucho más reciente y alineada con el RGPD, exige un consentimiento informado, granular y con rechazo al mismo nivel que la aceptación. En la práctica, el criterio que te van a aplicar en una inspección es el de la AEPD. Cumple con el más exigente, no con el más cómodo.
Bloque 8 · Traspaso y primeras horas (4 comprobaciones)
- Código, archivos fuente de diseño y documentación entregados y localizados en un sitio que el cliente controla
- Formularios y pasarela probados de extremo a extremo con un envío y un cobro reales, con el correo llegando a la bandeja correcta y no a spam
- Monitorización activa: caídas, errores 404 y errores de servidor con aviso automático desde la primera hora
- Sesión de traspaso grabada y guardada, para que tu equipo pueda seguir sin nosotros
Qué medimos nosotros con esta lista
| Concepto | Dato | Nota |
|---|---|---|
| Redirecciones e indexación | — | — |
| Rendimiento | — | — |
| Legal | — | — |
— = dato en medición; lo publicaremos cuando tengamos muestra propia.
Y una cifra que publicaremos en cuanto tenga muestra suficiente: en medición.
No ponemos un número de ejemplo ahí. Un número inventado en una checklist contamina todo lo demás.
Cómo encaja esto en nuestros movimientos
| Momento | Qué se comprueba | Quién responde |
|---|---|---|
| T-7 días | Bloques 1 a 6 completos | Estudio |
| T-2 días | Bloque 7, legal, con el cliente delante | Cliente y estudio |
| T-0 | Segunda pasada de los bloques 3 y 4 | Estudio |
| T+24 h | Bloque 8 y monitorización | Estudio |
| T+30 días | Comparación con la línea base | Estudio |
| # | Fase | Qué hacemos | Entregables |
|---|---|---|---|
| 06 | Lanzar y acompañar | El lanzamiento es una lista de verificación, no un salto de fe. | Checklist de 47 · Traspaso · 30 días de soporte incluido |
Los 30 días de soporte posteriores al lanzamiento existen precisamente para esto: para las cosas que ninguna lista atrapa. Y el precio de esa fase está cerrado antes de empezar, sin horas sorpresa.
Una web no se publica: se pone en producción. Son dos gestos distintos, y solo uno de ellos deja rastro comprobable.
Esta lista no la escribimos para vender lanzamientos: la escribimos para que puedas auditar el tuyo, con nosotros o sin nosotros. Descárgala y pasa hoy los bloques 3 y 4 sobre la web que ya tienes viva: quince minutos, el robots.txt delante y la tabla de redirecciones al lado. Si te salen más de tres líneas en rojo, mándanos el mapa de URLs y la fecha de lanzamiento que tienes en la cabeza; te respondemos en menos de 24 horas laborables con qué bloque hay que cerrar primero y en qué orden.
Preguntas frecuentes
¿Puedo lanzar con alguna comprobación en rojo?
Sí, si es una decisión consciente y escrita, con fecha de corrección. Lo que no vale es lanzar sin saber cuáles están en rojo.
¿Cuánto tarda el tráfico en recuperarse tras una migración?
Google indica que un sitio pequeño o mediano tarda unas semanas en mover la mayoría de sus páginas, y los grandes más. Si alguien te garantiza cero pérdida, te está garantizando algo que la propia documentación de Google no afirma.
¿Vale con pasar un analizador automático y ya está?
No. Un analizador detecta los fallos evidentes de rendimiento y accesibilidad. Las redirecciones, el traspaso y la parte legal se comprueban a mano, línea a línea.
¿Esta lista sirve para una web hecha con WordPress o con un constructor?
Sirve entera. Cambia cómo se ejecuta cada línea, no cuáles hay que comprobar. En un constructor, algunas líneas dependen de lo que la plataforma te deje tocar, y esa limitación conviene conocerla antes de elegirla, no la semana del lanzamiento.
¿Podemos usar la checklist sin contrataros?
Sí. Está publicada y es descargable en PDF, sin registro. Si al pasarla te salen más rojos de los que puedes cerrar solo, cuéntanos qué tienes delante.
Sigue leyendo
- Rediseñar tu web sin perder tráfico ni posicionamiento: cómo se hace por fases y qué medir antes y después
- Cuándo rediseñar tu web: 7 umbrales medibles, no "7 señales"
- Qué son los Core Web Vitals y cuándo compensa optimizar el rendimiento
- Accesibilidad web en España tras la European Accessibility Act: a quién obliga y qué exige
- Acceso al repositorio: por qué el cliente debe tenerlo desde el día uno
Nota de transparencia. Algunos datos propios de esta guía todavía están en medición en proyectos reales, con un mismo método. Los publicaremos con su tamaño de muestra y su ventana de fechas cuando la muestra sea suficiente; hasta entonces, cada cifra que ves lleva su fuente y su fecha de consulta.
Fuentes verificadas
- https://web.dev/articles/vitals — umbrales de Core Web Vitals: LCP 2,5 s, INP 200 ms, CLS 0,1, medidos en el percentil 75 y separando móvil y escritorio
- https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes — redirecciones 301/308, mantenerlas al menos 1 año, evitar cadenas, cuándo usar Change of Address, plazos de recuperación
- https://developers.google.com/search/docs/crawling-indexing/block-indexing — la regla noindex no funciona si la URL está bloqueada en robots.txt
- https://www.aepd.es/guias/guia-cookies.pdf — Guía sobre el uso de las cookies, versión de mayo de 2024: rechazo en la misma capa y al mismo nivel, prohibición de muros de cookies, consentimiento no superior a 24 meses, cookies exentas
- https://www.boe.es/buscar/act.php?id=BOE-A-2002-13758 — Ley 34/2002 LSSI-CE, art. 10 (información general obligatoria: denominación, domicilio, NIF, datos registrales, precios) y art. 22.2 (consentimiento para dispositivos de almacenamiento; admite parámetros del navegador, lo que contrasta con la guía de la AEPD)
- https://www.boe.es/buscar/act.php?id=BOE-A-2023-11022 — Ley 11/2023, de 8 de mayo: transposición de la Directiva (UE) 2019/882, plazo de aplicación efectiva del 28 de junio de 2025 y disposición transitoria única sobre productos y servicios
¿Quieres ver este criterio aplicado a un proyecto real?
