Auditoría técnica antes de un rediseño: qué medir

Respuesta breve

Antes de rediseñar hay que dejar registrado el estado actual con suficiente detalle para poder comparar después: inventario completo de URLs con su respuesta y sus señales, rendimiento por plantilla, datos de tráfico y conversión por página, y la lista de elementos que generan señales y que el nuevo sitio debe seguir emitiendo. Sin esa línea base, una caída posterior no se puede diagnosticar, porque no hay contra qué contrastar. La auditoría previa no es un trámite: es la única oportunidad de capturar información que desaparece con el sitio antiguo.

Puntos clave

• Todo lo que no se capture antes del lanzamiento se pierde de forma irreversible.
• El inventario debe salir de varias fuentes: rastreo, sitemap, analítica, Search Console, logs y base de datos.
• Un rediseño que cambia URLs es una migración, aunque nadie lo llame así.
• Las señales críticas —canonical, robots, títulos, encabezados, datos estructurados, enlaces internos— deben inventariarse plantilla a plantilla.
• El mapa de redirecciones se construye antes, se prueba en preproducción y se despliega con el cambio, no después.
• Define de antemano qué caída y en qué plazo activan una revisión o una vuelta atrás.

Qué se captura antes de lanzar

1. Inventario de URLsRastreo, sitemap, analítica, Search Console, logs y base de datos.
2. Señales por plantillaCanonical, robots, títulos, encabezados, datos estructurados, enlaces.
3. Rendimiento y campoMétricas por plantilla y tráfico por página.
4. Mapa de redireccionesConstruido antes y probado en preproducción, URL a URL.
5. Umbral de vuelta atrásQué caída y en qué plazo activan la revisión.

Índice

1. Por qué la línea base se toma antes
2. El inventario de URLs
3. Qué se conserva y qué puede cambiar
4. Señales por plantilla
5. Rendimiento y datos de campo
6. El mapa de redirecciones
7. Comprobaciones en preproducción
8. Las primeras semanas
9. Errores frecuentes
10. Próximo paso

Por qué la línea base se toma antes

Tres meses después del lanzamiento, con el tráfico orgánico un treinta por ciento por debajo, la conversación siempre es la misma: ¿qué había antes en esa página?, ¿esa URL existía?, ¿el título era ese? Y nadie lo sabe, porque el sitio antiguo ya no está y las capturas del archivo público son incompletas.

La línea base es un conjunto de ficheros con fecha y método documentado. Un mínimo utilizable:

• Rastreo completo del sitio actual, exportado con todas las columnas.
• Exportación de rendimiento de Search Console por página y por consulta, con el mayor periodo disponible.
• Sesiones, conversiones y valor por página de la analítica, para un periodo comparable.
• Ficheros de sitemap tal como se sirven hoy.
• Copia del robots.txt y de las cabeceras relevantes.
• Un mes de log de servidor, si hay acceso.
• Copia del HTML publicado de una URL por plantilla.

El último punto es el que más se agradece meses después: un fichero por plantilla con el HTML tal cual se sirve permite comparar señal por señal. Guárdalo todo junto, fechado, donde sobreviva al proyecto.

El inventario de URLs

Un rastreo solo encuentra lo que está enlazado. Un inventario completo cruza fuentes, porque cada una ve una parte distinta:

Fuentes del inventario de URLs: qué aporta cada una y qué se le escapa.

Fuente	Qué aporta	Qué se le escapa
Rastreo propio	Lo enlazado y su estado	Huérfanas y lo no enlazado
Sitemap	Lo declarado como inventario	Lo que el sitemap no incluye
Search Console	Lo que recibe impresiones	Lo que nunca posicionó
Analítica	Lo que recibe visitas por cualquier canal	Lo que no tiene tráfico
Logs	Lo que se pide de verdad	Nada relevante, si el periodo es amplio
Base de datos	Todo lo publicado, incluido lo oculto	URLs generadas por reglas o plugins

La unión de las seis listas suele contener bastantes más URLs de las esperadas. Ahí aparecen las páginas huérfanas con tráfico —las que nadie recuerda y siguen recibiendo visitas—, los restos de una migración anterior y las URLs con parámetros que alguien enlazó desde fuera.

Con la lista unificada, clasifica cada URL: se mantiene igual, cambia de dirección, se fusiona con otra, se retira. Esa clasificación es el documento que gobierna el resto del proyecto y debe decidirse con datos de tráfico y enlaces delante, no por criterio estético.

Qué se conserva y qué puede cambiar

Un rediseño puede cambiar plantilla, tipografía, estructura visual y sistema de diseño sin tocar nada de lo anterior. El riesgo aparece cuando cambian, a menudo sin intención declarada, las URLs, la jerarquía o el contenido.

Cambios de bajo riesgo: maquetación, paleta, componentes visuales, orden de bloques dentro de una página, sistema de rejilla.

Cambios de riesgo alto que exigen plan explícito:

• Estructura de URLs, incluido añadir o quitar un segmento o una barra final.
• Fusión o eliminación de páginas con historial.
• Reescritura del contenido de páginas que ya posicionan.
• Cambio de la jerarquía de encabezados y del enlazado interno.
• Sustitución del gestor de metadatos y datos estructurados.
• Paso de contenido servido en HTML a contenido generado por JavaScript.
• Cambio de dominio, subdominio o protocolo.

Cuando varios de estos coinciden, el proyecto ya no es un rediseño: es una migración con rediseño encima, y el riesgo se acumula; conviene entonces trabajar con el plan de migración de web sin perder posiciones. Separarlos en dos lanzamientos cuesta más calendario y hace que, si algo falla, sepas cuál de los dos lo causó.

Señales por plantilla

El nuevo sitio debe seguir emitiendo lo que el anterior emitía, salvo donde haya una decisión consciente de cambiarlo. La forma práctica de asegurarlo es una tabla por plantilla con el valor actual y el valor previsto.

• Título y meta descripción, y de dónde salen.
• Etiqueta canonical y su regla de generación.
• Directivas de robots en meta y en cabecera.
• Jerarquía de encabezados, con un solo h1 por página.
• Datos estructurados: tipos emitidos y componente que los genera.
• Enlaces internos que la plantilla genera de forma automática.
• Anotaciones de idioma, si el sitio es multilingüe.
• Migas de pan y navegación secundaria.
• Paginación y su comportamiento.

La regla del canonical merece atención propia, porque el cambio de tema suele traer una fuente nueva que sobrescribe la anterior en silencio; los casos donde el contexto cambia la decisión están recogidos en errores con la etiqueta canonical. Y toda esta tabla es exactamente el tipo de evidencia reproducible que exige una auditoría SEO técnica bien planteada: hallazgo, evidencia, acción y prueba de salida.

Rendimiento y datos de campo

Un rediseño puede mejorar mucho el aspecto y empeorar el rendimiento, sobre todo si introduce un constructor visual, tipografías nuevas o animaciones; el impacto real de esa decisión se compara midiendo, como plantea Elementor frente a desarrollo a medida. Sin línea base, esa degradación se descubre cuando ya está consolidada.

Registra, por plantilla y antes del cambio:

• Valores de campo de LCP, INP y CLS, con los umbrales de referencia en 2,5 s, 200 ms y 0,1 en el percentil 75.
• Peso total y número de peticiones, separando HTML, CSS, JavaScript, imágenes y fuentes.
• Tiempo de respuesta del servidor en condiciones comparables.
• Elemento que forma el LCP en cada plantilla.
• Inventario de scripts de terceros con su origen y responsable.

Ese inventario de terceros suele ser el hallazgo más rentable de toda la auditoría previa. Un rediseño es la única ocasión razonable para retirar herramientas que ya no responden a ninguna decisión activa, porque después nadie vuelve a abrir esa conversación.

El mapa de redirecciones

Si alguna URL cambia, el mapa se construye en la fase de diseño, no la noche del lanzamiento. Reglas que evitan los problemas habituales:

• Cada URL antigua redirige a su equivalente más próximo, no a la portada ni a una categoría genérica.
• Una URL sin equivalente real es mejor que devuelva 404 o 410 que una redirección engañosa.
• Un solo salto: origen a destino final, sin encadenar reglas antiguas con nuevas.
• Redirección permanente cuando el cambio es permanente.
• Conserva los parámetros que el destino necesita y descarta los que no.
• Prueba el mapa completo antes del despliegue, no una muestra.
• Actualiza también los enlaces internos al destino nuevo: la redirección es una red de seguridad, no la solución.

Un detalle que rompe mapas enteros: la barra final. Si el sitio nuevo la añade o la quita, cada URL del inventario cambia aunque el slug sea idéntico. Decídelo pronto, aplícalo de forma coherente y comprueba que no se genera un doble salto.

Comprobaciones en preproducción

El entorno de pruebas debe estar cerrado al rastreo, y esa protección debe poder retirarse de forma limpia. La forma más segura es autenticación a nivel de servidor: bloquear con noindex funciona, pero es exactamente la etiqueta que después se olvida en producción.

Antes de aprobar el lanzamiento, comprueba sobre el entorno de pruebas:

• Rastreo completo y comparación con el inventario: qué URLs faltan y cuáles son nuevas.
• Que el contenido principal está en el HTML servido y no depende de ejecución en cliente.
• Que la tabla de señales por plantilla se cumple.
• Que el mapa de redirecciones resuelve en un salto y sin bucles.
• Que los sitemaps generados contienen lo que deben y nada más.
• Que el robots.txt de producción es el correcto y no el de pruebas.

La lista de verificación previa al lanzamiento debe tener responsable y firma. Un lanzamiento sin nadie que responda de cada punto es el escenario en el que aparece el noindex global una semana después.

Un lanzamiento sin nadie que responda de cada punto es el escenario en el que aparece el noindex global una semana después.

Las primeras semanas

Después del cambio la fluctuación es normal, y el riesgo es interpretarla demasiado pronto. Define de antemano qué mirar y cada cuánto.

• Primeras horas: códigos de estado en el log, errores de servidor, comprobación manual de las veinte URLs de más tráfico.
• Primeros días: cobertura e indexación de las URLs nuevas, redirecciones detectadas, avisos en Search Console.
• Primeras semanas: impresiones y clics por página comparados con la línea base, y conversión sobre el mismo periodo del año anterior si el negocio es estacional.

Si el tráfico baja, resiste la tentación de tocar diez cosas a la vez. Un descenso puede venir del rediseño, de una actualización del algoritmo, de la estacionalidad o de un cambio de medición, y el método para separarlos está en diagnosticar una caída sin saltar a conclusiones. La línea base que capturaste al principio es lo que convierte ese diagnóstico en algo resoluble. Y si el origen resulta ser una actualización del algoritmo y no el rediseño, el camino es otro: recuperar tráfico tras una caída, con diagnóstico antes que remedio.

En cuatro láminas

curl -sI https://seonidas.com/. HTTP/1.1 200 / content-type: text/html; charset=UTF-8 / cache-control: public, max-age=600, must-revalidate / strict-transport-security: max-age=31536000; includeSubDomains / x-content-type-options: nosniff / referrer-policy: strict-origin-when-cross-origin / cross-origin-opener-policy: same-origin / server: hcdn. Leído el 28 de septiembre de 2026.

shell: $ for p in / /blog/ /blog/x/ /seo-tecnico/ /contacto/ / curl -s "https://ejemplo.es$p" \ / > linea-base/$(basename ${p:-inicio}).html / $ sha256sum linea-base/*.html > linea-base/sumas / / # el HTML tal cual se sirve, por plantilla: / # permite comparar señal por señal

1 umbral de vuelta atrás. Qué caída, en qué métrica y en qué plazo activan la revisión o la vuelta atrás. Decidido antes, no con el sitio caído.

Errores frecuentes

• Empezar el rediseño sin exportar nada del sitio actual.
• Construir el inventario solo con un rastreo y perder las páginas huérfanas con tráfico.
• Cambiar URLs sin considerarlo una migración.
• Redirigir todo lo que no tiene equivalente a la portada.
• Encadenar redirecciones nuevas sobre las antiguas.
• Dejar el noindex del entorno de pruebas en producción.
• Rediseñar y migrar de dominio en el mismo despliegue.
• Interpretar la fluctuación de la primera semana como un resultado.

Preguntas habituales

¿Qué se pierde si no capturo nada antes del rediseño?

Todo lo que sirve para comparar después: qué URLs había, qué señales llevaban, qué rendía cada plantilla y qué páginas traían tráfico. Es una pérdida irreversible, porque el sitio anterior deja de existir el día del cambio. Sin ese registro, cualquier caída posterior se discute con opiniones.

Solo cambio el diseño, no las URLs. ¿Es una migración?

Si alguna URL cambia, sí lo es, se llame como se llame. Y conviene revisarlo en detalle: los rediseños suelen mover paginaciones, archivos, categorías y adjuntos aunque las páginas principales se conserven. Ahí es donde aparecen después los 404 que nadie esperaba.

¿Basta con un rastreo para hacer el inventario?

No: un rastreo solo encuentra lo enlazado, así que deja fuera las páginas huérfanas, que a veces son las que traen tráfico. El inventario se cruza desde varias fuentes —rastreo, sitemap, analítica, Search Console, logs y la base de datos— y de ahí sale la lista real.

¿Cuándo decido que hay que volver atrás?

Antes de lanzar. Se fija qué caída, en qué métrica y en qué plazo activan una revisión o una vuelta atrás; decidirlo con el sitio ya caído es tarde y se decide mal. Un umbral escrito convierte una discusión en una comprobación.

Próximo paso

Antes de aprobar el primer diseño, monta la carpeta de línea base con las seis exportaciones y el HTML de una URL por plantilla, todo fechado. Después construye la lista unificada de URLs y clasifícala en mantener, redirigir, fusionar o retirar. Ese documento es el que debe gobernar el proyecto; si el rediseño avanza sin él, lo que estás decidiendo no es el aspecto del sitio, sino cuánto vas a perder sin saber por qué.

Fuentes

• Google Search Central, cambios de sitio con cambio de URL — documentación oficial.
• Google Search Central, redirecciones y la Búsqueda — documentación oficial.
• Google Search Console, informe de indexación de páginas — documentación oficial.

Servicio relacionado

Si esto es lo que te está pasando, auditoría seo es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver auditoría seo