Cómo rediseñar una web sin perder lo que se ha ganado
Un rediseño debe cambiar cómo se vive una empresa, no borrar años de historial de búsqueda. Este es el método de trabajo que usamos para proteger URL, posiciones y enlaces mientras todo lo demás cambia.
, 5 min de lectura, por MigrateSpot
La mayoría de las webs consolidadas parecen más antiguas que las empresas que hay detrás. Y suelen valer más de lo que aparentan. Años de páginas publicadas, enlaces entrantes e historial de búsqueda han generado un patrimonio que no aparece en ningún balance, y un rediseño descuidado puede gastarlo en una sola tarde.
El consejo habitual es cambiar lo menos posible, para que “nadie lo note”. Creemos que eso pone el listón demasiado bajo. Un rediseño debe notarse. Lo que no debe hacer es romper aquello en lo que ya confían los buscadores y los visitantes recurrentes. El método que sigue es cómo separamos ambas cosas.
Empieza con un inventario completo de URL
Antes de que nadie abra una herramienta de diseño, haz una lista de todas las URL que la web actual ha expuesto alguna vez. Eso va más allá de las páginas del menú. Combina el sitemap XML, un rastreo completo de la web en producción, las URL que Google muestra en Search Console, las páginas de destino de tu analítica y, si está disponible, las URL de destino de los enlaces externos según una herramienta de backlinks.
Cada fuente detecta cosas que las demás pasan por alto. Los rastreos encuentran plantillas huérfanas y variantes con parámetros. Search Console encuentra páginas que ya no tienen enlaces internos pero siguen recibiendo impresiones. Los datos de backlinks encuentran antiguas páginas de campaña que nadie recuerda pero a las que otras webs siguen apuntando. El inventario es la lista única con la que se contrasta cada decisión posterior.
Lee los datos antes de decidir nada
Search Console conserva unos 16 meses de datos de rendimiento. Exporta clics e impresiones por página y por consulta para todo el periodo, para que las páginas estacionales no se juzguen por un mes flojo. En GA4, revisa las páginas de destino y las conversiones o eventos clave a los que conducen: una página con un tráfico modesto puede ser aun así donde empiezan la mayoría de las consultas comerciales.
A partir de estas exportaciones, importan tres preguntas para cada URL. ¿Atrae visitas desde la búsqueda? ¿Otras webs la enlazan? ¿Contribuye a consultas, registros o ventas? Una página que responde que no a las tres es candidata a retirarse. Una página que responde que sí a cualquiera de ellas necesita un plan deliberado.
Cuando faltan datos
Muchas de las webs que vemos tienen lagunas, y es mejor decirlo que fingir lo contrario. Puede que Search Console nunca se haya verificado, o solo para un protocolo o subdominio. Puede que el historial de analítica terminara con Universal Analytics, cuyos datos Google ya ha eliminado. A veces el único registro es la propia web en producción.
En esos casos rebajamos nuestra confianza, no nuestro nivel de exigencia. Verifica de inmediato una propiedad de dominio en Search Console, porque cada semana de datos recogida antes del lanzamiento ayuda. Usa los logs del servidor si el hosting los conserva; muestran qué URL se solicitan realmente, tanto por personas como por rastreadores. Usa una herramienta de backlinks para encontrar las URL enlazadas. Si nada nos dice que una página no es importante, la redirigimos a su equivalente más cercano en lugar de dejar que falle.
Conservar, mejorar, fusionar o retirar
Cada URL del inventario recibe una de cuatro decisiones. Aquí es donde un rediseño se convierte en un proyecto editorial más que técnico.
- Conservar: la página funciona y su URL se mantiene. El contenido pasa al nuevo diseño con su sustancia intacta.
- Mejorar: la página tiene demanda, pero el contenido es escaso, está desfasado o es difícil de usar. Mantiene su URL y se reescribe.
- Fusionar: varias páginas compiten por la misma intención. Se convierten en una sola página más fuerte y las demás redirigen a ella.
- Retirar: la página no tiene tráfico, ni enlaces, ni función de negocio. Se elimina y se redirige a la página relevante más cercana o, si ninguna encaja, devuelve un 404 o un 410.
Mapea cada redirección, una a una
Cualquier URL que cambie necesita una redirección permanente en el servidor (un 301 o un 308) a su nuevo equivalente más relevante. Las directrices de Google sobre traslados de sitios son explícitas: las redirecciones deben asignar cada URL antigua a su equivalente nueva concreta y mantenerse durante mucho tiempo, en general al menos un año.
Evita dos atajos habituales. Enviar todo a la página de inicio indica a los buscadores que la página antigua no tiene un sucesor real, y Google puede tratar esas redirecciones como soft 404. Encadenar redirecciones (de la antigua a una intermedia y luego a la nueva) ralentiza el rastreo y diluye la señal. Reduce cada cadena para que cada URL antigua se resuelva en un solo salto, incluidas las URL que ya redirigían antes de empezar el proyecto.
Canonicals y datos estructurados
Cada página nueva debe declarar una URL canónica autorreferenciada que coincida con su dirección final ya redirigida, su entrada en el sitemap y sus enlaces internos. Las señales contradictorias, como un canonical que apunta a una URL que redirige a otro sitio, son una causa frecuente de reindexación lenta tras el lanzamiento.
Los datos estructurados merecen el mismo cuidado. Traslada lo que era válido, como el marcado Organization, Article o BreadcrumbList, y describe solo lo que es visible en la página. Las políticas de datos estructurados de Google dejan claro que el marcado debe reflejar el contenido que ven los usuarios. Un rediseño es un buen momento para corregir el marcado que se ha quedado desfasado.
Un checklist de lanzamiento
- Rastrea la web de staging y confirma que cada página devuelve un 200, lleva el canonical correcto y no está bloqueada por reglas de robots o etiquetas noindex pensadas solo para staging.
- Pasa la lista completa de URL antiguas por las reglas de redirección y comprueba que cada una se resuelve en un solo salto hacia una página con 200.
- Actualiza los enlaces internos para que apunten directamente a las URL finales en lugar de depender de redirecciones.
- Publica un nuevo sitemap XML y envíalo en Search Console.
- Comprueba que la analítica, el consentimiento y el seguimiento de conversiones se activan en las nuevas plantillas.
- Anota la fecha de lanzamiento en tus informes para poder leer los cambios posteriores en su contexto.
Los primeros 90 días
Es normal que las posiciones se muevan algo tras un rediseño importante, mientras los buscadores vuelven a rastrear y reevalúan la web. El objetivo de la monitorización es distinguir las turbulencias normales de los problemas reales con tiempo suficiente para actuar.
Durante las primeras semanas, revisa el informe de indexación de páginas y las estadísticas de rastreo de Search Console, los 404 que aparecen en los logs del servidor y las impresiones de las páginas que más valor aportaban antes del lanzamiento. Compara lo comparable: las mismas páginas, las mismas consultas, los mismos días de la semana. Después, una revisión semanal suele bastar hasta cumplir los 90 días. Si una página importante pierde visibilidad y no se recupera, mira primero qué cambió en esa URL concreta: su redirección, su contenido, sus enlaces internos.
Fuentes
- Google Search Central, “Site moves with URL changes”: developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- Google Search Central, “Redirects and Google Search”: developers.google.com/search/docs/crawling-indexing/301-redirects
- Google Search Central, “How to specify a canonical URL”: developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
- Google Search Central, “General structured data guidelines”: developers.google.com/search/docs/appearance/structured-data/sd-policies
Tu próxima web empieza con la que ya tienes.
Enséñanos tu web actual. Exploraremos en qué puede convertirse.
Reimagina mi web