Checklist SEO para rediseño de sitio: migrar sin perder tráfico

Un rediseño de sitio es el momento más habitual en el que el tráfico SEO se destruye en silencio. No por una actualización de Google, ni por un competidor, sino por un lanzamiento en el que alguien se olvidó del mapa de redirecciones, las nuevas URLs quedaron más cortas “porque se ven más limpias” y los datos estructurados vivían solo en los templates viejos. Cuando el dashboard muestra una caída del 40 por ciento en el tráfico orgánico, el proyecto ya cerró, el equipo siguió con otra cosa y alguien queda explicando por qué el nuevo sitio se ve hermoso y no rankea en nada.

Esta checklist existe para evitar esa historia. Recorre el trabajo que tiene que pasar antes, durante y después de un rediseño para que la visibilidad construida durante años viaje con el sitio nuevo en lugar de quedar atrás. Está estructurada alrededor de los momentos en que las cosas realmente fallan.

Por qué los rediseños rompen el SEO

La respuesta corta es que los buscadores ven al sitio viejo y al nuevo como sitios distintos, a menos que les digas explícitamente lo contrario. Cada cambio introduce una posibilidad de que esa señal se rompa.

Las URLs cambian porque la nueva arquitectura es más limpia. El mapa de redirecciones se olvida del long tail. Los meta títulos los reescribe una nueva redactora que no conocía los patrones viejos. Los enlaces internos pasan por tres saltos porque el equipo de desarrollo armó “redirecciones de compatibilidad” sin chequear los destinos. El sitemap XML se genera de cero y solo lista las URLs nuevas en vivo, mientras Google sigue con 50.000 URLs viejas en el índice que ya no resuelven.

Nada de esto es por mala fe. Es el resultado previsible de un proyecto que trata al SEO como una “fase 2” en vez de meterlo en cada decisión. La forma de evitarlo es traer esas decisiones temprano y dejar las respuestas dentro del plan de lanzamiento.

Fase 1: auditoría previa al rediseño

Antes de que el equipo de diseño abra Figma, el equipo SEO necesita una imagen completa de lo que el sitio actual está rindiendo. Esa es la línea base contra la cual se medirá todo lo demás.

Crawlear el sitio actual de punta a punta. Con un crawler SEO real con render de JavaScript, exportar el inventario completo de URLs. Para cada URL, registrar el código de estado, el canonical final, el meta título, la meta description, el H1, la cantidad de enlaces internos, la cantidad de backlinks externos y el tráfico orgánico de los últimos 12 meses. Ese dataset es la fuente de verdad del mapa de redirecciones.

Bajar el rendimiento de Search Console de los últimos 16 meses. URLs que recibieron clics e impresiones, las queries que las trajeron y la distribución de tráfico por página. El 20 por ciento superior de las páginas suele traer el 80 por ciento del tráfico. Esas páginas necesitan un plan explícito de preservación; el long tail se puede manejar con patrones.

Bajar datos de backlinks. URLs con enlaces entrantes. Una página sin tráfico orgánico pero con backlinks de autoridad sigue siendo un activo crítico, porque ese equity fluye a través de ella al resto del sitio. Perder esa página en una migración no se ve en los dashboards de tráfico, pero sí en la autoridad general del sitio a largo plazo.

Mapear los datos estructurados. ¿Qué tipos de schema viven en qué templates? Article, Product, Organization, BreadcrumbList, FAQPage. Cada uno tiene que preservarse en los nuevos templates, idealmente con markup idéntico o mejorado. Una página que pierde su schema FAQPage pierde su lugar en rich results en el próximo recrawl.

Documentar los patrones de URL. ¿Cómo están construidas las URLs hoy? /blog/{slug}, /producto/{categoria}/{slug}, /{lang}/{seccion}/{slug}. El sitio nuevo no tiene que mantener los mismos patrones, pero cada cambio necesita un redirect. Escribí los patrones antes de cualquier decisión sobre la arquitectura nueva.

El producto de la fase 1 es una planilla con cada URL del sitio actual, sus señales clave y su destino planeado en el sitio nuevo. Esa planilla es la fuente de verdad para todo lo que sigue. Una auditoría SEO técnica sólida es el marco correcto para esta fase.

Fase 2: el mapa de redirecciones (el artefacto más importante)

En el mapa de redirecciones es donde fallan la mayoría de las migraciones. Es también la parte que más fácil sale bien si la tomás en serio temprano.

Un mapa de redirecciones es una lista de URLs viejas y la URL nueva a la que cada una debería enviar a un usuario (y a un buscador). Tiene que cubrir todas las URLs alguna vez indexadas, no solo las populares hoy. Páginas olvidadas con buenos backlinks son comunes; aportan autoridad al sitio todos los días hasta que el mapa las descarta.

Reglas de un buen mapa de redirecciones.

Cada redirect es HTTP 301, no 302. Una 301 le dice a Google que el cambio es permanente y transfiere la señal; una 302 mantiene a la URL vieja como canonical y pierde señal. Usá 302 solo para movimientos temporales de verdad (una caída, un A/B test).

Cada redirect cae en un destino relevante, no en la home. Redirigir /blog/post-sobre-hreflang a /blog porque “la home sirve para todo” pierde el match temático. El destino correcto es la página nueva que cubre el mismo tema, aunque no sea un match perfecto. Mejor caer 80 por ciento on topic que en un listado genérico.

Cada redirect es un solo salto. /old-url → /intermediate-url → /new-url es una cadena de redirecciones que pierde equity y enlentece el crawl. Siempre redirigir directo al final, aunque haya que reescribir reglas viejas encadenadas.

Cada versión con parámetros está cubierta. /blog/post?utm_source=... debería redirigir limpio, idealmente con el parámetro removido del lado nuevo. Las versiones con parámetros olvidadas son por las que el analytics se rompe durante semanas después del lanzamiento.

Cómo construir el mapa a escala.

Para cambios por patrón (/blog/post pasa a /articulos/post), usar expresiones regulares en las reglas de redirect. Para casos puntuales, listar cada par explícitamente. La mayoría de los mapas terminan en 70 por ciento patrones y 30 por ciento explícitos, eso es saludable.

Validar el mapa antes del lanzamiento. Correr un crawler contra el sitio nuevo con las URLs viejas como entrada. Toda URL vieja debería pegar en una 301 y aterrizar en un 200. Cualquier 404 en el reporte es un hueco; cualquier 301 a 301 es una cadena; cualquier 200 desde una URL vieja significa que una regla nunca quedó configurada.

Fase 3: decisiones de estructura de URL

Si el sitio nuevo mantiene las mismas URLs, salteá esta fase. La mayoría de los rediseños no lo hace. Las estructuras nuevas son una oportunidad de diseño, pero cada cambio tiene un costo.

Resistite a “ordenar” URLs sin un motivo real. Una URL como /blog/2023/06/titulo-articulo parece vieja, pero cambiarla significa un redirect por cada blog post publicado. Si la estructura con fecha no está dañando activamente (no lo está), dejala. Gastá el presupuesto de redirects en estructuras que de verdad están rotas.

Elegí una jerarquía clara y mantenela. Una URL como /categoria/subcategoria/slug-producto se lee bien para humanos y buscadores. Profundidades inconsistentes (/slug-producto para unas, /categoria/slug-producto para otras) dificultan el crawl y la interpretación.

Decidí las barras finales una vez y para siempre. /sobre/ y /sobre son URLs distintas para los buscadores. Elegí una y forzala con redirect del lado del servidor. Mezclar es una fuga lenta de pares duplicados y de equity de enlaces perdido.

Tratá con cuidado los prefijos de idioma y región. Si el sitio nuevo introduce hreflang por primera vez, eso es un proyecto propio. La guía de implementación de hreflang cubre las reglas.

Evitá las stop words y el relleno. /la-mejor-guia-de-seo es peor que /guia-seo. URLs más cortas y directas se escanean, comparten y recuerdan mejor. Pero más corto no es lo mismo que críptico; /g1 es mala por motivos diferentes.

Una tabla resumen:

Fase 4: traspaso de señales on page

Cada página del sitio nuevo tiene que cargar las señales SEO que llevaron a la página vieja a sus rankings. Es trabajo invisible que desaparece si sale bien.

Title tags y meta descriptions. Traer las etiquetas existentes por defecto. Si el equipo de redacción quiere reescribir, esa es una decisión por página, no un sobrescrito automático. Las páginas con CTR alto en Search Console deberían conservar sus títulos probados. La mecánica completa vive en la guía de meta tags.

Estructura de encabezados. Cada página sigue con un solo H1, H2 y H3 jerárquicos y contenido que mapea a las queries que rankea. Un rediseño que aplana todos los encabezados a divs porque “el sistema de diseño usa divs” es una herida SEO autoinfligida.

Enlaces internos. Mapear el grafo interno antes de la migración. Si la página A enlazaba a la página B con anchor “técnica X” y B ahora es /new-url, el enlace de A debería apuntar a la nueva URL, no pasar por el 301. Los enlaces internos vía 301 no son fatales pero son descuidados y se acumulan.

Etiquetas canonical. Cada página indexable del sitio nuevo necesita un canonical autorreferencial. Las páginas que legítimamente consolidan a otra URL (variantes con parámetros, paginaciones, duplicados regionales) necesitan canonicals apuntando al master. La guía de canonical tags es la referencia.

Datos estructurados. Traer cada tipo de schema de los templates viejos. Si todavía no tenés inventario, hacé un crawl con el marco de la guía de schema markup y usalo como objetivo de migración.

hreflang. Si el sitio es multilingüe, cada anotación hreflang tiene que actualizarse al mismo tiempo que cambian las URLs. Un mapa de redirecciones que se olvida del hreflang deja a Google apuntando a URLs que redirigen a otro lado, lo que rompe el setup internacional.

Fase 5: QA en el entorno de staging

La mayoría de los lanzamientos falla porque el entorno de prueba no se parece lo suficiente al de producción. Construir un staging realista es la mitad del trabajo.

Hacer staging crawleable pero no indexable. Staging debería estar bloqueado para los buscadores con headers noindex y auth básica, pero un crawler con credenciales tiene que poder traerlo. Crawleá staging como Googlebot crawleará producción.

Hacer una auditoría completa contra staging. Las mismas herramientas que en la fase 1. Comparar métricas. Las páginas que tenían meta description todavía la tienen. Las páginas que tenían schema FAQ todavía lo tienen. Las páginas que canonicalizaban a un master siguen haciéndolo.

Verificar los redirects en staging. Aplicar el mapa a la configuración de staging y crawlear las URLs viejas contra él. Cada URL vieja debería resolver a su URL mapeada con una sola 301. Esta es la prueba de mayor palanca de todo el proyecto, porque atrapa tanto reglas faltantes como cadenas.

Probar el render. Si el sitio nuevo es pesado en JavaScript, renderizar cada template clave a través de un crawler que ejecute JavaScript y confirmar que el contenido extraído coincide con el visible. Un sitio moderno que falle este test va a fallar JavaScript SEO al lanzar.

Medir rendimiento. Core Web Vitals en staging predicen Core Web Vitals en producción para la mayoría de los templates. Un diseño nuevo que carga más lento que el viejo es una regresión, aunque sea más bonito. La guía de Core Web Vitals cubre los objetivos.

Levantar Search Console en staging. Configurar Search Console temporalmente para el hostname de staging y enviar un sitemap de muestra. Eso saca a la luz problemas que específicamente le importan a Google y que otras herramientas pueden pasar por alto.

El entregable de la fase 5 es una lista de problemas que hay que resolver antes del lanzamiento y una afirmación firmada de que el mapa de redirecciones funciona como se diseñó. Sin esa afirmación, no hay lanzamiento.

Fase 6: día del lanzamiento

El día del lanzamiento se trata sobre todo de no hacer nada sorprendente. El trabajo se hizo en las fases anteriores; el día del lanzamiento es la ejecución.

Elegir una ventana de bajo tráfico. La mayoría de los sitios tiene una ventana con poco tráfico (madrugada, fin de semana de mañana). Usá esa ventana para que los problemas tempranos afecten a los menos usuarios. Martes a las 10 de la mañana en temporada alta es la ventana equivocada para casi cualquier sitio.

Actualizar DNS, después verificar. Después del cambio de DNS, verificar desde múltiples ubicaciones geográficas que el sitio nuevo responde. La propagación del CDN puede dejar a una región en el sitio viejo durante horas; detectarlo temprano importa.

Enviar el nuevo sitemap XML enseguida. Generar el sitemap nuevo, validarlo, enviarlo a Search Console. Cuanto antes vea Google las nuevas URLs, antes ocurre la reindexación. La guía del sitemap XML cubre la validación.

Crawlear producción con la lista de URLs viejas. Dentro de una hora del lanzamiento, pasar la lista de URLs viejas por un crawler contra producción. Cada URL vieja debería pegar una 301 y aterrizar en 200. Cualquier 404 es un tema crítico y debería resolverse en el próximo deploy.

Mirar los dashboards obvios. Search Console Coverage, Google Analytics tiempo real, tasa de errores, tiempo de respuesta del servidor. Las primeras 24 horas muestran si el lanzamiento está sano. La mayoría de los problemas de lanzamiento son visibles en esta ventana si alguien mira.

Comunicar con el equipo. Los stakeholders tienen que saber que algo de variación de tráfico la primera semana es normal mientras Google reindexa. Una caída del 5 por ciento entre 7 y 14 días es recuperable; una caída del 30 por ciento que no empieza a volver después de dos semanas es un problema real.

Fase 7: los primeros 30 días

Después del lanzamiento, el trabajo pasa de prevenir a detectar. El primer mes es cuando los problemas que se escabulleron del testing aparecen.

Diario en la primera semana:

• Reporte de Coverage de Search Console, mirar nuevos “No encontrado”
• Reporte de Enhancements de Search Console, mirar advertencias de schema
• Logs del servidor, mirar 404 y 500 de Googlebot
• Updates internos por Slack o stand up para que el equipo vea las mismas señales

Semanal en el primer mes:

• Crawl completo del sitio, comparar contra la línea base previa al lanzamiento
• Search Console Performance, mirar las top URLs de la fase 1
• Reportes de backlinks, asegurarse de que los enlaces entrantes siguen resolviendo
• Comparar curvas de tráfico con el mismo período del año anterior, no solo con la semana pasada

Problemas que aparecen en la semana 2:

• Reglas que existen pero redirigen al destino equivocado (match cosmético sin match semántico)
• Páginas que cargan para usuarios pero renderizan vacías para Googlebot (regresión de JavaScript)
• Páginas que perdieron su canonical y ahora compiten con sus propios duplicados
• Páginas que ganaron un noindex por accidente desde un default del CMS nuevo

Problemas que aparecen en la semana 4:

• URLs long tail que nadie recordaba, ahora con 404, acumulándose en el reporte de Coverage
• Schema markup que valida pero no produce rich results porque cayó una propiedad obligatoria
• Patrones de enlaces internos que apuntan a 301 en lugar de la URL final, drenando una fracción de eficiencia de crawl

Un review a los 30 días cierra la migración. Comparar cada señal de la fase 1 con su estado actual. Todo lo que no esté en paridad recibe un ticket. La mayoría de las migraciones no están “terminadas” hasta que el review de 30 días no encuentre nada.

Lo que sale mal aunque hayas hecho todo

Algunos problemas sobreviven incluso a una migración cuidadosa. Saber que existen ayuda a no entrar en pánico cuando aparecen.

La reindexación lleva tiempo. Incluso con un mapa perfecto, Google tarda semanas en consolidar del todo las URLs viejas en las nuevas. Un pequeño bajón de visibilidad durante este período es normal. La curva de recuperación, no el número del día del lanzamiento, es la métrica que importa.

La invalidación de caché va con retraso. Los navegadores, los CDN y el propio caché de Google pueden mostrar versiones viejas durante horas después del lanzamiento. Si un usuario dice “el sitio está roto”, un hard refresh muchas veces lo arregla. Del lado del servidor, revisá dos veces la configuración del CDN.

Algunas queries se mueven. Una página que rankeaba para “zapatillas rojas baratas” puede rankear un poco distinto para esa query después de la migración, aunque el contenido sea idéntico. Google reevalúa una página movida contra su índice actual, y el índice también se movió. Movimientos pequeños son ruido; movimientos grandes en las top páginas son la señal para investigar.

Capturas viejas en Search Console. La herramienta “Live Test” puede mostrar la versión vieja un tiempo porque cachea. Confiá en la vista de historial de URL Inspection, no en la captura, para el estado de indexación.

Para qué usar esta checklist

Para el rediseño de una sola página, esto es exagerado. Para el rediseño de una sección, usá las fases 2, 4, 6, 7. Para una migración total del sitio, las siete fases. La checklist es la columna vertebral; cada proyecto adapta la profundidad de cada fase a su tamaño.

Para más contexto sobre el render en migraciones modernas, la guía de JavaScript SEO y rendering cubre qué cambia cuando el sitio nuevo es React o Vue. Para un marco de auditoría que use los mismos datos de crawl, el checklist de auditoría SEO técnica da la estructura de un programa continuo después de cerrada la migración. Y Seodisias está hecho para hacer visible la brecha entre lo que un crawler ve en el sitio viejo y lo que ve en el nuevo, que es la pregunta diaria durante una migración.

Un rediseño de sitio debería ser un momento de inversión en la marca, no un momento en el que sangra el fundamento SEO que trajo a los usuarios a la marca en primer lugar. Con la preparación correcta, el sitio nuevo lanza mejor que el viejo, en cada señal que importa.