— Verificado con la documentación de Google Search Console, probado en lanzamientos reales de sitios y con datos de migración de nuestro propio cambio de .io → .com en enero de 2026.
TL;DR: Ya lanzaste el sitio. Felicidades. Ahora empieza el trabajo de verdad. Los primeros 30 días después de un lanzamiento definen si ganas visibilidad en Google o te pierdes dentro del índice. Este checklist cubre los pasos exactos — hora por hora, semana por semana — que uso en cada lanzamiento y migración. Si te saltas las primeras 24 horas, puedes pasar meses recuperando lo que podrías haber protegido en una tarde.
Lanzar un sitio se siente bien. Durante unos cinco minutos. Después llega la ansiedad: ¿se está indexando todo? ¿funcionaron las redirecciones? ¿de verdad alguien nos está encontrando?
Lo he visto decenas de veces. Los equipos pasan meses en diseño, contenido y desarrollo. Se obsesionan con las tipografías y los colores de los botones. Luego hacen clic en “publicar” y se van.
Ahí es cuando empieza a romperse todo.
Solo el 10% de las migraciones de sitios realmente mejoran el rendimiento SEO. El otro 90% se estanca o pierde tráfico — a veces de forma catastrófica. ¿El tiempo promedio de recuperación después de una migración mal hecha? 523 días. Eso es casi un año y medio viendo cómo tu gráfica de tráfico apunta en la dirección equivocada.
¿La diferencia entre el 10% que mejora y el 90% que no? Un checklist. Literalmente. Los equipos que siguen un proceso estructurado de SEO post-lanzamiento se recuperan en semanas. Los que improvisan pasan trimestres explicándole a sus jefes por qué cayó el tráfico.
"El enlazado interno es una de las cosas más importantes que puedes hacer en un sitio web para orientar a Google y guiar a los visitantes hacia las páginas que consideras importantes."
El punto de Mueller es especialmente relevante después del lanzamiento. La nueva arquitectura de tu sitio tiene que decirle de inmediato a Google qué es lo que importa. Si lanzaste con enlaces internos rotos, páginas huérfanas o sin sitemap, Google no sabe por dónde empezar — y no lo va a adivinar por arte de magia.
Estas revisiones son imprescindibles. Hazlas antes de tuitear sobre el lanzamiento. Antes de escribirle a tu lista. Antes de cualquier otra cosa. En nuestra migración, las primeras 24 horas fueron una mezcla borrosa de ventanas de terminal y pestañas de Search Console. No fue glamoroso. Pero cada punto de abajo existe porque detectamos un problema a tiempo o vimos a alguien más no detectarlo.
| Prioridad | Revisión | Por qué importa | Cómo verificarlo |
|---|---|---|---|
| P0 | Quitar etiquetas noindex | Los sitios en desarrollo bloquean a los motores de búsqueda — olvidarte de quitar esto vuelve invisible todo tu sitio | Ver código fuente → buscar noindex. Revisar robots.txt para Disallow: / |
| P0 | Enviar el XML sitemap a GSC | Le dice a Google cuáles son todas las páginas de tu nuevo sitio. Sin esto, la indexación tarda semanas en vez de días | Google Search Console → Sitemaps → Enviar URL |
| P0 | Verificar todas las redirecciones 301 | Las URLs antiguas todavía tienen backlinks y marcadores. Las redirecciones rotas = autoridad perdida | Rastrear la lista de URLs antiguas y verificar que cada una devuelva 301 a la nueva URL correcta |
| P0 | Comprobar que robots.txt sea accesible | Si robots.txt está bloqueado, Google no puede rastrear nada | Visita yourdomain.com/robots.txt — debe devolver 200 |
| P1 | Verificar HTTPS en todas las páginas | Las advertencias de contenido mixto dañan la confianza y los rankings | Ejecuta un rastreo — marca cualquier página que cargue recursos por HTTP |
| P1 | Revisar etiquetas canonical | Los canonical incorrectos le dicen a Google que ignore tus páginas nuevas | Haz una revisión rápida de 10 páginas — el canonical debe apuntar a la URL actual, no al dominio anterior |
| P1 | Probar el renderizado móvil | Google usa mobile-first indexing — los sitios pensados solo para desktop pierden visibilidad | Herramienta Mobile-Friendly Test de Google |
| P1 | Monitorear códigos de respuesta del servidor | Errores 500 durante el lanzamiento = páginas saliendo del índice | Revisar logs del servidor para respuestas 5xx en las primeras 24h |
| P2 | Verificar Google Analytics / Tag Manager | Sin medición = sin datos. Necesitas una línea base desde el día uno | Reporte en tiempo real en GA — confirma que estén entrando páginas vistas |
| P2 | Solicitar indexación de páginas clave | Acelera el descubrimiento de tu contenido más importante | GSC → URL Inspection → Request Indexing (homepage, top 10 páginas) |
Conclusión clave
¿El error de lanzamiento más común que he visto? Dejar noindex en producción. Suena demasiado tonto para ser real — pero he visto rediseños de seis cifras publicarse con la casilla de “Discourage search engines” todavía marcada en WordPress. Revísalo primero. Revísalo dos veces. Luego haz que otra persona también lo revise. Nosotros casi lo publicamos así durante el cambio a .com — lo detectamos solo porque nuestro script de deploy tiene una validación automática de noindex en la homepage. Añade una al tuyo.
Aquí tienes un robots.txt limpio para un sitio recién lanzado. Ajusta la URL del sitemap y cualquier ruta de administración según tu CMS.
User-agent: *
Allow: /
# Block admin and staging paths
Disallow: /wp-admin/
Disallow: /staging/
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
# Allow CSS and JS for rendering
Allow: /wp-includes/*.js
Allow: /wp-includes/*.css
Allow: /wp-content/themes/*.js
Allow: /wp-content/themes/*.css
# Sitemap location
Sitemap: https://yourdomain.com/sitemap.xml
# AI crawler directives (new for 2026)
User-agent: GPTBot
Allow: /blog/
Allow: /resources/
User-agent: ClaudeBot
Allow: /blog/
Allow: /resources/
User-agent: PerplexityBot
Allow: /blog/
Allow: /resources/
Fíjate en las directivas para rastreadores de IA al final. En 2026, esto ya no es opcional. Si quieres que tu contenido sea citado en respuestas de ChatGPT, Perplexity o Claude, necesitas permitir explícitamente sus crawlers. Si los bloqueas, desapareces por completo de la búsqueda con IA — y ese canal no deja de crecer.
Las primeras 24 horas sirven para apagar incendios. La primera semana sirve para asegurarte de que la base esté sólida. En nuestra migración, el día 3 fue cuando empezó el verdadero pánico — no por una crisis, sino porque ya había pasado suficiente tiempo para que empezaran a llegar datos a Search Console y por fin pudiéramos ver qué estaba pasando. La brecha entre “ya lanzamos” y “ya tenemos datos” inquieta bastante.
| Día | Revisión | Acción requerida | Herramienta |
|---|---|---|---|
| Día 2 | Monitorear errores 404 | Revisar el informe de Coverage de GSC para detectar nuevos errores de rastreo. Configurar monitoreo de enlaces rotos. | Google Search Console, SEOJuice Broken Link Checker |
| Día 2 | Revisar velocidad de carga | Ejecutar auditoría de Core Web Vitals. LCP por debajo de 2.5s, INP por debajo de 200ms, CLS por debajo de 0.1. | PageSpeed Insights, Chrome DevTools |
| Día 3 | Validar datos estructurados | Probar el schema markup en los tipos de página clave (homepage, producto, artículo, FAQ). | Google Rich Results Test |
| Día 3 | Revisar la estructura de enlaces internos | Ejecutar un rastreo para identificar páginas huérfanas. Cada página importante necesita al menos 3 enlaces internos. | Screaming Frog, SEOJuice Internal Linking |
| Día 4 | Verificar hreflang (si es multilingüe) | Confirmar que todas las versiones de idioma se apunten correctamente entre sí. Sin hreflang = contenido duplicado. | Hreflang Tag Checker |
| Día 5 | Auditar meta titles y descriptions | Buscar duplicados, etiquetas faltantes o etiquetas que todavía hagan referencia al sitio o marca anterior. | SEOJuice Site Audit |
| Día 5 | Configurar una línea base de seguimiento de posiciones | Monitorear tus top 50 keywords. Necesitas una línea base para medir el impacto post-lanzamiento. | GSC, SEOJuice keyword tracker |
| Día 6-7 | Revisar archivos de logs del servidor | Comprobar los patrones de rastreo de Googlebot. ¿Está encontrando tus páginas importantes? ¿Qué tan rápido? | Logs de acceso del servidor, Screaming Frog Log Analyzer |
No puedo exagerar la importancia del enlazado interno. Después de lanzar seojuice.com, lo primero que hice fue pasar nuestra propia herramienta de enlaces internos por cada post del blog. Encontramos 34 páginas huérfanas el primer día. Treinta y cuatro páginas a las que Google no tenía forma de llegar. Esas páginas habían recibido tráfico en el dominio anterior — y habrían desaparecido en silencio en el nuevo. El día 3 fue cuando vi las primeras páginas huérfanas apareciendo como “Discovered — currently not indexed” en Search Console. Ese estado es la forma educada que tiene Google de decir “sé que esta página existe, pero no tengo ninguna razón para prestarle atención”. Los enlaces internos le dan a Google una razón para prestarle atención.
A estas alturas, tu sitio ya debería estar indexándose. La fase de emergencia terminó. El primer mes consiste en acelerar lo que está funcionando y corregir lo que no.
| Semana | Revisión | Métrica de éxito | Si falla |
|---|---|---|---|
| Semana 2 | La cobertura de indexación crece | GSC muestra un aumento diario de páginas indexadas | Revisar problemas de crawl budget, páginas huérfanas o recursos bloqueados |
| Semana 2 | No hay caídas de ranking en términos clave | Las top 20 keywords están dentro de 5 posiciones respecto al pre-lanzamiento | Verificar redirecciones 301, revisar etiquetas canonical, auditar contenido on-page |
| Semana 3 | El tráfico orgánico se estabiliza | El tráfico está dentro del 80% de los niveles previos al lanzamiento | Revisar páginas con noindex, redirecciones rotas o contenido faltante |
| Semana 3 | El perfil de backlinks sigue intacto | El número de dominios de referencia coincide con el pre-lanzamiento | Encontrar backlinks rotos y configurar redirecciones |
| Semana 4 | No se activó el content decay | No hay páginas con una caída de tráfico >20% | Auditar URLs cambiadas, actualizar enlaces internos, revisar paridad de contenido |
| Semana 4 | Se mantiene la visibilidad en IA | La marca sigue apareciendo en ChatGPT/Perplexity para consultas clave | Verificar acceso de rastreadores de IA, revisar directivas en robots.txt, actualizar llms.txt |
La métrica de estabilización del tráfico es la que más pánico genera. Esta es la verdad: casi toda migración de sitio tiene una caída temporal de tráfico. Es normal. Google necesita volver a rastrear, reindexar y reevaluar tu contenido con la nueva estructura de URL. Una caída de 10-20% en las semanas 1-2 que se recupera en las semanas 3-4 es totalmente esperable. Una caída del 50% que no se recupera para la semana 4 significa que algo está roto de raíz.
En nuestra migración, la caída fue de 15%. Yo ya lo sabía antes de empezar y aun así revisé la gráfica de tráfico cada hora durante la primera semana. Saber que algo es normal no hace que se sienta normal cuando estás viendo tus propios números.

El checklist no termina a los 30 días. Estas son las cosas que deberías vigilar de forma permanente después de cualquier lanzamiento.
Semanalmente: revisa GSC para detectar nuevos errores de rastreo. Monitorea Core Web Vitals. Revisa cualquier nueva página 404. Esto toma 15 minutos. Ponlo en tu calendario. Yo lo hago todos los lunes por la mañana antes de cualquier otra cosa.
Mensualmente: rastreo completo del sitio para detectar nuevas páginas huérfanas. Auditoría de enlaces rotos. Revisión de content decay en tus 50 páginas principales. Revisión de visibilidad en IA para consultas clave.
Trimestralmente: auditoría técnica completa. Validación de schema markup. Limpieza de cadenas de redirecciones (las cadenas se alargan con el tiempo a medida que agregas más redirecciones — nosotros ya teníamos cadenas de 4 saltos en el mes 2 porque alguien añadió una redirección a una página que ya estaba redirigida). Análisis de enlaces internos para mantener la arquitectura del sitio bien ajustada.

A veces las cosas se rompen incluso siguiendo el checklist. Esta es la prioridad de triage cuando estás mirando un precipicio en tu tráfico.
| Síntoma | Causa probable | Solución | Tiempo de recuperación |
|---|---|---|---|
| Sitio completo desindexado | Etiqueta noindex o robots.txt bloqueando a todos los rastreadores | Quitar el bloqueo, enviar el sitemap, solicitar indexación de la homepage | 3-7 días |
| Caída de tráfico de 50%+ de un día para otro | Redirecciones 301 rotas desde el dominio anterior | Auditar cada redirección, corregir las rotas, enviar sitemap actualizado | 2-4 semanas |
| Páginas específicas no posicionan | Canonical apuntando a la URL equivocada | Corregir etiquetas canonical, solicitar reindexación de las páginas afectadas | 1-2 semanas |
| Se multiplican las páginas Soft 404 | Páginas de plantilla devolviendo 200 sin contenido | Devolver 404/410 correctos para páginas muertas, o agregar contenido real | 1-3 semanas |
| Los rankings cayeron pero las páginas están indexadas | Problema de paridad de contenido — las páginas nuevas tienen menos contenido | Restaurar el contenido faltante, añadir enlaces internos, revisar etiquetas H1 | 2-6 semanas |
| Los rankings móviles se desplomaron | El nuevo diseño no responde bien en móvil | Corregir el layout responsive, probar con Google Mobile-Friendly Tool | 1-2 semanas |
Las dos primeras filas explican alrededor del 80% de las llamadas de emergencia que he recibido después de un lanzamiento. Casi siempre es una etiqueta noindex o redirecciones rotas. No una penalización misteriosa del algoritmo. No una conspiración de Google. Solo casillas que nadie revisó.
Debería practicar lo que predico, así que aquí va lo que pasó cuando movimos SEOJuice del dominio .io al .com en enero de 2026.
Llevábamos más de un año funcionando en seojuice.io. Tráfico decente, buen perfil de backlinks, rankings para nuestras keywords objetivo. Pero yo quería el .com. No por razones de SEO — la extensión .io está bien para búsqueda — sino por confianza. Cuando le vendes a agencias y empresas, tener el .com importa más de lo que debería.
Esto fue lo que hicimos:
Antes del cambio: exportamos cada URL del sitio .io. Construimos un mapa completo de redirecciones. Probamos cada redirección en staging. Actualizamos todos los enlaces internos para que apuntaran a URLs .com. Notificamos a Google mediante la herramienta Change of Address en Search Console.
El día del cambio: desplegamos las redirecciones. Enviamos el nuevo sitemap. Verificamos en GSC que la propiedad .com estuviera recibiendo datos. Monitoreamos logs del servidor para ver actividad de rastreo. Me quedé despierto hasta medianoche viendo cómo subía la tasa de rastreo de Googlebot.
Qué pasó: vimos una caída de tráfico de 15% en la semana 1. Para la semana 3, habíamos vuelto a los niveles previos a la migración. Para la semana 6, el tráfico superó el nivel anterior en 12% — en parte porque el dominio .com parecía ganar más click-through desde las SERPs (la gente confía más en .com, aunque sea de forma subconsciente).
Lo que casi sale mal: teníamos un lote de posts antiguos del blog que usaban URLs .io hardcodeadas dentro del contenido. Las redirecciones capturaban bien el tráfico externo, pero los enlaces internos estaban creando cadenas de redirecciones (la página A enlaza a una URL .io, que hace 301 a una URL .com). Lo detectamos el día 3 durante la revisión de logs del servidor — exactamente por eso esa revisión está en la tabla de la semana 1 de arriba. Si me hubiera saltado la revisión de logs, esas cadenas se habrían acumulado en silencio, cada una agregando latencia y diluyendo link equity.
"Los sitios con buena calidad de contenido, autoridad temática y un SEO técnico limpio suelen estabilizarse rápido después de una migración. Los que no se recuperan son los que ya tenían problemas ocultos antes de moverse."
Eso fue exactamente lo que vivimos. La migración no causó los problemas — los expuso. Las páginas huérfanas que encontramos ya eran huérfanas antes del cambio. Las URLs hardcodeadas eran deuda técnica, no un problema de migración. El checklist simplemente nos obligó a mirar de verdad.
Cada punto de este checklist existe porque alguien, en algún lugar, no lo revisó y perdió tráfico. No estoy exagerando. La revisión de redirecciones está ahí porque un ecommerce de $2M perdió 44% de tráfico orgánico después de una migración en la que alguien olvidó mapear 3,000 URLs de producto. La revisión de noindex está ahí porque una empresa SaaS lanzó con la casilla de “Discourage search engines” marcada y no se dio cuenta durante tres semanas.
El SEO post-lanzamiento no es glamoroso. Es un checklist. Es marcar casillas. Es mirar logs del servidor a las 11pm el día del lanzamiento porque algo no se ve bien. En nuestro día de lanzamiento, yo estaba alternando entre una terminal haciendo tail a los access logs y un niño de dos años gritando porque no quería irse a dormir. Ambas situaciones requerían lo mismo: paciencia, un enfoque sistemático y aceptar que las siguientes 48 horas simplemente iban a ser así.
Pero esa es la diferencia entre un lanzamiento que se convierte en crecimiento acumulativo y uno del que tardas un año y medio en recuperarte.
Haz el checklist.
Para un dominio completamente nuevo, espera entre 1-2 semanas para la indexación inicial después de enviar tu sitemap a Google Search Console. Para una migración de dominio (mismo contenido, nueva URL), Google normalmente reindexa la mayoría de las páginas en 1-4 semanas. Solicitar la indexación de tu homepage y de tus páginas principales mediante la herramienta URL Inspection acelera el proceso. Los sitios con perfiles de backlinks sólidos y contenido actualizado con frecuencia se rastrean más rápido.
Sí. Una caída de tráfico de 10-20% en las primeras 1-2 semanas es completamente normal, incluso en lanzamientos bien ejecutados. Google necesita volver a rastrear y reevaluar tu contenido. La métrica clave es la recuperación: deberías volver a los niveles previos al lanzamiento en 3-4 semanas. Si el tráfico sigue 30%+ abajo después de 4 semanas, algo está mal — empieza por la tabla de soluciones de emergencia de arriba.
No. Tus backlinks antiguos siguen transmitiendo autoridad a través de tus redirecciones 301. Desautorizarlos sería tirar a la basura el link equity que ya ganaste. Solo desautoriza enlaces que ya eran genuinamente spam antes de la migración. La redirección se encarga del resto.
Si tienes uno, sí. Actualízalo con tu nueva estructura de URL y tus páginas de contenido clave. Aunque llms.txt todavía no se ha convertido en un estándar oficial, Claude y Perplexity sí lo consultan. Es una tarea de cinco minutos que ayuda a que los motores de búsqueda con IA tengan un mapa claro de tu contenido. Piensa en él como un sitemap para IA — poco esfuerzo, puede dar mucho retorno.
Si todavía controlas el dominio anterior, configura las redirecciones de inmediato. Si ya no tienes acceso al dominio anterior, concéntrate en conseguir nuevos backlinks hacia tus páginas principales y envía un sitemap completo. Recuperarte sin redirecciones tarda bastante más — espera 3-6 meses en lugar de 3-6 semanas.
Puedes hacer todo este checklist manualmente con Google Search Console y una hoja de cálculo. Pero si prefieres automatizar el monitoreo, esto es lo que yo recomendaría:
SEOJuice Site Audit — Ejecuta una auditoría completa inmediatamente después del lanzamiento. Detecta etiquetas noindex, enlaces rotos, schema faltante y más de 200 problemas automáticamente.
Broken Link Checker — Crítico para detectar fallas en redirecciones. Ejecútalo el día 1 y otra vez el día 7.
SEO Hygiene Checklist — Nuestra guía completa para el mantenimiento SEO continuo. Combina muy bien con este checklist post-lanzamiento para la fase de “monitoreo continuo”.
La fase post-lanzamiento es donde se gana o se pierde la mayor parte del valor SEO. Los equipos que la tratan como un proceso estructurado — no como una celebración — son los que terminan sacando ventaja.
no credit card required
No related articles found.