En corto
- Un buscador indexa direcciones concretas, no contenido. Si cambian las URLs y las antiguas no redirigen, lo acumulado se queda huérfano.
- El fallo peor no es el 404, es el 200 con una página de error dentro: el visitante ve un error y el rastreador ve una página viva.
- Antes de tocar nada, inventario de todas las direcciones que hoy responden, cruzando sitemap, Search Console, analítica, registros del servidor y enlaces externos.
- El mapa de redirecciones se hace una a una, con 301 a la página equivalente. Mandarlo todo a la portada no conserva casi nada.
- curl -sI resuelve la duda en una línea: o hay un 301 con su location, o hay un 200 y tienes un problema.
- La comprobación se hace contra el dominio real, con la dirección antigua exacta, antes de publicar y justo después.
He cambiado la web y he perdido posiciones en Google
El diseño nuevo suele ser mejor. El texto también. Y aun así el tráfico baja.
La causa casi nunca está en lo que se ve, sino en las direcciones. Un buscador no indexa "la página de servicios": indexa una URL concreta. Los enlaces que otras webs te pusieron están atados a esa cadena de texto, no al contenido.
Cuando el rediseño cambia la estructura, esa cadena deja de existir. Y solo hay dos finales. El honesto: la dirección antigua devuelve un 404 y se ve que algo se ha roto. Y el silencioso, que es el que hace daño: devuelve un 200 con una página de error dentro. Para una persona es obvio que falta algo. Para el rastreador, esa dirección sigue viva y con contenido.
¿Por qué una URL borrada puede seguir devolviendo un 200?
Porque el navegador te enseña una pantalla y el servidor manda otra cosa. Son dos capas distintas.
En cada respuesta HTTP viaja un código de estado. El 200 significa "aquí está lo que pediste"; el 301, "esto se ha mudado para siempre a esta otra dirección"; el 404, "esto no existe". El rastreador lee ese código antes que nada y decide con él.
Devolver un 200 con una página de error es facilísimo y pasa sin que nadie lo decida. En una aplicación de una sola página, el servidor entrega el mismo archivo inicial para cualquier ruta y deja que el JavaScript decida qué pintar: la ruta no existe, aparece "Página no encontrada", y la respuesta ya salió con un 200. En muchos paneles hay además una opción para "enviar los errores a la portada": si se resuelve con una reescritura y no con una redirección, la portada se sirve bajo la dirección antigua, otra vez con un 200.
La señal no se traslada, porque nadie ha dicho que haya mudanza.
El inventario de URLs vivas: qué apuntar antes de tocar nada
Este paso va primero, antes del diseño y antes de elegir tecnología. Si la web antigua se apaga sin inventario, la información se pierde. Ninguna fuente vale por sí sola: se cruzan varias y se deduplica.
- El sitemap.xml real de la web actual, descargado, no el que crees que existe
- Search Console y analítica: páginas con clics o visitas del histórico más largo que puedas exportar
- Los registros del servidor, la única fuente que dice qué pide de verdad el rastreador
- Las direcciones con enlaces desde fuera, que son las que más caro sale perder
- Las que viven donde no controlas: correos, anuncios, códigos QR, folletos
El mapa de redirecciones se hace una a una, no con una regla comodín
Con el inventario delante se ordena por lo que duele perder: visitas, enlaces externos, conversiones.
Cada dirección antigua se empareja con la nueva que responde a lo mismo. Mandarlo todo a la portada con una regla comodín es cómodo y es un error: esa redirección masiva tiende a interpretarse como un error más, y quien llega desde un resultado antiguo aterriza donde no está lo que buscaba. Si no hay equivalente exacto se elige la página más cercana, la categoría o la sección madre. Y si no hay nada parecido, se deja morir a propósito en vez de camuflarla.
Lo que se escapa siempre:
- Con barra final y sin barra final son direcciones distintas: elige una y que la otra redirija
- http y https, con www y sin www son cuatro combinaciones y todas deben acabar en la misma
- Nada de cadenas: si la antigua lleva a una intermedia y esa a la definitiva, sobra un salto
- El listado no se borra a los seis meses: los enlaces que te pusieron desde fuera no caducan
Cómo compruebo con curl si una redirección está bien hecha
No hay que instalar nada: curl viene de serie en macOS y Linux, y está disponible en Windows.
curl -sI https://ejemplo.com/servicios/pagina-antigua
La opción -s quita la barra de progreso y la -I pide solo las cabeceras, sin descargar el contenido. Buscas dos líneas.
Bien:
HTTP/2 301
location: https://ejemplo.com/servicios/pagina-nueva
Mal, y este es el caso silencioso:
HTTP/2 200
Si ves un 200 en una dirección que ya no existe, da igual que el navegador muestre un cartel enorme de "no encontrado". Para el buscador esa página existe.
Para ver la cadena completa de saltos se añade -L, que sigue las redirecciones:
curl -sIL https://ejemplo.com/pagina-antigua | grep -iE "^(HTTP|location)"
Deberías ver un solo 301 y un 200 final. Si aparecen tres saltos, sobran dos.
Y para pasar la lista entera de golpe, con las direcciones antiguas en un fichero de texto, una por línea:
while read -r u; do echo "$(curl -s -o /dev/null -w '%{http_code}' "$u") $u"; done < antiguas.txt
Cualquier línea que empiece por 200 o por 404 es trabajo pendiente. Se ejecuta contra el entorno de pruebas antes de publicar, y contra el dominio real justo después. Si ya publicaste y el tráfico ha caído, exporta de Search Console las páginas con clics anteriores al cambio, pásalas por ese bucle y empieza por los 200 falsos.
El código de estado es lo único que cuenta, no lo que se ve en pantalla
Un navegador está hecho para que el usuario no sufra: pinta lo que puede y no avisa de que la respuesta traía un código raro. Por eso una migración parece perfecta mientras el buscador lee otra película.
De ahí salen dos consecuencias. Una redirección hecha con JavaScript o con meta refresh no equivale a una de servidor: la respuesta sale con un 200 y el salto ocurre después, ya en el navegador. La buena se configura en el servidor, en el CDN o en la plataforma de despliegue.
Y se comprueba contra el dominio real, con la dirección antigua exacta. Ver que "sale la portada" en el navegador no prueba nada: ese es justo el síntoma a investigar.
Qué más se rompe en un rediseño además de las direcciones
Las redirecciones son el fallo caro, pero no viajan solas. Esta lista se repasa la víspera de publicar.
- El noindex del entorno de pruebas publicado en producción, en el HTML o en la cabecera x-robots-tag
- Un robots.txt con Disallow heredado del desarrollo, que bloquea el rastreo entero
- Canónicas apuntando todavía al dominio de pruebas o a la dirección antigua
- El sitemap sin regenerar, con las direcciones que acabas de retirar
Preguntas frecuentes
¿Por qué mi web nueva ha perdido posiciones si el contenido es el mismo?+
Porque el buscador no indexa contenido suelto, indexa direcciones concretas. Cada URL antigua tenía enlaces e historial asociados a esa cadena de texto exacta. Si el rediseño cambió la estructura y las viejas no redirigen con un 301 a su equivalente, nada de eso se traslada: el texto es idéntico, pero vive en una dirección que empieza de cero.
¿Qué diferencia hay entre una redirección 301 y una 302?+
La 301 dice que el cambio es permanente y que las señales deben pasar a la dirección nueva. La 302 dice que es temporal y que la antigua volverá a usarse, así que el buscador tiende a mantener indexada la original. En un rediseño, donde la web vieja no vuelve, corresponde un 301. Bastantes paneles ponen 302 por defecto: comprueba el código real.
¿Puedo redirigir todas las URLs antiguas a la página de inicio?+
Técnicamente sí, y es mala idea. Las redirecciones masivas hacia la portada tienden a interpretarse como errores, con lo que no se conserva casi nada. Y quien llega desde un resultado antiguo aterriza sin lo que buscaba, así que se va. Lo correcto es emparejar cada dirección con la página que responde a lo mismo, o con la categoría más cercana.
¿Cómo compruebo el código de estado de una URL sin instalar nada?+
Con curl, incluido en macOS y Linux y disponible en Windows. Se escribe curl -sI seguido de la dirección completa con https: la -s calla la barra de progreso y la -I pide solo las cabeceras. En la primera línea aparece el código. 301 es redirección permanente, 200 contenido normal, 404 no encontrado. Si es un 301, la cabecera location indica el destino.
¿Qué es un soft 404 y por qué es peor que un 404 de verdad?+
Es una dirección que muestra un mensaje de error al visitante pero responde con código 200, diciéndole al buscador que ahí hay contenido válido. Es peor que un 404 limpio porque no figura como error hasta que el buscador lo detecta por su cuenta, y mientras tanto la dirección se considera viva. Se detecta comprobando el código, no la pantalla.
¿Cuánto tiempo hay que mantener las redirecciones de un rediseño?+
Indefinidamente, salvo razón concreta para quitarlas. Los enlaces que otras webs pusieron hacia tus direcciones antiguas no caducan, ni los correos, ni lo impreso. Quitar el listado al año siguiente reabre el agujero que se cerró al migrar. El mapa se guarda como documentación del proyecto, no como un apaño.
¿Rediseño a la vista? Empieza por el inventario
Escríbenos con el dominio y con lo que está previsto cambiar. Si todavía no has publicado, se saca el inventario de direcciones y el mapa de redirecciones antes de tocar el diseño. Y si ya publicaste y el tráfico se ha caído, se miran los códigos de estado uno a uno y sabrás qué está roto y qué no.
Escríbenos y lo miramos