Hay una historia que se repite constantemente en marketing.
Una empresa lleva años construyendo presencia orgánica. Primeras posiciones, tráfico constante, leads que llegan solos. Entonces deciden renovar el sitio. Contratan una agencia de diseño, invierten seis meses y una cifra importante. El resultado visual es impresionante.
Y después del lanzamiento, el tráfico cae 40%.
No es mala suerte. Es que nadie en el proyecto pensó en SEO hasta que ya era demasiado tarde.
Un rediseño web mal ejecutado puede destruir en semanas lo que tardaste años en construir. Pero también puede ser exactamente lo contrario: la oportunidad de ordenar todo lo que quedó mal desde el principio y salir con mejor posicionamiento del que tenías.
La diferencia está en el proceso.
Antes de entrar al checklist, vale entender qué sale mal.
El error más común es tratar el rediseño como un proyecto de diseño. Se elige agencia, se aprueban paletas de colores, se construye el sitio, y el SEO aparece como ítem de último momento. A veces ni eso.
El problema es que Google no evalúa si tu sitio se ve bien. Evalúa estructura, velocidad, contenido, y la red de enlaces que apunta a tus páginas.
Cuando cambias URLs sin redireccionamientos correctos, reorganizas la arquitectura sin planificación, o migras a un nuevo CMS sin considerar cómo renderiza el contenido, le estás diciendo a Google que el sitio que indexó ya no existe.
Y Google te trata en consecuencia.
Otros problemas frecuentes: páginas que generaban tráfico y se eliminan sin redirect, contenido reescrito que pierde las palabras clave que lo posicionaban, velocidad que empeora con el nuevo diseño, y etiquetas técnicas que se rompen en la migración.
Todo esto es evitable. Solo requiere incluir SEO desde el día uno del proyecto, no el día antes del lanzamiento.
Tu primer trabajo, antes de cualquier decisión de diseño, es saber exactamente qué está funcionando hoy.
Exporta los datos de Google Search Console: qué queries traen tráfico, qué páginas tienen más impresiones, qué URLs generan clics. Descarga el tráfico por página desde Google Analytics. Extrae un snapshot de tus backlinks con alguna herramienta como Ahrefs o Semrush.
Esos datos son tu línea de base. Sin ellos, después del lanzamiento no vas a saber si mejoraste o empeoraste, ni por qué.
Luego haz un crawl completo del sitio actual. Herramientas como Screaming Frog o Sitebulb rastrean todas tus URLs y documentan títulos, meta descriptions, encabezados, canonical tags, códigos de estado y estructura de enlaces internos. Guarda eso. Es tu mapa del sitio actual y la referencia contra la que vas a comparar el nuevo.
No todo lo que tienes en el sitio merece seguir existiendo. Pero tampoco todo lo que parece viejo o "feo" merece eliminarse.
Clasifica tus páginas en cuatro categorías. Las que mantener tal como están porque posicionan bien. Las que mejorar y actualizar porque tienen potencial pero están desaprovechadas. Las que consolidar porque tienes varios artículos sobre lo mismo que compiten entre sí. Y las que eliminar porque no generan tráfico, no tienen backlinks, y no aportan nada.
Las páginas que eliminas necesitan un plan. Si tienen backlinks que apuntan a ellas o generaban aunque sea algo de tráfico, necesitan redirect a la URL más relevante que las reemplace. Si son páginas completamente irrelevantes sin ningún valor, un 404 es aceptable, pero siempre con conciencia de la decisión.
Antes de que el diseñador abra Figma, el equipo de SEO, interno o externo, necesita tener claras las reglas del juego.
¿Qué URLs no pueden cambiar bajo ninguna circunstancia? ¿Cuál es la estrategia para las que sí van a cambiar? ¿Cómo va a manejarse la arquitectura de la nueva navegación? ¿Qué páginas tienen backlinks de alta calidad que hay que proteger a toda costa?
Estas decisiones después son difíciles y caras de cambiar. Antes del diseño son conversaciones de media hora.
La arquitectura de información es cómo organizas el contenido del sitio: qué páginas existen, cómo se relacionan entre sí, cómo navega un usuario desde la homepage hasta lo que busca.
Una buena arquitectura hace que las páginas importantes estén a pocos clics de la homepage. Usa breadcrumbs que muestren la jerarquía. Agrupa contenido relacionado en clusters temáticos con buena vinculación interna.
Una arquitectura mal diseñada entierra contenido, dispersa la autoridad de dominio en páginas que no importan, y confunde tanto a usuarios como a crawlers.
Este es el trabajo más operativo del proceso y también el más crítico.
Crea una hoja de cálculo con cada URL existente. Para cada una, define qué va a pasar: la URL se mantiene igual y el contenido se migra sin cambios, la URL cambia y necesita redirect 301 hacia la nueva, el contenido se consolida con otra página y la URL redirige hacia ella, o la página se elimina sin redirect.
Los redirects 301 le dicen a Google que el contenido se movió permanentemente y transfieren la autoridad de la URL original a la nueva. Sin ellos, pierdes todo el equity acumulado.
Con redirect chains, un redirect que lleva a otro que lleva a otro, pierdes parte de ese equity de todas formas. Lo ideal es siempre redirect directo de origen a destino final.
El error clásico es pensar que el SEO técnico se puede resolver en la fase de post-lanzamiento. No funciona así.
Cada página del nuevo sitio necesita título único y con la keyword objetivo, meta description que invite al clic, estructura de encabezados lógica (un solo H1, H2s que organizan el contenido), alt text en las imágenes, y canonical tags que apunten a la versión correcta de la página.
Si tienes páginas en varios idiomas, los hreflang deben estar configurados antes de lanzar. Si tienes versiones desktop y mobile con URLs distintas, la configuración de mobile-first necesita estar lista.
Si migras a un framework JavaScript como React o Vue, tienes que confirmar que el servidor renderiza el contenido antes de enviárselo al crawler, no después.
Google usa la velocidad de carga como factor de ranking. Y más allá del ranking, casi la mitad de los usuarios abandona un sitio que tarda más de tres segundos en cargar.
Los principales culpables de sitios lentos son imágenes sin optimizar, JavaScript que bloquea el renderizado, falta de caché, y ausencia de CDN. Un rediseño es la oportunidad perfecta de resolver todos estos problemas de raíz, no de arrastrarlos al nuevo sitio.
Las métricas que importan son tres. LCP, que mide cuánto tarda en cargar el elemento visual más grande de la página, debe estar bajo 2.5 segundos.
CLS, que mide cuánto saltan los elementos mientras carga, debe estar bajo 0.1. Y FID, que mide la respuesta a la primera interacción del usuario, debe estar bajo 100 milisegundos.
Antes de lanzar, el nuevo sitio tiene que vivir en un entorno de staging bloqueado para crawlers. Ahí corres todas las pruebas. Nunca lanzas directamente a producción sin haber validado todo.
El testing pre-lanzamiento incluye correr un crawl completo del staging para verificar que todos los redirects están correctamente configurados, que los códigos de estado son los correctos, que los metadatos están en su lugar, y que no hay páginas del staging que hayan quedado accesibles para Google.
También necesitas validar que los scripts de analytics y Google Tag Manager están disparando correctamente en todos los tipos de página. Si lanzas sin tracking funcional, pierdes datos en el momento más crítico para poder diagnosticar cualquier problema.
Y, si es posible, prueba velocidad en el staging. Muchos servidores de staging son más lentos que producción, así que los números no van a ser exactos, pero los problemas estructurales sí se detectan.
El día que lanzas, las primeras acciones son técnicas. Habilitar crawling e indexación en el sitio de producción. Subir el sitemap actualizado a Google Search Console y Bing Webmaster Tools. Poner una anotación en Google Analytics marcando la fecha del lanzamiento para poder comparar métricas antes y después.
Luego, vuelve a correr el crawl en producción y compara contra el del staging. Confirma que todo lo que estaba bien en staging sigue bien en producción.
El tráfico orgánico no responde inmediatamente a los cambios. Google necesita recrawlear, reindexar, y reevaluar el sitio. Ese proceso puede tomar semanas.
Lo que sí puedes monitorear desde el primer día es Search Console: errores de indexación, páginas que aparecen con errores 404, cobertura del sitemap. Cualquier spike de errores en los primeros días post-lanzamiento necesita atención inmediata.
Durante las primeras ocho semanas, revisa semanalmente rankings de las páginas más importantes, tráfico orgánico por plantilla de página, y backlinks apuntando a URLs que ya no existen. Cualquier caída sostenida por más de dos semanas en páginas específicas es señal de que hay un problema técnico que diagnosticar, no de que "el SEO tarda en actualizarse".
Si detectas páginas que perdieron posicionamiento sin razón aparente, compara el contenido nuevo contra el anterior. A veces las reescrituras eliminan accidentalmente las keywords que posicionaban, o cambian el intent que Google estaba leyendo en la página.
Un rediseño web bien ejecutado no debería costarte tráfico. Debería darte la oportunidad de recuperar terreno en keywords donde estabas perdiendo, mejorar páginas que nunca rindieron su potencial, y construir una base técnica más sólida que la que tenías. Todo eso es posible. Solo requiere que el SEO sea parte del proyecto desde el primer día, no el problema que resolver después del lanzamiento.
.png){kind=small}
SEO consulting that scales traffic, grows your brand, increases revenue, and helps you win on Google and AI platforms and LLMs like ChatGPT.
%402x.svg){kind=icon}
