Lista de verificación SEO poslanzamiento: sistema de priorización, no un vertedero de tareas

TL;DR: La mejor checklist SEO pos-lanzamiento es más corta de lo que esperabas. Un lanzamiento casi nunca fracasa porque alguien olvidó una meta descripción. Falla porque Google no puede rastrear, renderizar, confiar o conectar las URL nuevas con las señales de autoridad antiguas. Revisa primero el acceso, el renderizado, los redireccionamientos, los canónicos, la analítica y los sitemaps. Si todo eso aprueba, probablemente el sitio no esté en llamas. Después ya podrás ordenar la habitación.

He publicado sitios de clientes con mindnow, reconstruido vadimkravcenko.com y ahora estoy creando seojuice.io con páginas públicas estáticas y superficies de aplicación que no necesitan posicionar. El pánico tras el lanzamiento casi nunca es «olvidamos un atributo alt». Suele ser «la nueva ruta de React devuelve un cascarón vacío», «el mapa de URL antiguo tiene huecos» o «Search Console indica "descubierta pero no indexada" y nadie quiere admitir que las páginas son débiles».

Esa es la mentalidad que hay que romper. Una checklist SEO pos-lanzamiento debe ser un sistema de triaje, no una hoja de cálculo donde cada fila tiene el mismo peso moral. Primero detén la hemorragia; luego pule.

La checklist SEO pos-lanzamiento es un sistema de triaje, no un vertedero de tareas

Las checklists estándar de lanzamiento igualan los riesgos. Una meta descripción faltante y un robots.txt bloqueante no pertenecen al mismo nivel. Tampoco una imagen hero lenta y un mapa 301 roto del sitio antiguo.

La primera hora es para obtener pruebas (lo que la mayoría de los equipos omite). ¿Pueden los rastreadores acceder a las páginas? ¿Ve Google la URL prevista, el canónico, el contenido y el estado? ¿Sobrevivieron las URL antiguas, los enlaces internos, la analítica y las citas? Solo después de eso el equipo debería pasar al trabajo de mejora.

Por eso una buena auditoría SEO técnica tras el lanzamiento empieza con modos de fallo, no con adornos. Los lanzamientos son políticos. Sin orden, cada reunión se convierte en teatro.

Qué verificar en los primeros 60 minutos después del lanzamiento

No asumas que «el sitio carga en Chrome» significa que Google ve el contenido. Chrome es tu navegador. Googlebot es un rastreador con pasos de renderizado, colas de rastreo, recursos bloqueados y otro cometido.

Empieza con el robots.txt de producción. Confirma que las secciones que deben posicionar estén permitidas. Luego revisa las meta robots, los encabezados x-robots-tag, los códigos de estado HTTP y las etiquetas canónicas. Las páginas activas deben devolver 200. Los redireccionamientos permanentes, 301. Las páginas eliminadas, 404 o 410. Los canónicos deben ser autorreferenciales o consolidar intencionalmente.

Después usa la Inspección de URL en Google Search Console. Prueba una URL de cada tipo de página indexable: home, categoría, producto, artículo, localización, página programática y cualquier plantilla nueva. Obtén la página. Inspecciona el HTML renderizado. Busca el contenido principal, los enlaces internos, el canónico, el título y los datos estructurados.

«El principal problema con CSR suele ser el riesgo de que, si algo falla durante la transmisión, el usuario no vea nada de tu contenido. Eso también puede tener implicaciones SEO.»

Esa advertencia de Martin Splitt, Developer Advocate en Google, describe el problema del día del lanzamiento en lenguaje llano. El renderizado del lado del cliente no es maligno; es frágil al lanzar porque un script fallido, un bug de hidratación, un problema de rutas o un recurso bloqueado puede convertir una página con contenido en un cascarón vacío.

• Rastrea una muestra de plantillas, no solo la home.
• Prueba una URL de cada tipo de página indexable.
• Usa la Inspección de URL para fetch y HTML renderizado.
• Confirma que ninguna regla noindex de staging llegó a producción.
• Verifica que el contenido clave aparezca sin interacción del usuario.
• Asegura que los enlaces de navegación sean enlaces HTML rastreables cuando sea posible.

Si el sitio usa JavaScript intensivo, añade una pasada de SEO para JavaScript. Ver código fuente no basta. Importa el DOM renderizado.

Por qué los redireccionamientos merecen más atención de la que reciben

Si las URL cambiaron, mapear los redireccionamientos es obligatorio. Es el puente entre las señales ganadas del sitio antiguo y la nueva estructura.

«Si cambian las URL y las antiguas no se mapean correctamente a las nuevas mediante 301, el sitio corre el riesgo de perder mucho poder SEO.»

Glenn Gabe, fundador de G-Squared Interactive, es tajante porque el fallo es habitual. Las URL antiguas redirigen a la home. Se publican 302 en lugar de 301. Las cadenas de redirección se apilan a través de rutas de CMS antiguo, reglas de barra final, HTTP a HTTPS y carpetas de locale (normalmente porque nadie es dueño del mapa de migración). Las URL con query string se descartan sin revisar backlinks ni tráfico.

Rastrea la lista de URL antiguas tras el lanzamiento (el sitio nuevo es la mitad fácil). Ahí se esconde la pérdida de tráfico. No rastrees solo el sitio nuevo y declares victoria.

• Las URL antiguas deben resolver a la nueva página equivalente.
• Los movimientos permanentes deben usar redirecciones 301.
• Las cadenas de redirección deben acortarse.
• Los enlaces internos deben apuntar a las URL finales, no a redirigidas.
• Los sitemaps XML deben excluir URL redirigidas y no canónicas.

Google puede seguir redirecciones; el objetivo no es poner a prueba su paciencia. Mantén los caminos directos.

Sitemaps y Search Console: útiles, pero no mágicos

La mayoría de las checklists coloca «enviar sitemap» arriba como si forzara la indexación. Google Search Central dice que el envío del sitemap es «meramente una pista» y no garantiza descarga, rastreo ni uso.

Los sitemaps siguen siendo útiles: ayudan al descubrimiento, exponen problemas de reporte y dan a Search Console una superficie limpia. Importan más cuando un sitio es nuevo, tiene pocos enlaces externos, muchas páginas o URL difíciles de encontrar mediante enlaces internos.

Una vez vi un sitemap lleno de URL redirigidas ocultar el problema real: las páginas canónicas nuevas apenas tenían enlaces.

• Envía el índice de sitemap XML correcto en Google Search Console.
• Elimina URL de staging, dominio antiguo, redirigidas, bloqueadas y no canónicas.
• Divide archivos antes de 50 MB sin comprimir o 50 000 URL.
• Confía en lastmod solo si el CMS lo escribe con precisión.
• Compara enviadas frente a indexadas por tipo de plantilla.

Enviar un sitemap es logística. La indexación se gana.

Si no puedes medir el lanzamiento, no puedes depurarlo

Todo el mundo dice que el tracking está listo. Luego la página de gracias, el banner de consentimiento, el evento de checkout o la referencia entre dominios se rompen.

Antes de discutir rankings, demuestra que la medición funciona. GA4 debe dispararse en cada plantilla pública. Search Console debe estar verificado para la propiedad correcta (protocolo, subdominio y dominio importan). Bing Webmaster Tools entra en la checklist si el sitio depende de Bing, superficies de Copilot o tráfico de búsqueda empresarial.

• Exporta el rank tracking antes del lanzamiento.
• Exporta las landing pages orgánicas por URL, plantilla, país y dispositivo.
• Confirma que los logs del servidor o CDN estén disponibles si cae el rastreo.
• Añade una anotación de lanzamiento en las herramientas de analítica.
• Prueba los eventos de conversión tras consent mode y reglas de tag manager.

El equipo necesita saber si el tráfico cambió por rankings, indexación, medición, estacionalidad o un redireccionamiento roto. Sin líneas base, la reunión pos-lanzamiento se convierte en adivinar con gráficos.

Core Web Vitals tras el lanzamiento: mide ahora, pero no esperes a CrUX

El Web Almanac del HTTP Archive 2025 muestra por qué el rendimiento merece atención el día del lanzamiento. HTTPS y las etiquetas title ya son comunes: HTTPS aparece en ≈91,7 % de páginas de escritorio y ≈91,5 % de móviles, mientras que las etiquetas title aparecen en ≈98,6 % y ≈98,5 % respectivamente. Los Core Web Vitals son más débiles. La tasa de aprobación en desktop es 56 %. En móvil es 48 %.

Eso significa que los Core Web Vitals son uno de los lugares más comunes donde fallan los lanzamientos, lejos de ser una tarea marginal.

INP se convirtió en Core Web Vital estable el 12 de marzo de 2024, reemplazando a FID. Los umbrales son simples: 200 ms o menos es bueno; de 200 ms a 500 ms necesita mejora; más de 500 ms es pobre. El Web Almanac informa que el 77 % de las páginas móviles aprueban INP, frente al 97 % en desktop. Solo el 53 % de los 1 000 sitios principales pasa, lo que dice mucho sobre los sitios grandes y cargados de JavaScript.

CrUX usa una ventana móvil de 28 días, así que las páginas nuevas pueden no tener datos de campo de inmediato. Usa Lighthouse, PageSpeed Insights (lab), WebPageTest, RUM y pruebas a nivel plantilla hasta que maduren los datos de campo.

• Prueba primero en móvil.
• Prueba la plantilla más lenta, no la página más bonita.
• Vigila LCP en imágenes hero y respuesta del servidor.
• Vigila INP en menús, filtros, acordeones, búsqueda, formularios y configuradores.
• Vigila CLS tras cargar fuentes, anuncios, banners, embeds y avisos de cookies.

Calidad de contenido y enlaces internos: por qué «Descubierta, actualmente no indexada» no es un problema de botón

La gente ve «Descubierta, actualmente no indexada» y empieza a reenviar URL. Eso puede ayudar a Google a encontrar la página otra vez. No la hace digna de indexarse.

«En la mayoría de los casos, se trata más de la calidad general del sitio.»

Esa frase de John Mueller, Search Advocate en Google, es un tirón de orejas útil. La mayoría de las checklists pos-lanzamiento tratan la indexación como un problema de configuración. Mueller la redefine como un problema de calidad.

Comprueba si las páginas importantes están enlazadas desde la navegación rastreable, hubs, migas de pan o bloques de contenido relacionado. Busca enlaces en el cuerpo que desaparecieron durante el rediseño. Revisa páginas thin de localización, categoría, etiqueta o programáticas que se multiplicaron en el lanzamiento. Asegura que el contenido único no quede enterrado bajo pestañas, scripts o copy hero genérico.

Aquí es donde importa la estrategia de enlaces internos. Los enlaces internos no son solo rutas de rastreo. Son prioridad editorial. Si el sitio no apunta a una página, le está diciendo a los motores que esa página no es central.

Verifica títulos, canónicos, schema y metadatos, pero no los idolatres

Los metadatos siguen importando. Simplemente pertenecen al nivel correcto.

El Web Almanac 2025 encontró etiquetas canónicas en ≈68 % de páginas desktop y ≈67 % móviles. Los títulos son casi universales. HTTPS es común. Son comprobaciones básicas, no el lugar donde se esconden los desastres serios de lanzamiento.

En una reconstrucción, un schema de staging con reseñas falsas llegó a producción. El problema era visible para cualquiera que viera el código fuente.

• Usa títulos únicos en plantillas indexables.
• Escribe meta descripciones para páginas donde el CTR importa.
• Define un único canónico claro por página indexable.
• Comprueba las previsualizaciones Open Graph de páginas compartidas al lanzar.
• Valida datos estructurados para productos, artículos, migas, organizaciones, locales, FAQs y reseñas donde sea elegible.
• Prueba hreflang si hay variantes de idioma o región.
• Elimina schema copiado de staging, marcas antiguas o URL erróneas.

Haz el trabajo. Solo no confundas completar metadatos con seguridad de lanzamiento.

Chequeo de lanzamiento 2026: reglas para crawlers de IA y continuidad de citas

La política de crawlers de IA es ahora una decisión del día de lanzamiento (en 2026 ya no es opcional). El Web Almanac 2025 encontró reglas gptbot en robots.txt del 4,5 % de páginas desktop y 4,2 % móviles, un aumento interanual del 55 %. Las reglas claudebot casi se duplicaron a 3,6 % en desktop y 3,4 % en móvil.

Esto no significa que permitir GPTBot garantice visibilidad en búsqueda de IA. Significa que robots.txt se usa cada vez más para controlar el acceso de crawlers de IA y el equipo de lanzamiento necesita una política documentada.

1. Decide permitir o bloquear los principales crawlers de IA antes del lanzamiento.
2. Preserva la continuidad de citas redirigiendo URL antiguas que ganaron menciones, enlaces y referencias en foros.
3. Mantén coherentes las señales de entidad: nombre de marca, autores, schema de organización, páginas «Acerca de», «Contacto», nombres de producto y páginas fuente canónicas.

Las URL rotas pueden destruir rastros de citas que los sistemas de búsqueda y los motores de respuesta podrían utilizar. Mantén rastreables las páginas que prueban quién eres.

El bucle de monitorización de 7 días pos-lanzamiento

El día 0 es acceso y renderizado. El día 1 son redirecciones, analítica e informes de sitemap. Los días 2 a 7 son detección de patrones.

• Revisa cobertura e indexación en Search Console por plantilla.
• Comprueba errores de servidor y soft 404.
• Vuelve a rastrear la lista de URL antiguas en busca de errores de redirección.
• Encuentra landing pages orgánicas que desaparecieron.
• Revisa consultas de marca e indexación de la home.
• Vigila páginas nuevas atascadas en descubiertas o rastreadas pero no indexadas.
• Revisa picos o caídas de rastreo en los logs.
• Prueba de nuevo el tracking de conversiones.
• Haz seguimiento de términos clave, pero espera algo de volatilidad temprana.

La paciencia importa: no cada bajón es un desastre. Pero cada bajón sin medir se convierte en una discusión política.

La revisión a 30 días: qué arreglar cuando el incendio ya se apagó

Después de la primera semana, deja de buscar solo errores catastróficos. Empieza a mejorar sistemas débiles.

• Revisa los datos de campo de Core Web Vitals a medida que estén disponibles.
• Encuentra páginas con impresiones pero bajo CTR.
• Añade enlaces internos a páginas estratégicas nuevas.
• Compara indexación por tipo de plantilla.
• Limpia enlaces internos que aún redirigen.
• Revisa contenido que perdió rankings tras reescrituras o fusiones.
• Soluciona avisos de schema y problemas de rich results.
• Confirma la política de crawlers de IA con los equipos legal y de marca.
• Refuerza señales de experiencia, contexto de autor y contenido de apoyo.

Aquí es donde una configuración de monitorización SEO adecuada empieza a rendir frutos. No puedes juzgar todos los resultados SEO en 48 horas. Sí puedes juzgar si el sistema mejora.

Checklist SEO pos-lanzamiento para copiar y pegar

Acceso e indexabilidad

• El robots.txt de producción permite las secciones previstas.
• No quedan directivas noindex de staging.
• Las páginas indexables devuelven 200.
• Las páginas eliminadas devuelven 404 o 410.
• Los canónicos apuntan a las URL previstas.
• La Inspección de URL confirma fetch y renderizado.

Renderizado y plantillas

• El contenido principal aparece en el HTML renderizado.
• Los enlaces de navegación son rastreables.
• Los enlaces importantes no están ocultos tras acciones del usuario.
• Errores de JavaScript no bloquean el contenido de la página.
• Cada plantilla principal ha sido probada en móvil.

Redirecciones y continuidad de URL

• Lista de URL antiguas rastreada tras el lanzamiento.
• 301 de un solo salto para URL cambiadas.
• Las redirecciones apuntan a páginas equivalentes, no a la home.
• Los enlaces internos apuntan a URL finales.
• El sitemap XML excluye URL redirigidas.

Search Console y sitemaps

• Propiedad correcta verificada.
• Índice de sitemap enviado.
• El sitemap contiene solo URL canónicas e indexables.
• Enviadas vs. indexadas monitorizadas por plantilla.
• Acciones manuales y problemas de seguridad revisados.

Analítica y tracking

• GA4 se dispara en todas las plantillas públicas.
• Landing pages orgánicas registradas.
• Conversiones probadas.
• Anotación de lanzamiento añadida.
• Rankings y tráfico base exportados.

Rendimiento

• LCP comprobado en plantillas clave.
• INP probado en elementos interactivos.
• CLS verificado tras cargar banners, fuentes y embeds.
• Herramientas de laboratorio usadas hasta que maduren los datos CrUX.
• Móvil probado antes que desktop.

Contenido y enlaces internos

• Páginas prioritarias enlazadas desde hubs o navegación.
• Contenido antiguo importante no se eliminó sin reemplazo.
• Páginas programáticas thin revisadas.
• Títulos y encabezados alineados con la intención de búsqueda.
• Páginas huérfanas identificadas.

Datos estructurados y metadatos

• Títulos únicos en páginas indexables.
• Meta descripciones revisadas para páginas clave.
• Schema de breadcrumbs validado.
• Schema de producto, artículo, organización, local o reseña probado donde corresponda.
• Hreflang probado si aplica.

Búsqueda de IA y política de crawlers

• Reglas de crawlers de IA en robots.txt documentadas.
• URL antiguas citadas redirigidas.
• Detalles de entidad de marca y autor coherentes.
• Páginas «Acerca de», «Contacto» y fuente siguen rastreables.
• Páginas informativas clave preservadas durante la migración.

Si solo tienes una hora, revisa acceso de rastreo, renderizado, redirecciones, canónicos, analítica y sitemap. Si todo eso aprueba, probablemente el lanzamiento no esté en llamas. Entonces empieza el verdadero trabajo SEO.

FAQ

¿Cuándo debo ejecutar una checklist SEO pos-lanzamiento?

Ejecuta las comprobaciones de acceso, renderizado, robots, código de estado, canónico, analítica y redirecciones en la primera hora. Ejecuta sitemap, Search Console y rastreos de URL antiguas el primer día. Vigila indexación, logs, rankings y conversiones durante la primera semana.

¿Enviar un sitemap es suficiente para indexar un sitio nuevo?

No. Google dice que el envío del sitemap es «meramente una pista». Envíalo porque ayuda al descubrimiento y al reporte, especialmente en sitios nuevos o grandes. No lo trates como un botón de indexación.

¿Cuál es el mayor error SEO pos-lanzamiento?

Los fallos más costosos son bloqueo de rastreo, renderizado roto, redirecciones malas, canónicos equivocados y medición ausente. Los errores de metadatos son más fáciles de solucionar cuando el sitio se estabiliza.

¿Debo revisar las URL antiguas o solo el sitio nuevo?

Revisa ambos, pero rastrea la lista de URL antiguas tras el lanzamiento. Ahí aparecen la equidad perdida, los backlinks rotos, los mapeos incorrectos y las redirecciones a la home. Esto es SEO esencial de migración de sitios.

¿Cuándo revisar los Core Web Vitals después del lanzamiento?

Prueba de inmediato con herramientas de laboratorio y RUM. Los datos de campo de CrUX funcionan con una ventana de 28 días, así que las páginas nuevas pueden necesitar tiempo antes de tener reportes estables.

¿Necesitas ayuda para encontrar los problemas de lanzamiento que de verdad importan?

SEOJuice está diseñado para ayudar a los equipos a captar lo que cambia los resultados: enlaces internos rotos, prioridad de página débil, contexto ausente y problemas SEO pos-lanzamiento que se esconden bajo la superficie. Si tu sitio acaba de salir, empieza con las comprobaciones de triaje anteriores y luego usa SEOJuice para mantener la limpieza en marcha.