Rediseñar un sitio suele implicar cambiar su estructura de URL. Sin un plan de redirecciones, cada dirección que desaparece se lleva consigo el posicionamiento acumulado y envía a los visitantes a una página de error. No es un asunto cosmético: una redirección mal puesta se traduce en tráfico perdido desde las primeras pasadas del rastreador. Esta guía cubre la elección de los códigos HTTP, la construcción del plan, la canonicalización, la implementación en el servidor y el control tras la puesta en marcha.
Lo que transmite una redirección y lo que destruye un error
Una redirección permanente indica al navegador y al motor de búsqueda que el contenido ha cambiado de dirección de forma definitiva. El motor transfiere entonces la mayor parte de la señal de posicionamiento de la antigua URL a la nueva y actualiza su índice. A la inversa, una URL eliminada sin redirección devuelve un 404: los enlaces externos que apuntaban a ella se convierten en callejones sin salida y la señal que aportaban desaparece. Un rediseño logrado conserva la correspondencia entre cada antigua dirección útil y su destino.
La transferencia no es instantánea. El motor debe volver a pasar por la antigua URL, constatar la redirección y luego reevaluar el destino. Ese plazo, de unos días a unas semanas según la frecuencia de rastreo, explica por qué una caída temporal de tráfico tras un cambio no tiene nada de anormal, siempre que las redirecciones sean correctas.
301, 302, 307, 308: elegir el código correcto
El código HTTP no es un detalle. Le dice al motor si el cambio es permanente y si debe transferir la señal. Equivocarse de código supone o bien conservar la antigua URL en el índice, o bien perder la transferencia.
| Código | Naturaleza | Método conservado | Uso recomendado |
|---|---|---|---|
| 301 | Permanente | No garantizado (puede forzar GET) | Rediseño, cambio de URL definitivo |
| 302 | Temporal | No garantizado | Mantenimiento, test A/B breve |
| 307 | Temporal | Sí | Redirección temporal de un POST |
| 308 | Permanente | Sí | Cambio definitivo que preserva el método |
Para un rediseño la regla es sencilla: 301 para las páginas, 308 cuando el método HTTP debe preservarse. El 302 se reserva a situaciones realmente temporales, ya que no invita al motor a actualizar su índice.
Construir el plan de redirección antes del cambio
El plan se prepara durante el rediseño, nunca después. Consiste en una tabla de correspondencia entre cada antigua URL y su destino, elaborada a partir de tres fuentes cruzadas: la exportación de las URL indexadas desde Search Console, la lista de las páginas más visitadas y los enlaces entrantes conocidos. Cada antigua URL con valor recibe un destino en una página equivalente, no sistemáticamente la página de inicio, que diluye la señal.
Redirigir todas las páginas antiguas a la página de inicio no es un plan de redirección: es una pérdida de señal disfrazada de solución.
Algunos casos merecen atención especial. Las URL con parámetros (filtros, orden, seguimiento de campaña) no se redirigen una a una: es mejor una regla sobre la ruta, conservando o no los parámetros según su función. Las páginas de paginación, los archivos y las URL de imágenes también cambian durante un rediseño y deben figurar en el plan. Por último, la continuidad editorial importa tanto como la técnica: una página que llevaba datos estructurados debe recuperar un marcado equivalente en su destino, de lo contrario los resultados enriquecidos desaparecen hasta que el motor reevalúa la nueva página.
Canonicalización: forzar una única versión de cada URL
Un rediseño es el buen momento para consolidar los puntos de entrada duplicados. Mientras http:// y https://, la versión con y sin www, o las variantes con y sin barra final respondan todas con un 200, el motor ve varias URL para un mismo contenido y debe decidir él mismo cuál indexar. La elección se fuerza con una redirección permanente hacia una forma única, llamada canónica. En nginx, la práctica idiomática pasa por bloques de redirección dedicados en lugar de pruebas condicionales:
# HTTP a HTTPS: todo el tráfico en claro va a la versión segura
server {
listen 80;
server_name ejemplo.com www.ejemplo.com;
return 301 https://www.ejemplo.com$request_uri;
}
# Versión sin www hacia la versión canónica con www
server {
listen 443 ssl;
server_name ejemplo.com;
return 301 https://www.ejemplo.com$request_uri;
}El mismo principio se aplica a la barra final: elegir una convención, la misma en todas partes, y redirigir la otra forma con un 301. Lo importante es la coherencia, no la elección en sí.
Implementarlo en el servidor
La redirección se coloca en el servidor web, por delante de la aplicación, para seguir siendo rápida e independiente del código. En nginx, una correspondencia exacta se declara con return 301, un patrón completo con rewrite:
server {
listen 443 ssl;
server_name www.ejemplo.com;
# Redirección exacta, página antigua a nueva
location = /antigua-seccion/articulo {
return 301 /nueva-seccion/articulo/;
}
# Redirección de un patrón completo a un nuevo árbol
location /blog/ {
rewrite ^/blog/(.*)$ /articulos/$1 permanent;
}
}El resultado se verifica en la respuesta HTTP: el código debe ser 301 y la cabecera Location debe apuntar a la URL final, en un solo paso.
GET /antigua-seccion/articulo HTTP/1.1
Host: www.ejemplo.com
HTTP/1.1 301 Moved Permanently
Location: https://www.ejemplo.com/nueva-seccion/articulo/Basta un control por línea de comandos para confirmar el comportamiento sin abrir un navegador:
curl -sI https://www.ejemplo.com/antigua-seccion/articulo \
| grep -i -E '^(HTTP|location)'Esta lógica vale sea cual sea el alojamiento, incluida una pila autoalojada donde el servidor web es directamente accesible.
Evitar cadenas y bucles
Dos defectos recurrentes degradan un rediseño. La cadena de redirecciones —A redirige a B que redirige a C— añade idas y vueltas, ralentiza el renderizado y diluye la señal transmitida: cada antigua URL debe apuntar directamente a su destino final. El bucle —A a B, B a A— vuelve la página inaccesible y provoca un error del navegador. Una auditoría de las redirecciones antes de pasar a producción detecta ambos.
Controlar tras la puesta en marcha
El cambio no es el final del trabajo. En los días siguientes se imponen tres verificaciones: enviar el nuevo mapa del sitio a Search Console y vigilar la cobertura de indexación, seguir la evolución del tráfico para detectar una página que se descuelga, y leer los registros del servidor en busca de los 404 que aún se sirven. El panel de control que cruza analítica y Search Console hace legibles esas señales de un vistazo. Un pico de 404 en los registros casi siempre señala una antigua URL olvidada en el plan; se corrige añadiendo la redirección que falta, sin esperar a que el motor constate el error.
Lo que hay que recordar
Un rediseño conserva su posicionamiento cuando el plan de redirección se prepara antes del cambio, apoyado en datos reales de indexación y tráfico, colocado como 301 directas en el servidor y controlado tras la puesta en marcha. El código HTTP se elige según la naturaleza del cambio, los puntos de entrada duplicados se consolidan hacia una URL canónica, los destinos siguen siendo pertinentes página a página, y las cadenas y los bucles se eliminan de antemano. Nada espectacular: método, aplicado en el momento adecuado.
En los rediseños que he llevado, la redirección nunca es la etapa que falla: es el plan lo que falta. Mantengo una regla simple —ninguna URL se elimina hasta que su destino esté escrito negro sobre blanco en la tabla de correspondencia— y hago correr un control de los 404 cada día la primera semana. Es laborioso, pero es exactamente lo que distingue un rediseño que conserva su tráfico de uno que lo deja escapar. — Simon Janvier
Para profundizar: la documentación de Google Search Central sobre las redirecciones y su efecto en el rastreo y la indexación.
