Redirección 301 vs 302: comprender las diferencias, el impacto SEO y lograr una migración de dominio exitosa
Por CaptainDNS
Publicado el 16 de marzo de 2026
- 301 = redirección permanente, transfiere el 100 % del ranking SEO hacia el destino
- 302 = redirección temporal, Google sigue indexando la URL de origen
- Una migración de dominio requiere 301 en cada URL, no solo en la raíz
- Los códigos 307 y 308 existen para preservar el método HTTP (POST, PUT)
- CaptainDNS Redirect Hosting gestiona las 301/302 con HTTPS automático
Cambiar de nombre de dominio, fusionar dos sitios, pasar de HTTP a HTTPS: todas estas operaciones dependen de las redirecciones HTTP. Mal configuradas, provocan una pérdida del 30 al 50 % del tráfico orgánico en las semanas posteriores a la migración. Bien configuradas, transmiten la totalidad de tu autoridad SEO hacia el nuevo destino.
La pregunta "¿debo usar una 301 o una 302?" aparece constantemente en los foros SEO y en las discusiones entre desarrolladores. La respuesta depende del contexto, pero las consecuencias de una mala elección son reales: Google indexa la URL equivocada, el PageRank se diluye, los backlinks pierden su valor. Según un estudio de Moz realizado sobre 30 000 dominios, el 12 % de las migraciones de dominio utilizan redirecciones 302 en lugar de 301, causando una pérdida media de tráfico orgánico dos veces mayor que las migraciones correctamente configuradas.
Esta guía cubre los 4 códigos de redirección HTTP, explica en detalle el impacto SEO de cada uno y proporciona una checklist completa para realizar una migración de dominio exitosa. Ya sea que gestiones un sitio corporativo o un portal de 50 000 páginas, los principios son los mismos.
Última precisión: esta guía trata las redirecciones del lado del servidor (códigos de estado HTTP). Las redirecciones JavaScript o las etiquetas meta refresh no se abordan aquí porque presentan problemas fundamentales para el rastreo y la indexación. Para los casos de uso de marketing (vanity URLs, link tracking, códigos QR), hay una guía complementaria disponible en la sección "Guías relacionadas" al final del artículo.
Configura tus redirecciones ahora
Los 4 códigos de redirección HTTP
El protocolo HTTP define cuatro códigos de redirección principales. Cada uno comunica una intención diferente al navegador y a los motores de búsqueda.
301 Moved Permanently
El código 301 significa que el recurso ha sido movido de forma permanente a una nueva URL. El servidor responde con un encabezado Location que contiene el destino.
HTTP/1.1 301 Moved Permanently
Location: https://captaindns.com/es/tools
Comportamiento del navegador: el navegador almacena en caché la redirección y redirige automáticamente las futuras solicitudes hacia el destino, sin volver a pasar por el servidor de origen. Este caché persiste incluso después de cerrar el navegador.
Definido en la RFC 7231, sección 6.4.2, el código 301 permite a los clientes HTTP transformar una solicitud POST en GET durante la redirección. Este comportamiento, heredado de las primeras implementaciones HTTP, es la razón por la que se creó el código 308.
302 Found
El código 302 significa que el recurso está temporalmente disponible en otra URL. El servidor responde de la misma forma:
HTTP/1.1 302 Found
Location: https://captaindns.com/es/maintenance
Comportamiento del navegador: el navegador no almacena en caché la redirección. Cada solicitud vuelve a pasar por el servidor de origen, que puede devolver un destino diferente o dejar de redirigir.
Definido en la RFC 7231, sección 6.4.3, el código 302 tiene una historia complicada. En HTTP/1.0, significaba "Moved Temporarily". Los navegadores transformaban históricamente las solicitudes POST en GET durante una 302, lo que no correspondía con la especificación. El código 303 (See Other) fue creado para formalizar este comportamiento, y el código 307 para preservar el método HTTP.
307 Temporary Redirect
El código 307 es el equivalente estricto de la 302, pero con una garantía: el método HTTP se preserva. Si el cliente envía un POST, la redirección reenvía un POST hacia el destino.
HTTP/1.1 307 Temporary Redirect
Location: https://captaindns.com/api/v2/submit
Este código está definido en la RFC 7231, sección 6.4.7. Se utiliza principalmente para formularios y API REST donde la preservación del método es crítica. Para las redirecciones de páginas web clásicas (GET), la diferencia entre 302 y 307 es nula.
308 Permanent Redirect
El código 308 es el equivalente estricto de la 301, pero con la misma garantía que el 307: el método HTTP se preserva.
HTTP/1.1 308 Permanent Redirect
Location: https://captaindns.com/api/v2/submit
Definido en la RFC 7238, el código 308 es la elección correcta para las redirecciones permanentes de API donde el método HTTP debe conservarse. Para las redirecciones de páginas web (GET), 301 y 308 son funcionalmente idénticos.
Tabla comparativa de los 4 códigos
| Código | Tipo | ¿Método HTTP preservado? | ¿Caché del navegador? | ¿Transferencia SEO? |
|---|---|---|---|---|
| 301 | Permanente | No (POST puede convertirse en GET) | Sí | Sí (100 %) |
| 302 | Temporal | No (POST puede convertirse en GET) | No | Parcial (Google indexa el origen) |
| 307 | Temporal | Sí | No | Parcial (mismo comportamiento que 302) |
| 308 | Permanente | Sí | Sí | Sí (mismo comportamiento que 301) |
En la práctica, para las redirecciones de páginas web (solicitudes GET), solo los códigos 301 y 302 son relevantes. Los códigos 307 y 308 están reservados para contextos técnicos donde la preservación del método HTTP es necesaria.
Redirecciones del lado del servidor vs JavaScript
Los códigos 301, 302, 307 y 308 son redirecciones del lado del servidor: el servidor envía un encabezado HTTP Location y el navegador lo sigue inmediatamente. Pero también existen redirecciones del lado del cliente, implementadas en JavaScript o mediante una etiqueta meta refresh.
Redirecciones del lado del servidor (HTTP): Google las detecta y las sigue inmediatamente durante el rastreo. La transferencia de señales SEO es fiable y rápida. Es el método recomendado por Google Search Central para cualquier cambio de URL.
Redirecciones JavaScript (window.location, window.location.replace): Google debe primero descargar la página HTML, ejecutar el JavaScript en su motor de renderizado (basado en Chromium) y luego descubrir la redirección. Este proceso añade un retraso significativo. Google clasifica este método como último recurso, a utilizar solo cuando la redirección del lado del servidor es imposible.
Redirecciones meta refresh (<meta http-equiv="refresh" content="0;url=...">): Google puede seguirlas, pero las desaconseja formalmente. El comportamiento es similar a una redirección JavaScript: la página debe descargarse y analizarse antes de que se detecte la redirección.
| Método | Detección por Google | Transferencia SEO | Caso de uso |
|---|---|---|---|
| Del lado del servidor (301/302) | Inmediata | Completa (301) o parcial (302) | Migraciones, cambios de URL |
| JavaScript | Después del renderizado | Incierta, a menudo parcial | SPA (Single Page Applications) |
| Meta refresh | Después de la descarga | Desaconsejada por Google | Ningún caso recomendado |
El riesgo principal de las redirecciones JavaScript: si el renderizado de la página falla (error JS, timeout, recurso bloqueado), Google simplemente no ve la redirección. La página de origen sigue indexada, el destino es ignorado. Para las Single Page Applications (SPA) donde la redirección del lado del servidor es técnicamente imposible, JavaScript es el único recurso, pero entonces hay que verificar regularmente que Googlebot detecta correctamente la redirección (mediante la herramienta de inspección de URL en Search Console).
¿Cómo tratan los navegadores las redirecciones?
Cuando un navegador recibe un código de redirección, realiza automáticamente una nueva solicitud hacia la URL indicada en el encabezado Location. Este proceso es transparente para el usuario: solo percibe un ligero retraso de carga.
Para las redirecciones 301, el navegador almacena la correspondencia en un caché local. Las visitas siguientes a la antigua URL se redirigen directamente por el navegador, sin contactar el servidor de origen. Este caché es persistente: sobrevive al cierre del navegador y solo se vacía mediante un borrado manual del caché o la expiración definida por los encabezados Cache-Control.
Para las redirecciones 302, el navegador no almacena en caché la correspondencia. Cada visita a la antigua URL desencadena una solicitud al servidor de origen, que puede responder de forma diferente cada vez. Este comportamiento es lo que hace que la 302 sea adecuada para redirecciones dinámicas (geolocalización, pruebas A/B, campañas temporales).
Esta diferencia de caché tiene un impacto directo en el rendimiento. Una 301 ahorra una solicitud de red en cada visita posterior. Una 302 añade sistemáticamente la latencia de un viaje de ida y vuelta HTTP adicional.
Otros códigos de estado HTTP que debes conocer
Tres códigos HTTP se confunden a veces con las redirecciones:
- 200 OK: la página existe y devuelve contenido. No hay redirección. Si la página muestra "Vas a ser redirigido...", se trata de una redirección del lado del cliente (JavaScript o meta refresh), no de una redirección HTTP.
- 404 Not Found: la página no existe. Si eliminas una página sin configurar una redirección, los visitantes y Googlebot reciben un 404. Los backlinks hacia esa página pierden todo su valor.
- 410 Gone: la página ha sido eliminada definitivamente y no será reemplazada. Google trata el 410 como una señal fuerte para retirar la página del índice. Usa el 410 cuando no haya una página de destino pertinente para una redirección.
301 vs 302: impacto SEO detallado
Esta es la sección más importante de esta guía. La diferencia técnica entre 301 y 302 parece menor (permanente vs temporal), pero las consecuencias SEO son significativas. Comprender estas diferencias es esencial antes de configurar cualquier redirección.
Transferencia de PageRank y autoridad
El PageRank es la puntuación de autoridad que Google asigna a cada página en función de los enlaces entrantes. Cuando un sitio A enlaza tu página, le transmite una fracción de su propio PageRank.
Con una 301: Google transfiere el 100 % del PageRank de la antigua URL hacia la nueva. No siempre fue así. Antes de 2016, Google aplicaba una penalización del 15 % sobre el PageRank transmitido mediante una 301. Desde una actualización confirmada por Gary Illyes del equipo Google Search, esta penalización fue eliminada. Una 301 transfiere ahora la totalidad de la autoridad.
Con una 302: Google no transfiere el PageRank hacia el destino. La lógica es simple: si la redirección es temporal, se supone que la URL de origen volverá. Google conserva por tanto la autoridad en la URL de origen. El problema surge cuando una 302 permanece activa durante meses o años. Google termina por tratarla como una 301 de facto, pero el plazo es impredecible y el período de transición causa una pérdida de posicionamiento.
Indexación y canonicalización
La elección 301 vs 302 determina qué URL muestra Google en sus resultados:
Con una 301: Google elimina la antigua URL de su índice e indexa el destino. Los resultados de búsqueda muestran la nueva URL. Este proceso tarda generalmente de algunos días a algunas semanas según la frecuencia de rastreo.
Con una 302: Google sigue indexando la URL de origen y la muestra en sus resultados. El destino es conocido por Google, pero no se considera como la versión canónica. Resultado: tus visitantes ven la antigua URL en Google, hacen clic, son redirigidos a la nueva página, pero las señales SEO (backlinks, antigüedad, autoridad) permanecen asociadas a la antigua URL.
Caché del navegador y conteo de visitas
La 301 se almacena en caché por el navegador. Después de la primera visita, el navegador redirige directamente al destino sin contactar el servidor de origen. Consecuencia: no puedes rastrear el número de redirecciones, ya que las visitas siguientes ya no pasan por tu servidor.
La 302 no se almacena en caché. Cada visita pasa por el servidor de origen, que puede contar las solicitudes, registrar la información del visitante e incluso cambiar el destino sobre la marcha. Por eso las vanity URLs y los enlaces de tracking usan 302.
Cadenas de redirección: la pérdida silenciosa
Una cadena de redirección se produce cuando una URL redirige hacia una segunda URL, que a su vez redirige hacia una tercera, y así sucesivamente. Cada salto en la cadena consume una solicitud de rastreo y añade latencia.
Google sigue las cadenas de redirección, pero con límites. John Mueller confirmó que Googlebot sigue generalmente 5 redirecciones antes de abandonar. Más allá de eso, la página final no se rastrea ni se indexa.
Incluso por debajo de 5 saltos, cada redirección intermedia diluye potencialmente la señal SEO. La recomendación es limitar cualquier cadena a 2 saltos como máximo: el origen redirige hacia el destino final, punto.
Puedes verificar la presencia de cadenas de redirección en tus páginas con el Page Crawl Checker.
Mitos vs realidad
Mito: la 302 penaliza el SEO. Realidad: la 302 no penaliza directamente el SEO. Simplemente no está diseñada para transferir la autoridad. Google no aplica sanción, pero indexa la URL equivocada y conserva la autoridad en el lugar incorrecto. El resultado se parece a una penalización, pero es un problema de configuración.
Mito: una 301 hace perder PageRank. Realidad: desde 2016, una 301 transfiere el 100 % del PageRank. Esta información ha sido confirmada por Google en múltiples ocasiones. La antigua penalización del 15 % ya no existe.
Mito: Google trata las 302 de larga duración como 301. Realidad: es parcialmente cierto. Google puede, tras un largo período, decidir tratar una 302 como una 301. Pero el plazo es impredecible (semanas, meses) y durante la transición, tu SEO se resiente. No cuentes con este comportamiento. Usa el código correcto desde el principio.
Mito: las redirecciones del lado del cliente (JavaScript, meta refresh) son equivalentes. Realidad: no. Google puede seguir las redirecciones JavaScript, pero con un retraso adicional (el renderizado de la página debe efectuarse por el motor de renderizado). Las meta refresh están desaconsejadas por Google. Solo las redirecciones del lado del servidor (301, 302, 307, 308) se procesan de forma inmediata y fiable.
Mito: las 301 son instantáneas para el SEO. Realidad: no. Después de configurar una 301, Google debe volver a rastrear la antigua URL, descubrir la redirección y luego actualizar su índice. Este proceso tarda de algunos días a varias semanas según la frecuencia de rastreo de tu sitio. Las páginas con mucho tráfico y muchos backlinks se rastrean más rápidamente que las páginas profundas con pocas visitas.
HTTPS y redirecciones: un requisito indispensable
El servidor que aloja las redirecciones debe soportar HTTPS obligatoriamente. Si un backlink apunta a https://antiguo.captaindns.com/page y el servidor de redirección solo soporta HTTP, el navegador mostrará un error de certificado en lugar de la redirección.
Con CaptainDNS Redirect Hosting, el certificado TLS se genera y se renueva automáticamente mediante Let's Encrypt. No se necesita configuración manual. El servidor de redirección responde en HTTPS en todos los dominios configurados.
Para las configuraciones manuales en tu propio servidor (Nginx, Apache, Caddy), asegúrate de que:
- El certificado TLS cubra todos los dominios de origen (antiguo dominio, variantes www, subdominios).
- La renovación del certificado esté automatizada (Let's Encrypt con certbot o acme.sh).
- Las redirecciones HTTP hacia HTTPS estén configuradas además de las redirecciones de dominio.
¿301, canonical o ambos? Elegir el enfoque correcto
Las redirecciones 301 y las etiquetas rel=canonical son dos herramientas que sirven un objetivo similar: indicar a Google cuál URL es la versión preferida. Pero funcionan de forma muy diferente y no se utilizan en las mismas situaciones.
¿Cuándo usar una 301 en lugar de un canonical tag?
La distinción es simple: la 301 redirige físicamente al visitante, el canonical no.
Una redirección 301 suprime el acceso a la URL de origen. El visitante que escribe la antigua URL es enviado automáticamente al destino. La antigua página ya no es accesible. Es la elección correcta cuando la URL de origen ya no tiene razón de existir.
Un canonical tag (rel=canonical) deja ambas URLs accesibles. El visitante puede seguir accediendo a la URL de origen y ver su contenido. El canonical es una indicación a Google: entre estas dos páginas con contenido idéntico o similar, esta es la que debes indexar. Google puede seguir esta indicación o ignorarla.
| Criterio | Redirección 301 | Canonical tag |
|---|---|---|
| ¿El visitante es redirigido? | Sí | No, ambas páginas son accesibles |
| Señal para Google | Directiva fuerte (obligatoria) | Indicación (sugerencia, puede ser ignorada) |
| ¿Ambas URLs existen? | No, solo el destino es accesible | Sí, ambas permanecen en línea |
| Transferencia de PageRank | 100 % hacia el destino | Google consolida las señales en la URL canónica |
| Caso de uso principal | URL eliminada, migración, cambio definitivo | Contenido duplicado, parámetros de URL, versiones paginadas |
En resumen: si la antigua URL ya no sirve, usa una 301. Si la antigua URL tiene una razón de existir (versión para imprimir, página con parámetros de ordenación, variante regional), usa un canonical.
Combinar 301 y canonical
Después de una migración de dominio, Google recomienda usar ambas señales juntas cuando sea posible. La 301 redirige físicamente a los visitantes y a los bots. El canonical tag en la página de destino refuerza la señal confirmando que esta URL es la versión preferida.
Concretamente, después de configurar tus redirecciones 301 desde el antiguo dominio hacia el nuevo, añade en cada página de destino un canonical tag que apunte a sí misma:
<link rel="canonical" href="https://captaindns.com/es/tools" />
Esta doble señal es particularmente útil cuando tu contenido es accesible mediante múltiples rutas (antiguo dominio redirigido, variante www, versión HTTP). Google recibe un mensaje coherente de todas las fuentes: el destino es efectivamente la URL canónica.
La combinación 301 + canonical no es obligatoria, pero acelera la convergencia en el índice de Google y reduce el riesgo de que Google elija la URL equivocada como versión canónica durante el período de transición.
¿Cuándo usar una 301?
La 301 es la elección por defecto para toda redirección definitiva. Estos son los casos de uso más frecuentes.
Migración de dominio definitiva
Cambias de nombre de dominio. El antiguo dominio ya no se usará para contenido. Cada URL del antiguo dominio debe redirigirse en 301 hacia su equivalente en el nuevo dominio.
antiguo-sitio.captaindns.com/blog/article-1
→ 301 → captaindns.com/es/blog/article-1
Consolidación de varios dominios
Posees varios dominios (variantes ortográficas, extensiones de país, dominios de marketing) y deseas concentrar la autoridad SEO en uno solo.
captaindns.fr → 301 → captaindns.com
captaindns.de → 301 → captaindns.com
Cambio de URL permanente
Rediseño del sitio, cambio de CMS, nueva arquitectura de URLs. Las antiguas URLs ya no existen y no volverán.
captaindns.com/products/dns-check
→ 301 → captaindns.com/es/tools/dns/test-propagation
Paso de HTTP a HTTPS
El paso de HTTP a HTTPS es permanente. Todas las URLs HTTP deben redirigirse en 301 hacia su equivalente HTTPS.
http://captaindns.com/es/tools
→ 301 → https://captaindns.com/es/tools
Naked domain hacia www (o viceversa)
Eliges una versión canónica de tu dominio. La otra versión redirige en 301.
www.captaindns.com → 301 → captaindns.com
o viceversa:
captaindns.com → 301 → www.captaindns.com
Tabla recapitulativa: casos de uso 301
| Situación | Ejemplo | ¿Por qué 301? |
|---|---|---|
| Migración de dominio | antiguo.captaindns.com hacia captaindns.com | El dominio de origen ya no servirá contenido |
| Consolidación multi-dominio | captaindns.fr hacia captaindns.com | Concentrar la autoridad SEO en un único dominio |
| Cambio de URL (rediseño) | /products/ hacia /es/tools/ | La antigua estructura de URL se abandona |
| HTTP hacia HTTPS | http:// hacia https:// | El paso a HTTPS es definitivo |
| www vs sin www | www.captaindns.com hacia captaindns.com | Una sola versión canónica del dominio |
¿Cuándo usar una 302?
La 302 es la elección correcta cuando la redirección es temporal: prevés restablecer la URL de origen a su estado original.
Campañas de marketing temporales
Creas una vanity URL para una campaña limitada en el tiempo. La redirección se desactivará al final de la campaña.
promo.captaindns.com → 302 → captaindns.com/es/pricing
(durante la campaña de marzo 2026)
Pruebas A/B
Rediriges una fracción del tráfico hacia una variante de página para probar un nuevo diseño o nuevo contenido. La redirección se retirará una vez terminada la prueba.
Mantenimiento planificado
Tu sitio está en mantenimiento. Rediriges temporalmente el tráfico hacia una página de información. El sitio volverá a su estado normal después del mantenimiento.
captaindns.com/es/tools → 302 → captaindns.com/es/maintenance
Geolocalización y detección de idioma
Rediriges a los visitantes hacia una versión localizada de tu sitio en función de su dirección IP o del idioma de su navegador. La redirección es condicional y no debe almacenarse en caché, ya que un mismo usuario podría visitar desde otro país.
captaindns.com → 302 → captaindns.com/es/ (visitante español)
captaindns.com → 302 → captaindns.com/en/ (visitante inglés)
Redirecciones condicionales (móvil/escritorio)
Rediriges a los visitantes móviles hacia una versión dedicada. Esta práctica es cada vez menos común (el diseño responsive la ha reemplazado en gran medida), pero todavía existe en algunos sitios.
Tabla recapitulativa: casos de uso 302
| Situación | Ejemplo | ¿Por qué 302? |
|---|---|---|
| Campaña de marketing | promo.captaindns.com hacia landing page | Redirección temporal, será desactivada |
| Prueba A/B | 50 % del tráfico hacia variante B | Prueba limitada en el tiempo |
| Mantenimiento | Sitio hacia página de mantenimiento | El sitio volverá |
| Geolocalización | Raíz hacia versión local | Condicional, no debe almacenarse en caché |
| Redirección móvil | Sitio hacia versión móvil | Condicional según el dispositivo |
Migración de dominio: la checklist completa
La migración de dominio es la operación más arriesgada en SEO. Esta es la checklist completa para minimizar las pérdidas.
Antes de la migración: auditoría e inventario
1. Listar todas las URLs indexadas
Exporta la lista completa de URLs indexadas desde Google Search Console (informe "Páginas"). Complementa con un rastreo completo de tu sitio (Screaming Frog, Sitebulb o cualquier otro crawler).
El objetivo: tener un inventario exhaustivo de cada URL que recibe tráfico o backlinks.
2. Identificar las páginas de alto valor
Clasifica tus URLs por tráfico orgánico (Google Analytics) y por número de backlinks (Ahrefs, Moz, Semrush). El 20 % de páginas que generan el 80 % del tráfico son tu prioridad absoluta. Cualquier error de redirección en estas páginas tendrá un impacto inmediato y visible.
3. Crear el plan de redirección 1:1
Cada URL del antiguo dominio debe corresponder a una URL en el nuevo dominio. Sin redirección genérica hacia la homepage. Una tabla simple es suficiente:
| URL de origen | URL de destino | Estado |
|---|---|---|
| antiguo.captaindns.com/ | captaindns.com/es/ | Por configurar |
| antiguo.captaindns.com/blog/article-1 | captaindns.com/es/blog/article-1 | Por configurar |
| antiguo.captaindns.com/contact | captaindns.com/es/contact | Por configurar |
Si algunas páginas no tienen equivalente en el nuevo dominio, redirígelas hacia la página más pertinente (no la homepage por defecto).
4. Verificar el contenido del nuevo dominio
Antes de activar las redirecciones, asegúrate de que cada página de destino existe y funciona. Una redirección 301 hacia una página 404 es peor que no tener redirección: Google ve una página de error y desclasifica la URL.
5. Respaldar los datos existentes
Antes de cualquier modificación, exporta una copia completa:
- Export CSV de todas las URLs indexadas desde Search Console
- Export de las posiciones de búsqueda (Semrush, Ahrefs u otra herramienta de seguimiento)
- Export de los backlinks del antiguo dominio
- Captura de pantalla de las estadísticas de tráfico orgánico de los últimos 90 días
Estos datos servirán como referencia para medir el impacto de la migración y detectar anomalías después del cambio.
Configurar las redirecciones 301
6. Implementar las redirecciones en cada URL
La regla fundamental: cada URL debe redirigirse individualmente. Redirigir únicamente la raíz (antiguo.captaindns.com hacia captaindns.com) no es suficiente. Las páginas profundas, los artículos del blog, las fichas de producto deben tener cada una su propia redirección.
Si tu nuevo sitio conserva la misma estructura de URL, puedes usar una regla de path forwarding. La ruta de la antigua URL se añade automáticamente al destino:
antiguo.captaindns.com/* → 301 → captaindns.com/*
Con CaptainDNS Redirect Hosting, activa la opción "Path forwarding" para transmitir automáticamente la ruta de la URL de origen hacia el destino.
7. Gestionar las 4 variantes de cada URL
Cada URL existe potencialmente en 4 versiones:
http://antiguo.captaindns.com/pagehttps://antiguo.captaindns.com/pagehttp://www.antiguo.captaindns.com/pagehttps://www.antiguo.captaindns.com/page
Las 4 versiones deben llegar al mismo destino. Olvidar una variante significa dejar backlinks sin redirección.
Verificar el DNS
8. Configurar los registros DNS
Para que las redirecciones funcionen, el dominio de origen debe resolver hacia el servidor de redirección. Si usas CaptainDNS Redirect Hosting, crea un registro CNAME o A/AAAA apuntando al servicio de redirección.
9. Verificar la propagación DNS
Después de modificar los registros DNS, verifica que la propagación sea efectiva en todas las regiones con el test de propagación DNS. La propagación completa puede tardar de algunos minutos a 48 horas según el TTL anterior.
Google Search Console: herramienta Change of Address
10. Declarar el cambio en Google Search Console
Google proporciona una herramienta dedicada en Search Console: "Change of Address" (Configuración > Cambio de dirección). Esta herramienta:
- Verifica que las redirecciones 301 están correctamente configuradas
- Acelera la actualización del índice de Google
- Transfiere las señales del antiguo dominio al nuevo
Prerrequisito: ambos dominios (antiguo y nuevo) deben estar verificados en Google Search Console.
11. Enviar el nuevo sitemap
Envía el sitemap XML del nuevo dominio en Google Search Console. Verifica que todas las URLs del sitemap devuelven un código 200. Elimina el sitemap del antiguo dominio una vez que la migración haya terminado y el índice esté actualizado.
Monitorización post-migración
12. Supervisar el tráfico orgánico (30/60/90 días)
Una bajada temporal del tráfico orgánico (10 a 20 %) es normal en las 2 a 4 semanas posteriores a una migración. Más allá de eso, hay un problema. Supervisa:
- Semana 1-2: Google comienza a rastrear el nuevo dominio. El tráfico puede bajar del 10 al 30 %.
- Semana 3-4: el tráfico debería estabilizarse y comenzar a subir.
- Mes 2-3: el tráfico debería recuperar su nivel pre-migración, incluso superarlo si el nuevo sitio es de mejor calidad.
13. Verificar los errores en Search Console
Consulta el informe "Páginas" en Google Search Console para identificar errores 404, errores de redirección y problemas de indexación. Corrige inmediatamente las URLs que devuelven errores.
14. Monitorizar los backlinks
Verifica que los backlinks del antiguo dominio se redirigen correctamente al nuevo. Usa Ahrefs o una herramienta similar para identificar los backlinks que devuelven un error 404 en lugar de una redirección 301.
15. Verificar las posiciones de búsqueda
Sigue tus palabras clave estratégicas en una herramienta de seguimiento de posiciones (Semrush, Ahrefs, Sistrix). Compara las posiciones antes y después de la migración. Una palabra clave que cae más de 10 posiciones después de 4 semanas indica probablemente un error de redirección en la página correspondiente.
Crea una tabla de seguimiento con tus 50 palabras clave más importantes:
| Palabra clave | Posición antes | Posición D+7 | Posición D+30 | Posición D+90 |
|---|---|---|---|---|
| redirección dns | 5 | 8 | 6 | 4 |
| test propagación dns | 3 | 7 | 4 | 3 |
| verificación email spf | 12 | 18 | 14 | 11 |
Una subida progresiva es señal de que la migración se desarrolla correctamente. Un estancamiento en D+30 requiere investigación (redirecciones faltantes, contenido modificado, problemas técnicos).
Duración de mantenimiento de las redirecciones
16. ¿Cuánto tiempo mantener las redirecciones?
Google recomienda mantener las redirecciones 301 de forma permanente si es posible. En la práctica:
- Mínimo 6 meses: por debajo, Google no ha tenido tiempo de volver a rastrear todas tus páginas y actualizar su índice.
- Recomendado 1 año: la gran mayoría de las señales SEO habrán sido transferidas.
- Ideal: permanente: mientras el antiguo dominio esté activo, las redirecciones deben funcionar. Los backlinks en sitios de terceros seguirán apuntando al antiguo dominio durante años.
Si dejas expirar el antiguo dominio, las redirecciones obviamente dejan de funcionar. Los backlinks que apuntaban al antiguo dominio devolverán un error DNS. Por eso se recomienda conservar el antiguo dominio y renovar su registro el mayor tiempo posible.
Un riesgo adicional existe: si tu antiguo dominio expira y un tercero lo compra, puede recuperar los backlinks que aún apuntaban al antiguo dominio. En el mejor de los casos, muestra contenido sin relación. En el peor, explota la reputación de tus antiguos backlinks para alojar contenido malicioso o spam. Renueva el registro de tu antiguo dominio durante al menos 3 años después de la migración.
Planificación semana a semana
Una migración de dominio se prepara con varias semanas de anticipación. Este es un calendario tipo para estructurar las etapas y evitar olvidos.
| Semana | Acción | Verificación |
|---|---|---|
| S-4 | Auditoría completa de URLs, inventario de backlinks | Lista exhaustiva exportada |
| S-3 | Configurar las redirecciones 301 en el servidor | Probar cada redirección con curl |
| S-2 | Declarar el nuevo dominio en Search Console | Verificación de propiedad validada |
| S-1 | Últimas pruebas, backup del sitemap del antiguo dominio | Todas las redirecciones funcionan |
| D-0 | Activar las redirecciones, enviar el Change of Address | Verificar las primeras horas en tiempo real |
| S+1 | Monitorizar la indexación y el tráfico diariamente | Search Console y Analytics consultados cada día |
| S+4 | Primer balance a 30 días | Comparación de tráfico antes y después de la migración |
| S+8 | Segundo balance a 60 días | Estabilización esperada del tráfico orgánico |
| S+12 | Balance final a 90 días | Decisión: conservar o ajustar las redirecciones |
Este calendario es indicativo. Para los sitios voluminosos (varios miles de páginas), prevé una semana adicional para la auditoría y el mapeo de URLs.
Caso real: migración HTTP a HTTPS
El paso de HTTP a HTTPS es la migración más frecuente. Google considera HTTP y HTTPS como dos sitios distintos. Cada URL HTTP debe redirigirse en 301 hacia su equivalente HTTPS.
El proceso es idéntico a un cambio de dominio clásico:
- Obtener un certificado TLS para tu dominio (Let's Encrypt, o cualquier otro proveedor)
- Configurar el servidor para responder en HTTPS
- Redirigir cada URL HTTP en 301 hacia HTTPS (no solo la homepage)
- Actualizar los enlaces internos para apuntar a las URLs HTTPS
- Declarar la versión HTTPS en Google Search Console
- Enviar el sitemap con las URLs HTTPS
Error común: redirigir solo la homepage HTTP hacia HTTPS y olvidar las páginas internas. Resultado: las páginas profundas siguen accesibles en HTTP, Google las considera como duplicados, y la autoridad SEO se fragmenta entre las dos versiones.
Punto importante: Google Search Console trata HTTP y HTTPS como propiedades distintas. Debes enviar ambas versiones (propiedad HTTP y propiedad HTTPS) para tener una vista completa de la indexación durante la transición. Usa la herramienta Change of Address para acelerar el proceso.
Impacto en el crawl budget y los Core Web Vitals
Las redirecciones no solo afectan la indexación y la transferencia de autoridad. También tienen un impacto medible en dos aspectos técnicos del SEO: el presupuesto de rastreo y el rendimiento de carga.
Crawl budget y redirecciones
Googlebot dispone de un presupuesto de rastreo limitado para cada sitio: un número de páginas que puede explorar en un intervalo de tiempo dado. Este presupuesto depende del tamaño del sitio, de su popularidad y de la capacidad del servidor para responder rápidamente.
Cada redirección consume una unidad de este presupuesto. Cuando Googlebot encuentra una 301, cuenta una solicitud para la URL de origen (que devuelve la redirección) y luego una segunda solicitud para el destino. Una cadena de 3 redirecciones consume por tanto 4 solicitudes para una sola página de contenido.
Para los sitios pequeños (unos cientos de páginas), el impacto es insignificante. Para los sitios voluminosos con miles de redirecciones activas, el consumo de presupuesto de rastreo puede volverse significativo. Googlebot dedica tiempo a seguir redirecciones en lugar de rastrear contenido nuevo.
Recomendaciones:
- Minimiza el número de redirecciones en las páginas de alto tráfico y alto valor SEO
- Elimina las cadenas de redirecciones apuntando directamente al destino final
- Después de una migración, una vez actualizado el índice (6 a 12 meses), las redirecciones consumen menos presupuesto de rastreo ya que Googlebot aprende progresivamente las nuevas URLs
Impacto en los Core Web Vitals
Los Core Web Vitals son las métricas de rendimiento de usuario medidas por Google: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) y CLS (Cumulative Layout Shift). Estas métricas influyen en el posicionamiento desde 2021.
Cada redirección añade un viaje de ida y vuelta en la red (RTT) entre el navegador y el servidor. En la práctica, esto representa de 100 a 300 ms adicionales por salto, según la latencia de red y la ubicación geográfica del visitante.
Impacto por métrica:
- LCP: directamente afectado. El tiempo de carga del contenido principal aumenta de 100 a 300 ms por redirección. En móvil con una conexión lenta, el impacto puede superar los 500 ms por salto.
- CLS: ningún impacto. Las redirecciones ocurren antes de la visualización de la página, no causan desplazamientos visuales.
- INP: ningún impacto. Las redirecciones no afectan la reactividad de la página una vez cargada.
Buena noticia: las redirecciones 301 almacenadas en caché por el navegador no tienen ningún impacto en los Core Web Vitals después de la primera visita. El navegador redirige localmente, sin viaje de ida y vuelta en la red. Es un argumento adicional a favor de las 301 frente a las 302 para las redirecciones permanentes.
Para medir el impacto real de las redirecciones en tus Core Web Vitals, usa Chrome DevTools (pestaña Performance) o los datos de campo en Google Search Console (informe Core Web Vitals).
Errores comunes que destruyen el SEO
Usar 302 en lugar de 301 para una migración
Es el error más frecuente. Un desarrollador configura redirecciones 302 "temporales" para una migración definitiva. Resultado: Google sigue indexando el antiguo dominio, el PageRank no se transfiere y el nuevo dominio parte de cero en términos de autoridad.
La corrección es simple: cambia todas las redirecciones 302 a 301. El efecto no es inmediato (Google debe volver a rastrear las URLs), pero la transferencia de autoridad terminará por efectuarse.
Redirigir todas las URLs hacia la homepage
Rediriges antiguo.captaindns.com/blog/article-1, antiguo.captaindns.com/blog/article-2 y antiguo.captaindns.com/contact hacia captaindns.com. Google considera estas redirecciones como soft 404: el contenido de la página de destino no corresponde con lo que la antigua URL prometía.
Resultado: Google ignora estas redirecciones y desclasifica las URLs. Los backlinks que apuntaban a tus artículos del blog pierden su valor, ya que redirigen a una página sin relación.
La solución: una redirección 1:1. Cada antigua URL redirige hacia la página equivalente en el nuevo dominio. Si una página no tiene equivalente exacto, redirígela hacia la página temáticamente más cercana. Por ejemplo, un artículo de blog eliminado puede redirigirse hacia un artículo relacionado que trate el mismo tema, o hacia la página de categoría correspondiente.
Cadenas de redirecciones
Situación típica: durante una primera migración, site-v1.captaindns.com fue redirigido hacia site-v2.captaindns.com. Durante una segunda migración, site-v2.captaindns.com fue redirigido hacia captaindns.com. Resultado: una cadena de 3 saltos.
site-v1.captaindns.com → 301 → site-v2.captaindns.com → 301 → captaindns.com
Cada salto añade latencia y consume una solicitud de rastreo. Más allá de 5 saltos, Googlebot abandona. Incluso con 3 saltos, la señal SEO se diluye.
Corrige actualizando las antiguas redirecciones para apuntar directamente al destino final:
site-v1.captaindns.com → 301 → captaindns.com
site-v2.captaindns.com → 301 → captaindns.com
Bucles de redirección
Un bucle de redirección se produce cuando la URL A redirige hacia la URL B, que redirige hacia la URL A. El navegador muestra el error ERR_TOO_MANY_REDIRECTS. El crawler de Google abandona inmediatamente.
Los bucles suelen estar causados por conflictos entre reglas de redirección. Ejemplos clásicos:
- El servidor redirige
httphaciahttps, y un plugin redirigehttpshaciahttp. - El servidor redirige
wwwhaciasin www, y el CDN redirigesin wwwhaciawww. - Dos reglas de redirección se solapan en el archivo
.htaccesso en la configuración de Nginx.
La solución: prueba cada URL en un navegador en modo incognito y verifica los encabezados de respuesta con curl -I o el Page Crawl Checker.
Olvidar las variantes www, sin www, HTTP, HTTPS
Un sitio accesible mediante 4 URLs diferentes (http://, https://, http://www., https://www.) debe redirigir las 3 variantes no canónicas hacia la versión elegida.
Olvidar una variante significa que los backlinks que apuntan a esa versión no se redirigen. Devuelven un error o una página no canónica que Google puede indexar como duplicado.
Verifica sistemáticamente las 4 combinaciones para cada dominio implicado en la migración.
Este es un ejemplo concreto de prueba para un dominio:
curl -I http://captaindns.com/es/tools → debe devolver 301 hacia https://captaindns.com/es/tools
curl -I http://www.captaindns.com/es/tools → debe devolver 301 hacia https://captaindns.com/es/tools
curl -I https://www.captaindns.com/es/tools → debe devolver 301 hacia https://captaindns.com/es/tools
curl -I https://captaindns.com/es/tools → debe devolver 200 (URL canónica)
Eliminar las redirecciones demasiado pronto
Algunos equipos eliminan las redirecciones 301 después de unas semanas, pensando que Google ha tenido tiempo de actualizar su índice. En realidad, Google no vuelve a rastrear todas las páginas al mismo ritmo. Las páginas profundas con pocos backlinks pueden no ser rastreadas de nuevo antes de varios meses.
Además, los backlinks en sitios de terceros están fuera de tu control. Un artículo de blog publicado en 2020 que enlaza tu antiguo dominio seguirá generando clics durante años. Si la redirección se elimina, esos visitantes llegan a un error 404 o, peor aún, a un dominio comprado por un tercero.
No monitorizar después de la migración
La migración está en marcha, las redirecciones funcionan, el sitemap está enviado. ¿Trabajo terminado? No. Sin monitorización, no detectarás los problemas que aparecen en las semanas siguientes:
- Páginas 404 en el nuevo dominio (contenido eliminado o URL mal configurada)
- Redirecciones rotas (certificado expirado, servidor de redirección caído)
- Indexación bloqueada (robots.txt demasiado restrictivo en el nuevo dominio)
- Bajada anormal del tráfico en ciertas secciones del sitio
Consulta Google Search Console cada semana durante los 3 primeros meses. Configura alertas sobre bajadas de tráfico significativas en Google Analytics.
Ignorar los emails y newsletters que contienen enlaces al antiguo dominio
Tus emails de marketing, tus newsletters archivadas y tus documentos PDF contienen enlaces al antiguo dominio. Estos enlaces seguirán siendo clicados durante meses, incluso años. Si las redirecciones no están implementadas, tus suscriptores llegan a errores.
Haz un inventario de todos los canales que difunden enlaces hacia tu dominio: firmas de email, plantillas de newsletters, folletos PDF, presentaciones PowerPoint, perfiles de redes sociales. Actualiza los enlaces cuando sea posible, pero cuenta con las redirecciones para todo lo que no puedas modificar (emails ya enviados, PDF ya descargados).
No olvides los enlaces en aplicaciones móviles, integraciones con socios y widgets incrustados en sitios de terceros. Estas fuentes suelen ser invisibles en las auditorías de backlinks pero generan un tráfico significativo.
Usar redirecciones JavaScript en lugar de redirecciones del servidor
Algunos equipos implementan redirecciones mediante meta refresh o window.location en lugar de configurar redirecciones del lado del servidor. Esta elección es problemática para el SEO.
Las redirecciones JavaScript requieren que el motor de búsqueda descargue la página HTML, ejecute el JavaScript y luego descubra la redirección. Google puede hacerlo (su crawler usa un motor de renderizado basado en Chromium), pero con un retraso significativo. Los demás motores de búsqueda (Bing, Yandex) no siempre siguen las redirecciones JavaScript.
Resultado concreto: durante el período de transición, la indexación es más lenta, la transferencia de señales SEO es incierta y algunos bots simplemente no ven la redirección. Si tienes acceso a la configuración del servidor (Nginx, Apache, Caddy, CDN), usa siempre redirecciones HTTP del lado del servidor. Reserva el JavaScript para los casos donde la redirección del servidor es técnicamente imposible, como las Single Page Applications alojadas en un CDN estático.
No informar a Google vía Search Console
La herramienta Change of Address en Google Search Console está diseñada específicamente para acelerar las migraciones de dominio en el índice de Google. Sin embargo, muchas migraciones se realizan sin usar esta herramienta.
Sin el Change of Address, Google debe descubrir la migración por sí mismo rastreando el antiguo dominio y siguiendo las redirecciones. Este proceso puede tardar varias semanas, incluso varios meses para los sitios voluminosos. Mientras tanto, el antiguo dominio permanece en el índice y el nuevo dominio aún no hereda toda la autoridad.
Con el Change of Address, Google recibe una señal explícita: el antiguo dominio ha migrado al nuevo. Google verifica que las redirecciones 301 están implementadas y luego acelera la actualización de su índice. La herramienta está disponible en Search Console, sección Configuración, luego Cambio de dirección. Ambos dominios (antiguo y nuevo) deben estar verificados en Search Console.
Casos de uso concretos con CaptainDNS
Migración de subdominio al dominio principal
Alojas tu blog en blog.captaindns.com y decides trasladarlo a captaindns.com/es/blog para consolidar la autoridad SEO.
Configuración:
- Crea una redirección 301 con path forwarding en
blog.captaindns.com - Destino:
captaindns.com/es/blog - Activa la transferencia de ruta para que
blog.captaindns.com/article-1redirija acaptaindns.com/es/blog/article-1
Resultado: los backlinks hacia el blog, que reforzaban únicamente el subdominio, benefician ahora al dominio principal. La autoridad de dominio se concentra en una sola entidad en lugar de estar dispersa.
Puntos de atención:
- Actualiza los enlaces internos del sitio principal para apuntar a las nuevas URLs (
/es/blog/...) y no al antiguo subdominio. - Actualiza el sitemap para incluir las URLs del blog bajo el dominio principal.
- Si el blog tenía su propio perfil en Search Console, declara el cambio de dirección.
Consolidación de varios subdominios
Posees shop.captaindns.com, docs.captaindns.com y status.captaindns.com. Decides reagrupar todo bajo captaindns.com.
Configuración:
| Subdominio | Destino | Path forwarding |
|---|---|---|
| shop.captaindns.com | captaindns.com/es/pricing | Sí |
| docs.captaindns.com | captaindns.com/es/docs | Sí |
| status.captaindns.com | captaindns.com/es/status | No (página única) |
Cada subdominio se configura en 301 con CaptainDNS Redirect Hosting. El path forwarding preserva la estructura de URL para los dos primeros subdominios.
Beneficio SEO: en lugar de repartir la autoridad de dominio en 4 entidades distintas (dominio principal + 3 subdominios), toda la autoridad se consolida en el dominio principal. Los backlinks adquiridos por la documentación o la tienda refuerzan ahora todo el sitio.
Trampa a evitar: si tus subdominios tenían certificados TLS distintos, asegúrate de que el certificado del dominio principal cubra también las rutas de destino. Un certificado wildcard (*.captaindns.com) simplifica la gestión.
Rediseño con cambio de estructura de URLs
Pasas de una estructura plana (captaindns.com/dns-check) a una estructura jerárquica (captaindns.com/es/tools/dns/test-propagation).
Este caso requiere un plan de redirección 1:1, ya que la estructura cambia completamente. El path forwarding no es suficiente.
| Antigua URL | Nueva URL |
|---|---|
| captaindns.com/dns-check | captaindns.com/es/tools/dns/test-propagation |
| captaindns.com/spf-check | captaindns.com/es/tools/email-authentication/spf-check |
| captaindns.com/dkim-check | captaindns.com/es/tools/email-authentication/dkim-check |
Crea una redirección 301 individual para cada URL. No hay atajo posible.
Cambio de CMS con nuevas URLs
Migras de WordPress (captaindns.com/2025/03/mon-article) a un CMS headless con URLs limpias (captaindns.com/es/blog/mon-article).
El cambio de CMS modifica a menudo la estructura de URLs del blog. Los permalinks de WordPress incluyen la fecha, el nuevo CMS usa un slug simple. Cada antigua URL de WordPress debe redirigirse en 301 hacia la nueva URL.
captaindns.com/2025/03/mon-article → 301 → captaindns.com/es/blog/mon-article
captaindns.com/2025/04/autre-article → 301 → captaindns.com/es/blog/autre-article
Exporta la lista completa de permalinks de WordPress y mapea cada uno hacia la nueva URL antes de desactivar el antiguo CMS.
Consejo: si tu nuevo CMS utiliza los mismos slugs que WordPress (el título del artículo en minúsculas con guiones), puedes crear una regla de reescritura que elimine el prefijo de fecha y añade el prefijo /es/blog/. Esto reduce considerablemente el trabajo de mapeo para los sitios con cientos de artículos.
Internacionalización y redirección por idioma
Lanzas versiones localizadas de tu sitio. La URL /tools/dns-check se convierte en /es/tools/dns-check, /en/tools/dns-check, /de/tools/dns-check, etc.
Para las antiguas URLs sin prefijo de idioma, dos enfoques:
Enfoque 1: redirección 301 hacia la locale por defecto
Redirige las antiguas URLs hacia la versión del idioma principal:
captaindns.com/tools/dns-check → 301 → captaindns.com/es/tools/dns-check
Fácil de configurar, pero los visitantes anglófonos que tenían un backlink hacia /tools/dns-check llegan a la versión en español.
Enfoque 2: redirección 302 con detección de idioma
Redirige las antiguas URLs hacia la versión localizada en función del encabezado Accept-Language del navegador. Usa una 302 porque la redirección es condicional:
captaindns.com/tools/dns-check → 302 → captaindns.com/es/tools/dns-check (visitante ES)
captaindns.com/tools/dns-check → 302 → captaindns.com/en/tools/dns-check (visitante EN)
Más complejo de configurar, pero ofrece una mejor experiencia de usuario. Asegúrate de implementar las etiquetas hreflang en las páginas de destino para ayudar a Google a comprender la estructura multilingüe.
Plan de acción recomendado
-
Auditar tus URLs existentes: exporta la lista de páginas indexadas desde Google Search Console e identifica las páginas de alto valor (tráfico, backlinks).
-
Elegir el código de redirección correcto: migración permanente = 301. Campaña temporal = 302. En caso de duda, hazte la pregunta: ¿la antigua URL volverá algún día? Si no, usa una 301.
-
Crear el plan de redirección 1:1: cada antigua URL debe corresponder a una URL de destino. Sin redirección genérica hacia la homepage.
-
Configurar las redirecciones: usa el Redirect Hosting CaptainDNS para crear las redirecciones 301/302 con HTTPS automático y transferencia de ruta.
-
Verificar la propagación DNS: confirma que los registros DNS apuntan al servidor de redirección con el test de propagación DNS.
-
Declarar el cambio en Google Search Console: usa la herramienta "Change of Address" y envía el nuevo sitemap.
-
Monitorizar durante 90 días: sigue el tráfico orgánico, los errores de rastreo y las posiciones en Search Console. Corrige inmediatamente los problemas detectados.
Configura tus redirecciones ahora: usa el Redirect Hosting CaptainDNS para crear redirecciones 301/302 con HTTPS automático y transferencia de ruta.
FAQ
¿Cuál es la diferencia entre una redirección 301 y 302?
La 301 es una redirección permanente: indica a los navegadores y a los motores de búsqueda que la URL ha cambiado definitivamente. La 302 es una redirección temporal: indica que la URL actual está temporalmente accesible en otra dirección. La diferencia principal para el SEO es que la 301 transfiere la autoridad (PageRank) hacia el destino, mientras que la 302 conserva la autoridad en la URL de origen.
¿Una redirección 302 penaliza el SEO?
No, la 302 no penaliza el SEO en sentido estricto. Google no aplica sanción. El problema es que Google sigue indexando la URL de origen y no transfiere la autoridad. Si usas una 302 para una migración permanente, Google indexa la URL equivocada y tu nuevo dominio no se beneficia de los backlinks. No es una penalización, pero el resultado es similar: pérdida de tráfico orgánico.
¿Cuánto tiempo hay que mantener las redirecciones después de una migración?
Mínimo 6 meses, recomendado 1 año, ideal permanente. Google necesita tiempo para volver a rastrear todas tus páginas y actualizar su índice. Los backlinks en sitios de terceros seguirán apuntando al antiguo dominio durante años. Mientras el antiguo dominio esté registrado, las redirecciones deberían permanecer activas.
¿Qué sucede si uso una 302 en lugar de una 301?
Google sigue indexando la antigua URL y no transfiere el PageRank hacia el destino. Tu nuevo dominio no se beneficia de la autoridad acumulada por el antiguo. Con el tiempo, Google puede terminar por tratar la 302 como una 301, pero el plazo es impredecible. La corrección es reemplazar todas las 302 por 301. Google volverá a rastrear las URLs y actualizará su índice.
¿Las redirecciones en cadena afectan al SEO?
Sí. Cada salto en una cadena de redirección consume una solicitud de rastreo y añade latencia. Googlebot sigue generalmente hasta 5 redirecciones antes de abandonar. Más allá de eso, la página final no se rastrea ni se indexa. Incluso por debajo de 5 saltos, la señal SEO puede diluirse. Limita cualquier cadena a 2 saltos como máximo y corrige las antiguas redirecciones para apuntar directamente al destino final.
¿Cómo verificar que una redirección funciona correctamente?
Varios métodos. En línea de comandos, usa curl -I URL para mostrar los encabezados de respuesta HTTP y verificar el código de estado (301 o 302) y el encabezado Location. En un navegador, abre las herramientas de desarrollador (pestaña Red) y observa la cadena de solicitudes. También puedes usar el Page Crawl Checker para verificar las redirecciones y detectar las cadenas.
¿Hay que redirigir cada URL individualmente?
Sí, idealmente. Cada antigua URL debe redirigir hacia la página equivalente en el nuevo dominio (redirección 1:1). Si la estructura de URL se conserva, el path forwarding simplifica la configuración: la ruta de la antigua URL se transmite automáticamente al destino. Si la estructura cambia, debes mapear cada URL manualmente.
¿Google sigue las redirecciones JavaScript?
Google puede seguir las redirecciones JavaScript, pero con limitaciones. El contenido de la página debe primero ser renderizado por el motor de renderizado de Google, lo que añade un retraso. Además, no todas las redirecciones JavaScript se detectan de forma fiable. Google recomienda usar redirecciones del lado del servidor (301, 302) para los cambios de URL importantes.
¿Cuál es la diferencia entre 301 y 308?
Ambas son redirecciones permanentes con transferencia completa del SEO. La diferencia es técnica: la 301 permite al navegador transformar una solicitud POST en GET durante la redirección, mientras que la 308 preserva el método HTTP original (un POST sigue siendo un POST). Para las páginas web clásicas (solicitudes GET), 301 y 308 son funcionalmente idénticas. El código 308 se usa principalmente para APIs.
¿Cuántas redirecciones sigue Google antes de abandonar?
Google sigue generalmente hasta 5 redirecciones en una cadena antes de abandonar. John Mueller de Google confirmó este comportamiento. Si la página final no se alcanza en 5 saltos, no se rastrea ni se indexa. La recomendación es no superar nunca los 2 saltos para garantizar una transferencia óptima de la señal SEO.
¿Se puede anular una redirección 301?
Técnicamente sí, basta con eliminar la regla de redirección en el servidor. Pero en la práctica, los navegadores que han almacenado en caché la 301 seguirán redirigiendo automáticamente hasta la expiración de su caché. Google también necesita volver a rastrear la URL para constatar que la redirección ya no existe. El plazo de vuelta a la normalidad puede ser de varias semanas.
¿Cómo gestionar una migración con miles de URLs?
Exporta la lista completa de URLs indexadas desde Google Search Console. Usa una hoja de cálculo para crear el mapeo 1:1. Si la estructura se conserva, una sola regla de redirección con path forwarding es suficiente. Si la estructura cambia, agrupa las URLs por patrón y crea reglas de reescritura (regex) en tu servidor o tu CDN. Prueba una muestra antes de desplegar el conjunto.
¿Cuál es la diferencia entre una redirección 301 y un canonical tag?
La 301 redirige físicamente al visitante hacia una nueva URL: la antigua página ya no es accesible. El canonical tag (rel=canonical) deja ambas páginas accesibles pero indica a Google cuál indexar de preferencia. Usa una 301 cuando la URL de origen ya no tiene razón de existir. Usa un canonical cuando ambas URLs deben permanecer en línea (contenido duplicado, parámetros de URL, versiones paginadas).
¿Una redirección ralentiza mi sitio?
Sí. Cada redirección añade un viaje de ida y vuelta en la red (100 a 300 ms por salto). El impacto se concentra en el LCP (Largest Contentful Paint), la métrica de velocidad de carga. Las redirecciones 301 almacenadas en caché por el navegador ya no tienen impacto después de la primera visita, ya que el navegador redirige localmente sin contactar el servidor.
¿Google sigue las redirecciones meta refresh?
Sí, Google puede seguir las redirecciones meta refresh, pero con un retraso. La página HTML debe descargarse y analizarse antes de que Google detecte la redirección. Google desaconseja este método y recomienda las redirecciones del lado del servidor (301, 302). Las meta refresh también plantean un problema para los demás motores de búsqueda, que no siempre las siguen.
Glosario
- Redirección 301: redirección HTTP permanente. Indica que la URL ha cambiado definitivamente y transfiere la autoridad SEO hacia el destino.
- Redirección 302: redirección HTTP temporal. Indica que la URL está temporalmente accesible en otra dirección. La autoridad SEO permanece en la URL de origen.
- Redirección 307: redirección temporal que preserva el método HTTP. Equivalente estricto de la 302 sin transformación POST a GET.
- Redirección 308: redirección permanente que preserva el método HTTP. Equivalente estricto de la 301 sin transformación POST a GET.
- PageRank: algoritmo de Google que mide la importancia de una página web en función de la cantidad y calidad de los enlaces entrantes.
- Canonical tag: etiqueta HTML
rel=canonicalque indica a Google cuál versión de una URL es la preferida entre varias páginas con contenido idéntico o similar. - Canonicalización: proceso por el cual Google elige la URL preferida entre varias URLs que acceden al mismo contenido.
- Cadena de redirección: secuencia de redirecciones sucesivas donde una URL redirige hacia una segunda, que redirige hacia una tercera, etc.
- Bucle de redirección: situación donde dos URLs se redirigen mutuamente, creando un ciclo infinito.
- Path forwarding: mecanismo que transmite la ruta de la URL de origen hacia el destino durante una redirección.
- Soft 404: página que devuelve un código HTTP 200 pero cuyo contenido indica una página de error. Google la trata como un 404 para la indexación.
- Change of Address: herramienta de Google Search Console que permite declarar oficialmente un cambio de dominio y acelerar la migración en el índice de Google.
- Crawl budget: número de páginas que Googlebot puede explorar en un sitio en un tiempo dado. Las redirecciones consumen crawl budget, en particular las cadenas de redirecciones.
- Core Web Vitals: conjunto de métricas de Google (LCP, INP, CLS) que miden el rendimiento de usuario de una página web. Las redirecciones impactan principalmente el LCP añadiendo latencia de red.
- CNAME: tipo de registro DNS que crea un alias de un dominio hacia otro. Utilizado para apuntar un dominio hacia un servidor de redirección.
Guías de redirección de dominio relacionadas
- Vanity URL, link tracking y códigos QR: la guía completa de redirecciones marketing: crea enlaces de marca, rastrea los clics y mide el tráfico offline-to-online
Fuentes
- RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, section 6.4: definición oficial de los códigos de redirección HTTP 301, 302 y 307
- RFC 7238 - The Hypertext Transfer Protocol Status Code 308: definición del código de redirección permanente 308
- Google Search Central - Redirects and Google Search: documentación oficial sobre el tratamiento de redirecciones por Google
- Google Search Central - Change of Address tool: guía oficial para declarar un cambio de dominio
- Google Search Central - Avoid creating duplicate content: buenas prácticas para redirecciones y contenido duplicado
