Es por ello que por cuestión de la experiencia del usuario se tienen que hacer redirecciones a pesar de esos cambios en la URLs. Sin embargo, por diversos motivos las redirecciones que hagamos, cómo las hagamos y la metodología de implementación pueden afectar a nuestro posicionamiento web.
Cómo son muchas las variables, voy a establecer distintas clasificaciones y qué debería o no aplicar en cada caso.
Debemos saber a qué tipo de redirección nos atenemos.
- Redirección permanente
- Redirección temporal
En general se entiende que una redirección permanente es para mover de forma definitiva el contenido a otra URL y la temporal es para cuando por algún motivo, esa URL no está disponible de forma temporal y se envía el contenido a otro sitio.
Si la redirección es temporal, los sistemas de Google lo tomarán como un indicador débil de que la página nueva (la final, de destino) es la canónica (la que se pone en los resultados de búsqueda), mientras que con la permanente es un indicador fuerte de que la página final es la canónica.
Esto es lo que te pone la propia documentación de Google, pero vamos a aterrizar esto.
El efecto real de una redirección temporal, es que la URL antigua se mantendrá un poco más de tiempo en los índices de Google que con la redirección permanente, pero realmente en ambas situaciones Google acabará tomando la URL final como URL de destino.
La redirección permanente hará que Google se tome unos pocos días (entre que rastrea y verifica) como mucho en hacer el cambio en las SERPs mientras que con la temporal lo hará pero puede tomarse entre unas semanas hasta casi un mes. Casi como ocurre con la desindexación cuando es un 4xx o un 5xx.
En cuanto a la realidad práctica, en la mayor parte de ocasiones hay soluciones muchísimo mejores que la de realizar una redirección temporal. Ya que si alguien pretende hacer una redirección temporal es porque su intención es la de no modificar la URL original de los resultados de Google.
Dependiendo del tipo de circunstancia la mayor parte de situaciones se pueden resolver con un entorno de prueba y una buena planificación sin necesidad de arriesgarnos a un comportamiento indeseado de Google.
En cualquiera de los casos, te voy a ayudar con una guía de los tipos de redirección.
| Método de redirección | Descripción | Tipo (SEO) | Ventajas | Desventajas |
|---|---|---|---|---|
| Servidor (HTTP) | Se realiza modificando la cabecera HTTP, devolviendo un código 3XX. | ✅ Muy recomendable | • Compatible con todos los motores de búsqueda- Inmediata y robusta • Funciona para todo tipo de recursos (HTML, imágenes, PDFs…) • No requiere carga del contenido | • Requiere acceso al servidor • Mala implementación puede romper la web • No todos los CMS lo permiten fácilmente |
| Meta Refresh | Redirección por una etiqueta meta http-equiv="refresh" en el head del HTML. | ⚠️ Aceptable con reservas | • Se puede aplicar donde no hay acceso a servidor • Simple si tienes control del HTML | • Solo funciona con HTML • No apta para redirección masiva en todas las webs • Necesita que la página exista • Más lenta y menos eficaz que la de servidor • Se necesita mayor conocimiento para hacer cambios en Bulk |
| JavaScript | Se ejecuta mediante window.location u otros métodos JS. | ⚠️ Poco recomendable | • Permite lógica compleja y condicional • Posibilidad de automatización avanzada | • Necesita que se pueda renderizar • Mala experiencia de usuario • No siempre detectada por herramientas SEO • No siempre se ejecuta correctamente |
| Canonical (solo para Google) | Indica cuál es la URL preferida, aunque no redirige al usuario. | ⚠️ Complementario | • Útil para consolidar señales SEO • Combinable con otros métodos | • No redirige al usuario • Solo funciona si Google lo interpreta correctamente • No garantiza indexación de la URL canónica |
| Redirección “Crypto” | Mostrar un mensaje al usuario con un enlace manual a la nueva URL (no es una redirección técnica). | ❌ No recomendable | • Último recurso si no hay control técnico • Puede informar al usuario | • No es una redirección real • No transfiere señales SEO • Depende del clic del usuario |
Redirección por medio del servidor
Se consigue modificando el encabezado HTTP, es decir la respuesta que arroja el servidor al usuario antes de mostrarle el contenido.
En este caso le dirá un código de respuesta al usuario, y las redirecciones se sitúan en la centena del 3XX.
El código de respuesta 301 y 308 indican que es una redirección permanente, mientras que el 302, 303 y 307 indicarán una redirección temporal.
Estos son los códigos de respuesta que entenderá Google y los que se deben poner en caso de redirección. Por si alguien tiene dudas, más allá de la clasificación de permanente o temporal no hay ningún código de respuesta mejor que otro y el hecho de que existan variaciones se debe a una diferenciación entre los estándares y cómo acabaron utilizando los códigos de respuesta los desarrolladores.
Las redirecciones por medio del servidor tienen varias ventajas y desventajas.
Ventajas
- Todos los motores de búsqueda y user-agents las entienden.
- Son inmediatas (no hay que cargar el contenido para poder acceder a la redirección).
- Bien implementadas son muy robustas.
- Hay muchas opciones de servidores como Apache, nginx o azure cuyos lenguajes son muy distintos unos de otros.
- Funciona para todo tipo de elementos, sean páginas HTML, vídeos, PDFs o imágenes.
- Se pueden hacer independiente de que el contenido haya dejado de existir, lo cual permite hacer una buena curación de contenido.
Desventajas
- No siempre son fáciles de implementar.
- En caso de una mala implementación, puedes romper una web entera. Por lo que siempre hay que implementarlo con conocimiento, en una web de prueba y tener copias de seguridad.
- No todos los CMS o tecnologías permiten este tipo de redirección.
Redirección por medio de metaetiquetas
Como he explicado anteriormente, hay sistemas que no permiten siempre este tipo de redirecciones.
Hay CMS muy conocidos como Shopify o builders como Wix que te impiden las implementaciones por medio de servidor, lo cual te deja en una clara desventaja y falta de flexibilidad para estas cuestiones SEO.
Para este caso, se puede combinar sus lenguajes como Liquid (en Shopify) o Velo (en WiX) para que ante ciertos condicionales se ponga una etiqueta meta refresh.
En el caso de que se quiera que el metarefresh sea permanente se debe hacer que se haga sin conteo, con 0 segundos de retraso, y en caso de que se prefiera “temporal” se recomienda poner como mínimo un segundo de retraso.
En cualquiera de los casos, Google tiene que rastrear la web y el contenido, por lo que no suele ser tan efectivo como una redirección de servidor.
De hecho la meta refresh es de la familia de las http-equiv que básicamente son metaetiquetas que emulan ser un código del encabezado HTTP y que es cierto que como estándar la mayoría de navegadores interpreta de forma correcta.
Ventajas
- Se pueden implementar en cualquier web donde puedas poner HTML en el Head.
- Si no se tiene acceso al servidor pero si a un lenguaje de servidor como PHP se puede automatizar de forma relativamente sencilla.
Desventajas
- Suele ser más difícil de implementar en masa por ejemplo con regex, especialmente si se usan lenguajes que no son realmente de servidor (como liquid).
- La página debe estar dentro de las etiquetas <head> si no está ahí no se puede implementar.
- Sólo funciona en contenido de HTML
- Puede verse enturbiado por otras metaetiquetas como la canonical.
- La página debe existir para poder poner la metaetiqueta, no hay pruebas (falta hacer el experimento) de que funcione en un 404 (aunque tenga un condicional de redirección para aparecer solo en 404 concretos).
Redirección por medio de JavaScript
A diferencia de redirectpath, herramientas como PERSEO pueden tener problemas para detectarlo.
Por medio de JavaScript se puede hacer auténtica magia, puedes modificar todo el DOM de una página web y cambiar todo el contenido a tu antojo.
Es decir podemos modificar cualquier elemento de nuestra web por medio de JavaScript y además Google lee JavaScript. ¿No sería una buena forma de redireccionar?
La realidad es que solo sería buena alternativa en el caso de que estés en la misma situación en la que necesites el metarefresh, pero necesites automatismos que no puedes conseguir por medio de otro lenguaje para dichas redirecciones o que no tengas la opción de editar o insertar código en el <head>.
De hecho por medio de JavaScript a día de hoy, Google puede leer los enlaces por medio de JavaScript cuando están con onclick, como bien apuntó Javier Morell. Una forma en la que muchos SEOs hacían ofuscación de enlaces porque Google no era capaz de procesarlo.
Dicho todo esto, sería interesante preguntarse por qué no es mejor opción que el metarefresh, y la verdad es que mantiene gran parte de sus desventajas y se le añaden otras más importantes.
Google para leer JavaScript necesita renderizar la URL para procesarlo. Para renderizar la página web, esta debe ser la canónica y además debe ser indexable. Para lo cual gracias a su forma de cachear puede hacer otro rastreo procesando el JS, siendo la renderización un paso posterior al rastreo normal.
Podríamos pensar que con JavaScript además de hacer un location, podemos poner una etiqueta metarefresh en el head y arreglado, pero lo cierto es que además del renderizado, para el usuario también debe cargar. Por lo que sí con el metarefresh normal, debe descargarse el archivo HTML y ejecutarse, con JS debe también procesarse el JS, siendo un proceso más lento que puede generar una mala experiencia en el usuario, incluso siendo posible que aparezca la URL de origen antes de que el navegador te redirija a la URL final (siendo esta de hecho una forma manual de diagnosticar una redirección con JS.
Por otro lado y para finalizar, ChatGPT no renderiza el JavaScript, por lo que habría que poner algún indicativo a “modo de promt” para que funcionase en estos casos.
Imposibilidad de redirección
En ciertas ocasiones, el sistema en el que trabajemos será tan cerrado que no tendremos opción alguna de hacer una redirección efectiva. Esto suele pasar en webs “hechas a medida” que hacen que todos sus clientes se sirvan de la misma plantilla aunque en realidad es un pseudosecuestro.
Para estos casos, estas serían las opciones posibles, a menos que podamos introducir GTM y por medio de Google Tag Manager hacer una redirección de JS.
“Redirección Crypto”
Es el nombre que le asigna Google. La realidad que sería un mensaje intrusivo avisando al usuario del cambio de web y un enlace.
No es una redirección sino simplemente un enlace visible en toda la web.
Canonical
Algo que de funcionar bien puede ser como una redirección para Google aunque no para el usuario podría ser establecer como canónica la URL final.
Esto se puede combinar con métodos anteriores y de hecho en los debuggers y previsualizaciones de redes sociales, se tiende a mostrar el contenido de la URL canónica en lugar de la compartida
Las redirecciones son un tema bastante delicado en cualquier web que hay que tratar con mucho mimo y cuidado, es por ello que quiero tratar varios aspectos.
Mantener todo el ecosistema de redirecciones en el mismo sitio
Se debe tener un estándar de empresa y una documentación de donde están esas redirecciones y cómo gestionarlas.
A medida que escala y crece un proyecto, sus redirecciones también. Y llegado a cierto punto, las redirecciones y las posibles cadenas de redirecciones pueden suponer un punto de estancamiento.
Las cadenas de redirecciones son una redirección que llevan a otra redirección. Hay que tener cuidado porque puede generar un error de “too many redirect” o que Google no lo siga.
Es por eso que lo ideal es, independientemente de cómo y dónde se hagan las redirecciones en una página, centralizarlo todo en un sitio. Si se hace en el servidor, en el .htaccess y también en un plugin, es muy fácil perder el control e incluso que esta mala práxis provoque resultados indeseados en tu web.
En resumen, da igual que lo hagas por medio del .htaccess, un plugin o laravel forge. Lo realmente importante es mantener todas las redirecciones en el mismo sitio.
Redirecciones por idioma
En la mente de muchos, redirigir al usuario dependiendo del idioma en el que entre hacia la versión idiomática correspondiente puede parecer una idea espectacular, sin embargo veamos estas citas sacadas de la documentación de Google:
Si prefieres cambiar el contenido de forma dinámica o redirigir a los usuarios en función de su configuración de idioma, ten en cuenta que es posible que no encontremos ni rastreemos todas tus variantes. El motivo es que el rastreador del robot de Google suele proceder de Estados Unidos. Además, el rastreador envía solicitudes HTTP sin definir Accept-Language en el encabezado de solicitud.
Evita redirigir automáticamente a los usuarios de una versión lingüística de un sitio a otra versión lingüística diferente. Por ejemplo, no redirijas a los usuarios en función del idioma que crees que hablan. Estas redirecciones pueden impedir que los usuarios (y los buscadores) vean todas las versiones de tu sitio.
Por lo que no, redireccionar por el tema del idioma no es una buena idea es mejor dejarle libertad al usuario, con un selector de idioma y una buena configuración de hreflangs.
Redirecciones por legislación
En ocasiones se tiende a bloquear por país redireccionando la IP cuando se trabaja una web que legalmente no puede operar en ciertos países.
En lugar de georedireccionar por país, con el posible problema de redireccionar a Googlebot o a un revisor manual, es mejor aplicar técnicas como el paywall que recomienda Google en su sección de datos estructurados.
Sin embargo lo mejor sería hacer caso al consejo de John Mueller donde indica que lo adecuado sería hacer el bloqueo necesario, pero asignando los user-agents de Google y/o su listado de IP (si se quiere hacer más seguro) como en una lista blanca (permitiéndole así acceso al contenido).
Aquí el vídeo completo de la explicación.
Cuidado con el .htaccess
Si bien hay cierto mito con respecto a que las redirecciones ralentizan la velocidad de una web, hay 2 situaciones donde sí que las redirecciones pueden jugarte una mala pasada a nivel de rendimiento.
Cadenas de redirecciones
Si un usuario tiene que pasar por varias redirecciones en una misma consulta, evidentemente el contenido le llegará más tarde de lo esperado, causando un enorme retraso en la visualización de su contenido.
Metodología para poner las redirecciones
Hay formas de poner las redirecciones mejores que otras. Y ciertos plugins pueden llegar a ralentizarlo, sea porque se valgan de un archivo php o cambios en el .htaccess.
Y es que si bien es cierto que la cantidad de redirecciones no influye, la cantidad de código que tengas en tu web sí. Es decir, muchas líneas de redirecciones en tu .htaccess pueden afectar en tu velocidad, dependiendo del servidor, a partir de unas 5.000 ~ 25.000 líneas serían las que pueden empezar ya a provocar una pérdida de rendimiento.
Para solucionar ese problema, seguro que muchas redirecciones las puedes hacer por medio de regex y si no, siempre puedes poner dichas redirecciones en el httpd.conf evitando que a cada consulta al servidor se tenga que leer dicho archivo.
Reflexiones finales
En un entorno ideal lo mejor es hacer redirecciones desde el servidor bien documentadas, claras y limpias. Es lo que Google va a entender mejor y además te evitará dolores de cabeza.
Meta refresh, JavaScript o incluso la canonical pueden ser buenos recursos de emergencia en el caso de que ese entorno no sea tan ideal.
En cualquiera de los casos hay que tener claro cuándo procede hacer una redirección y cómo estas pueden repercutir al SEO.
Recuerda centralizar todas las redirecciones y tener un control exhaustivo de lo que ocurre en tu web, como bien puedes hacer con always on audit en Site Audit de Ahrefs.
