Redirección 301 vs 302: comprender las diferencias, el impacto SEO y lograr una migración de dominio éxitosa
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 raiz
- Los códigos 307 y 308 existen para preservar el método HTTP (POST, PUT)
- CaptainDNS Redirect Hosting gestióna las 301/302 con HTTPS automático
Cambiar de nombre de dominio, fusionar dos sitios, pasar de HTTP a HTTPS: todas estas operaciónes dependen de las redirecciónes 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 migraciónes de dominio útilizan redirecciónes 302 en lugar de 301, causando una pérdida media de tráfico orgánico dos veces mayor que las migraciónes 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 éxitosa. Ya sea que gestiónes un sitio corporativo o un portal de 50 000 páginas, los principios son los mismos.
Última precisión: esta guía trata las redirecciónes del lado del servidor (códigos de estado HTTP). Las redirecciónes JavaScript o las etiquetas meta refresh no se abordan aquí porque presentan problemás 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 "Guias relaciónadas" al final del articulo.
Los 4 códigos de redirección HTTP
El protocolo HTTP define cuatro códigos de redirección principales. Cada uno comúnica una intención diferente al navegador y a los motores de busqueda.
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 cache la redirección y redirige automáticamente las futuras solicitudes hacia el destino, sin volver a pasar por el servidor de origen. Este cache 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 implementaciónes HTTP, es la razón por la que se creo el código 308.
302 Found
El código 302 significa que el recurso esta 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 cache 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 correspondia con la específicacion. 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 garantia: el método HTTP se preserva. Si el cliente envia un POST, la redirección reenvia un POST hacia el destino.
HTTP/1.1 307 Temporary Redirect
Location: https://captaindns.com/api/v2/submit
Este código esta definido en la RFC 7231, sección 6.4.7. Se útiliza principalmente para formularios y API REST dónde la preservacion del método es crítica. Para las redirecciónes 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 garantia 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 redirecciónes permanentes de API dónde el método HTTP debe conservarse. Para las redirecciónes de páginas web (GET), 301 y 308 son funciónalmente idénticos.
Tabla comparativa de los 4 códigos
| Código | Tipo | Método HTTP preservado? | Cache del navegador? | Transferencia SEO? |
|---|---|---|---|---|
| 301 | Permanente | No (POST puede convertirse en GET) | Si | Si (100 %) |
| 302 | Temporal | No (POST puede convertirse en GET) | No | Parcial (Google indexa el origen) |
| 307 | Temporal | Si | No | Parcial (mismo comportamiento que 302) |
| 308 | Permanente | Si | Si | Si (mismo comportamiento que 301) |
En la práctica, para las redirecciónes de páginas web (solicitudes GET), solo los códigos 301 y 302 son relevantes. Los códigos 307 y 308 estan reservados para contextos técnicos dónde la preservacion del método HTTP es necesaria.
Redirecciónes del lado del servidor vs JavaScript
Los códigos 301, 302, 307 y 308 son redirecciónes del lado del servidor: el servidor envia un encabezado HTTP Location y el navegador lo sigue inmediatamente. Pero también existen redirecciónes del lado del cliente, implementadas en JavaScript o mediante una etiqueta meta refresh.
Redirecciónes del lado del servidor (HTTP): Google las detecta y las sigue inmediatamente durante el rastreo. La transferencia de senales SEO es fiable y rápida. Es el método recomendado por Google Search Central para cuálquier cambio de URL.
Redirecciónes 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 anade un retraso significativo. Google clasífica este método cómo último recurso, a útilizar solo cuándo la redirección del lado del servidor es imposible.
Redirecciónes 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 | Deteccion por Google | Transferencia SEO | Caso de uso |
|---|---|---|---|
| Del lado del servidor (301/302) | Inmediata | Completa (301) o parcial (302) | Migraciónes, 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 | Ningun caso recomendado |
El riesgo principal de las redirecciónes 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) dónde 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 redirecciónes?
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 redirecciónes 301, el navegador almacena la correspondencia en un cache local. Las visitas siguientes a la antigua URL se redirigen directamente por el navegador, sin contactar el servidor de origen. Este cache es persistente: sobrevive al cierre del navegador y solo se vacia mediante un borrado manual del cache o la expirácion definida por los encabezados Cache-Control.
Para las redirecciónes 302, el navegador no almacena en cache 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 redirecciónes dinamicas (geolocalización, pruebas A/B, campanas temporales).
Esta diferencia de cache tiene un impacto directo en el rendimiento. Una 301 ahorra una solicitud de red en cada visita posterior. Una 302 anade sistematicamente 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 redirecciónes:
- 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 cómo una senal fuerte para retirár la página del índice. Usa el 410 cuándo 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 cuálquier redirección.
Transferencia de PageRank y autoridad
El PageRank es la puntuacion de autoridad que Google asígna 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 penalizacion del 15 % sobre el PageRank transmitido mediante una 301. Desde una actualización confirmada por Gary Illyes del equipo Google Search, esta penalizacion 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 cuándo una 302 permanece activa durante meses o años. Google termina por tratarla cómo una 301 de facto, pero el plazo es impredecible y el período de transición causa una pérdida de posiciónamiento.
Indexación y canonicalizacion
La elección 301 vs 302 determina que URL muestra Google en sus resultados:
Con una 301: Google elimina la antigua URL de su índice e indexa el destino. Los resultados de busqueda muestran la nueva URL. Este proceso tarda generalmente de algunos dias 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 cómo la versión canonica. Resultado: tus visitantes ven la antigua URL en Google, hacen clic, son redirigidos a la nueva página, pero las senales SEO (backlinks, antiguedad, autoridad) permanecen asociadas a la antigua URL.
Cache del navegador y conteo de visitas
La 301 se almacena en cache 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 redirecciónes, ya que las visitas siguientes ya no pasan por tu servidor.
La 302 no se almacena en cache. 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 cuándo una URL redirige hacia una segúnda URL, que a su vez redirige hacia una tercera, y así sucesivamente. Cada salto en la cadena consume una solicitud de rastreo y anade latencia.
Google sigue las cadenas de redirección, pero con limites. John Mueller confirmo que Googlebot sigue generalmente 5 redirecciónes antes de abandonar. Mas alla 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 senal SEO. La recomendación es limitar cuálquier cadena a 2 saltos cómo maximo: 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 esta disenada para transferir la autoridad. Google no aplica sancion, pero indexa la URL equivocada y conserva la autoridad en el lugar incorrecto. El resultado se parece a una penalizacion, 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 multiples ocasíones. La antigua penalizacion del 15 % ya no existe.
Mito: Google trata las 302 de larga duración cómo 301. Realidad: es parcialmente cierto. Google puede, tras un largo período, decidir tratar una 302 cómo 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 redirecciónes del lado del cliente (JavaScript, meta refresh) son equivalentes. Realidad: no. Google puede seguir las redirecciónes JavaScript, pero con un retraso adicional (el renderizado de la página debe efectuarse por el motor de renderizado). Las meta refresh estan desaconsejadas por Google. Solo las redirecciónes del lado del servidor (301, 302, 307, 308) se procesan de forma inmediata y fiable.
Mito: las 301 son instantaneas 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 dias 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 redirecciónes: un requisito indispensable
El servidor que aloja las redirecciónes 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 mostrara 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 configuraciónes manuales en tu propio servidor (Nginx, Apache, Caddy), asegurate de que:
- El certificado TLS cubra todos los dominios de origen (antiguo dominio, variantes www, subdominios).
- La renovacion del certificado este automatizada (Let's Encrypt con certbot o acme.sh).
- Las redirecciónes HTTP hacia HTTPS esten configuradas además de las redirecciónes de dominio.
301, canonical o ambos? Elegir el enfoque correcto
Las redirecciónes 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 funciónan de forma muy diferente y no se útilizan en las mismás situaciónes.
Cuando usar una 301 en lugar de un canonical tag?
La distinción es simple: la 301 redirige fisicamente 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 cuándo 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 indicacion a Google: entre estas dos páginas con contenido idéntico o similar, esta es la que debes indexar. Google puede seguir esta indicacion o ignorarla.
| Criterio | Redirección 301 | Canonical tag |
|---|---|---|
| El visitante es redirigido? | Si | No, ambas páginas son accesibles |
| Senal para Google | Directiva fuerte (obligatoria) | Indicacion (sugerencia, puede ser ignorada) |
| Ambas URLs existen? | No, solo el destino es accesible | Si, ambas permanecen en linea |
| Transferencia de PageRank | 100 % hacia el destino | Google consolida las senales en la URL canonica |
| Caso de uso principal | URL eliminada, migración, cambio definitivo | Contenido duplicado, parametros de URL, versiónes páginadas |
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 parametros de ordenacion, variante regional), usa un canonical.
Combinar 301 y canonical
Después de una migración de dominio, Google recomienda usar ambas senales juntas cuándo sea posible. La 301 redirige fisicamente a los visitantes y a los bots. El canonical tag en la página de destino refuerza la senal confirmando que esta URL es la versión preferida.
Concretamente, después de configurar tus redirecciónes 301 desde el antiguo dominio hacia el nuevo, anade en cada página de destino un canonical tag que apunte a si misma:
<link rel="canonical" href="https://captaindns.com/es/tools" />
Esta doble senal es particularmente útil cuándo tu contenido es accesible mediante multiples rutas (antiguo dominio redirigido, variante www, versión HTTP). Google recibe un mensaje coherente de todas las fuentes: el destino es efectivamente la URL canonica.
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 cómo versión canonica durante el período de transición.
Cuando 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 usara 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
Consolidacion de varios dominios
Posees varios dominios (variantes ortograficas, extensiones de pais, 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 canonica 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
| Situacion | Ejemplo | Por qué 301? |
|---|---|---|
| Migración de dominio | antiguo.captaindns.com hacia captaindns.com | El dominio de origen ya no servirá contenido |
| Consolidacion 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 canonica del dominio |
Cuando usar una 302?
La 302 es la elección correcta cuándo la redirección es temporal: previenes restablecer la URL de origen a su estado original.
Campanas de marketing temporales
Creas una vanity URL para una campana limitada en el tiempo. La redirección se desactivara al final de la campana.
promo.captaindns.com 302 captaindns.com/es/pricing
(durante la campana 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 retirára una vez terminada la prueba.
Mantenimiento planificado
Tu sitio esta 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 condiciónal y no debe almacenarse en cache, ya que un mismo usuario podria visitar desde otro pais.
captaindns.com 302 captaindns.com/es/ (visitante español)
captaindns.com 302 captaindns.com/en/ (visitante ingles)
Redirecciónes condiciónales (movil/escritorio)
Rediriges a los visitantes moviles hacia una versión dedicada. Esta práctica es cada vez menos comun (el diseño responsive la ha reemplazado en gran medida), pero todavia existe en algunos sitios.
Tabla recapitulativa: casos de uso 302
| Situacion | Ejemplo | Por qué 302? |
|---|---|---|
| Campana 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 | Raiz hacia versión local | Condicional, no debe almacenarse en cache |
| Redirección movil | Sitio hacia versión movil | 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: auditoria 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 cuálquier 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
Clasífica 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. Cuálquier 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 generica 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, redirigelas hacia la página más pertinente (no la homepage por defecto).
4. Verificar el contenido del nuevo dominio
Antes de activar las redirecciónes, asegurate de que cada página de destino existe y funcióna. Una redirección 301 hacia una página 404 es peor que no tener redirección: Google ve una página de error y desclasífica la URL.
5. Respaldar los datos existentes
Antes de cuálquier modificación, exporta una copia completa:
- Export CSV de todas las URLs indexadas desde Search Console
- Export de las posiciónes de busqueda (Semrush, Ahrefs u otra herramienta de seguimiento)
- Export de los backlinks del antiguo dominio
- Captura de pantalla de las estadisticas de tráfico orgánico de los últimos 90 dias
Estos datos servirán cómo referencia para medir el impacto de la migración y detectar anomalias después del cambio.
Configurar las redirecciónes 301
5. Implementar las redirecciónes en cada URL
La regla fundamental: cada URL debe redirigirse individualmente. Redirigir únicamente la raiz (antiguo.captaindns.com hacia captaindns.com) no es suficiente. Las páginas profundas, los articulos 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 anade 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.
6. Gestiónar las 4 variantes de cada URL
Cada URL existe potencialmente en 4 versiónes:
http://antiguo.captaindns.com/pagehttps://antiguo.captaindns.com/pagehttp://www.antiguo.captaindns.com/pagehttps://www.antiguo.captaindns.com/page
Las 4 versiónes deben llegar al mismo destino. Olvidar una variante significa dejar backlinks sin redirección.
Verificar el DNS
7. Configurar los registros DNS
Para que las redirecciónes funciónen, 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.
8. 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
9. 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 redirecciónes 301 estan correctamente configuradas
- Acelera la actualización del índice de Google
- Transfiere las senales del antiguo dominio al nuevo
Prerrequisito: ambos dominios (antiguo y nuevo) deben estar verificados en Google Search Console.
10. Enviar el nuevo sitemap
Envia 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 este actualizado.
Monitorizacion post-migración
11. Supervisar el tráfico orgánico (30/60/90 dias)
Una bajada temporal del tráfico orgánico (10 a 20 %) es normal en las 2 a 4 semanas posteriores a una migración. Mas alla 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 deberia estabilizarse y comenzar a subir.
- Mes 2-3: el tráfico deberia recuperar su nivel pre-migración, incluso superarlo si el nuevo sitio es de mejor calidad.
12. Verificar los errores en Search Console
Consulta el informe "Páginas" en Google Search Console para identificar errores 404, errores de redirección y problemás de indexación. Corrige inmediatamente las URLs que devuelven errores.
13. 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.
14. Verificar las posiciónes de busqueda
Sigue tus palabras clave estrategicas en una herramienta de seguimiento de posiciónes (Semrush, Ahrefs, Sistrix). Compara las posiciónes antes y después de la migración. Una palabra clave que cae más de 10 posiciónes 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 | Posicion antes | Posicion D+7 | Posicion D+30 | Posicion 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 senal de que la migración se desarrolla correctamente. Un estancamiento en D+30 requiere investigacion (redirecciónes faltantes, contenido modificado, problemás técnicos).
Duracion de mantenimiento de las redirecciónes
14. Cuanto tiempo mantener las redirecciónes?
Google recomienda mantener las redirecciónes 301 de forma permanente si es posible. En la práctica:
- Minimo 6 meses: por debajo, Google no ha tenido tiempo de volver a rastrear todas tus páginas y actualizar su índice.
- Recomendado 1 ano: la gran mayoria de las senales SEO habrán sido transferidas.
- Ideal: permanente: mientras el antiguo dominio este activo, las redirecciónes deben funciónar. Los backlinks en sitios de terceros seguirán apuntando al antiguo dominio durante años.
Si dejas expirár el antiguo dominio, las redirecciónes obviamente dejan de funciónar. 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 expirá y un tercero lo compra, puede recuperar los backlinks que aun apuntaban al antiguo dominio. En el mejor de los casos, muestra contenido sin relación. En el peor, explota la reputacion 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.
Planificacion semana a semana
Una migración de dominio se prepara con varias semanas de anticipacion. Este es un calendario tipo para estructurar las etapas y evitar olvidos.
| Semana | Accion | Verificacion |
|---|---|---|
| S-4 | Auditoria completa de URLs, inventario de backlinks | Lista exhaustiva exportada |
| S-3 | Configurar las redirecciónes 301 en el servidor | Probar cada redirección con curl |
| S-2 | Declarar el nuevo dominio en Search Console | Verificacion de propiedad válidada |
| S-1 | Últimás pruebas, backup del sitemap del antiguo dominio | Todas las redirecciónes funciónan |
| D-0 | Activar las redirecciónes, 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 dia |
| S+4 | Primer balance a 30 dias | Comparacion de tráfico antes y después de la migración |
| S+8 | Segúndo balance a 60 dias | Estabilizacion esperada del tráfico orgánico |
| S+12 | Balance final a 90 dias | Decision: conservar o ajustar las redirecciónes |
Este calendario es indicativo. Para los sitios voluminosos (varios miles de páginas), prev una semana adicional para la auditoria 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 cómo 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 cuálquier 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 comun: 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 cómo duplicados, y la autoridad SEO se fragmenta entre las dos versiónes.
Punto importante: Google Search Console trata HTTP y HTTPS cómo propiedades distintas. Debes enviar ambas versiónes (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 redirecciónes 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 redirecciónes
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 segúnda solicitud para el destino. Una cadena de 3 redirecciónes 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 redirecciónes activas, el consumo de presupuesto de rastreo puede volverse significativo. Googlebot dedica tiempo a seguir redirecciónes en lugar de rastrear contenido nuevo.
Recomendaciones:
- Minimiza el número de redirecciónes en las páginas de alto tráfico y alto valor SEO
- Elimina las cadenas de redirecciónes apuntando directamente al destino final
- Después de una migración, una vez actualizado el índice (6 a 12 meses), las redirecciónes 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 metricas de rendimiento de usuario medidas por Google: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) y CLS (Cumulative Layout Shift). Estas metricas influyen en el posiciónamiento desde 2021.
Cada redirección anade 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 ubicacion geográfica del visitante.
Impacto por metrica:
- LCP: directamente afectado. El tiempo de carga del contenido principal aumenta de 100 a 300 ms por redirección. En movil con una conexión lenta, el impacto puede superar los 500 ms por salto.
- CLS: ningun impacto. Las redirecciónes ocurren antes de la visualizacion de la página, no causan desplazamientos visuales.
- INP: ningun impacto. Las redirecciónes no afectan la reactividad de la página una vez cargada.
Buena noticia: las redirecciónes 301 almacenadas en cache por el navegador no tienen ningun 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 redirecciónes permanentes.
Para medir el impacto real de las redirecciónes en tus Core Web Vitals, usa Chrome DevTools (pestana 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 redirecciónes 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 terminos de autoridad.
La correccion es simple: cambia todas las redirecciónes 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 redirecciónes cómo soft 404: el contenido de la página de destino no corresponde con lo que la antigua URL prometia.
Resultado: Google ignora estas redirecciónes y desclasífica las URLs. Los backlinks que apuntaban a tus articulos 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, redirigela hacia la página tematicamente más cercana. Por ejemplo, un articulo de blog eliminado puede redirigirse hacia un articulo relaciónado que trate el mismo tema, o hacia la página de categoria correspondiente.
Cadenas de redirecciónes
Situacion típica: durante una primera migración, site-v1.captaindns.com fue redirigido hacia site-v2.captaindns.com. Durante una segúnda 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 anade latencia y consume una solicitud de rastreo. Mas alla de 5 saltos, Googlebot abandona. Incluso con 3 saltos, la senal SEO se diluye.
Corrige actualizando las antiguas redirecciónes 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 cuándo 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 canonicas 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 canonica que Google puede indexar cómo duplicado.
Verifica sistematicamente las 4 combinaciónes 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 canonica)
Eliminar las redirecciónes demasíado pronto
Algunos equipos eliminan las redirecciónes 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 estan fuera de tu control. Un articulo 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 aun, a un dominio comprado por un tercero.
No monitorizar después de la migración
La migración esta en marcha, las redirecciónes funciónan, el sitemap esta enviado. Trabajo terminado? No. Sin monitorizacion, no detectarás los problemás que aparecen en las semanas siguientes:
- Páginas 404 en el nuevo dominio (contenido eliminado o URL mal configurada)
- Redirecciónes rotas (certificado expirádo, servidor de redirección caido)
- Indexación bloqueada (robots.txt demasíado restrictivo en el nuevo dominio)
- Bajada anormal del tráfico en ciertas secciónes 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 redirecciónes no estan implementadas, tus suscriptores llegan a errores.
Haz un inventario de todos los canales que difunden enlaces hacia tu dominio: firmás de email, plantillas de newsletters, folletos PDF, presentaciones PowerPoint, perfiles de redes sociales. Actualiza los enlaces cuándo sea posible, pero cuenta con las redirecciónes para todo lo que no puedas modificar (emails ya enviados, PDF ya descargados).
No olvides los enlaces en aplicaciónes moviles, integraciones con socios y widgets incrustados en sitios de terceros. Estas fuentes suelen ser invisibles en las auditorias de backlinks pero generan un tráfico significativo.
Usar redirecciónes JavaScript en lugar de redirecciónes del servidor
Algunos equipos implementan redirecciónes mediante meta refresh o window.location en lugar de configurar redirecciónes del lado del servidor. Esta elección es problematica para el SEO.
Las redirecciónes JavaScript requieren que el motor de busqueda 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 busqueda (Bing, Yandex) no siempre siguen las redirecciónes JavaScript.
Resultado concreto: durante el período de transición, la indexación es más lenta, la transferencia de senales 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 redirecciónes HTTP del lado del servidor. Reserva el JavaScript para los casos dónde la redirección del servidor es técnicamente imposible, cómo las Single Page Applications alojadas en un CDN estatico.
No informar a Google via Search Console
La herramienta Change of Address en Google Search Console esta disenada específicamente para acelerar las migraciónes de dominio en el índice de Google. Sin embargo, muchas migraciónes se realizan sin usar esta herramienta.
Sin el Change of Address, Google debe descubrir la migración por si mismo rastreando el antiguo dominio y siguiendo las redirecciónes. 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 aun no hereda toda la autoridad.
Con el Change of Address, Google recibe una senal explicita: el antiguo dominio ha migrado al nuevo. Google verifica que las redirecciónes 301 estan implementadas y luego acelera la actualización de su índice. La herramienta esta 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 tenia su propio perfil en Search Console, declara el cambio de dirección.
Consolidacion 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 | Si |
| docs.captaindns.com | captaindns.com/es/docs | Si |
| 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 tenian certificados TLS distintos, asegurate 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 jerarquica (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 útiliza los mismos slugs que WordPress (el titulo del articulo en minusculas con guiones), puedes crear una regla de reescritura que elimine el prefijo de fecha y anade el prefijo /es/blog/. Esto reduce considerablemente el trabajo de mapeo para los sitios con cientos de articulos.
Internacionalizacion y redirección por idioma
Lanzas versiónes 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
Facil de configurar, pero los visitantes anglofonos que tenian 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 condiciónal:
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)
Mas complejo de configurar, pero ofrece una mejor experiencia de usuario. Asegurate de implementar las etiquetas hreflang en las páginas de destino para ayudar a Google a comprender la estructura multilingue.
🎯 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. Campana temporal = 302. En caso de duda, hazte la pregunta: la antigua URL volverá algun dia? 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 generica hacia la homepage.
-
Configurar las redirecciónes: usa el Redirect Hosting CaptainDNS para crear las redirecciónes 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 envia el nuevo sitemap.
-
Monitorizar durante 90 dias: sigue el tráfico orgánico, los errores de rastreo y las posiciónes en Search Console. Corrige inmediatamente los problemás detectados.
Configura tus redirecciónes ahora: usa el Redirect Hosting CaptainDNS para crear redirecciónes 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 busqueda que la URL ha cambiado definitivamente. La 302 es una redirección temporal: indica que la URL actual esta 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 sancion. 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 penalizacion, pero el resultado es similar: pérdida de tráfico orgánico.
Cuanto tiempo hay que mantener las redirecciónes después de una migración?
Minimo 6 meses, recomendado 1 ano, 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 este registrado, las redirecciónes deberian 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 cómo una 301, pero el plazo es impredecible. La correccion es reemplazar todas las 302 por 301. Google volverá a rastrear las URLs y actualizara su índice.
Las redirecciónes en cadena afectan al SEO?
Si. Cada salto en una cadena de redirección consume una solicitud de rastreo y anade latencia. Googlebot sigue generalmente hasta 5 redirecciónes antes de abandonar. Mas alla de eso, la página final no se rastrea ni se indexa. Incluso por debajo de 5 saltos, la senal SEO puede diluirse. Limita cuálquier cadena a 2 saltos cómo maximo y corrige las antiguas redirecciónes para apuntar directamente al destino final.
Cómo verificar que una redirección funcióna correctamente?
Varios métodos. En linea 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 (pestana Red) y observa la cadena de solicitudes. También puedes usar el Page Crawl Checker para verificar las redirecciónes y detectar las cadenas.
Hay que redirigir cada URL individualmente?
Si, 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 redirecciónes JavaScript?
Google puede seguir las redirecciónes JavaScript, pero con limitaciones. El contenido de la página debe primero ser renderizado por el motor de renderizado de Google, lo que anade un retraso. Además, no todas las redirecciónes JavaScript se detectan de forma fiable. Google recomienda usar redirecciónes del lado del servidor (301, 302) para los cambios de URL importantes.
Cuál es la diferencia entre 301 y 308?
Ambas son redirecciónes 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 funciónalmente idénticas. El código 308 se usa principalmente para APIs.
Cuantas redirecciónes sigue Google antes de abandonar?
Google sigue generalmente hasta 5 redirecciónes en una cadena antes de abandonar. John Mueller de Google confirmo 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 optima de la senal SEO.
Se puede anular una redirección 301?
Tecnicamente si, basta con eliminar la regla de redirección en el servidor. Pero en la práctica, los navegadores que han almacenado en cache la 301 seguirán redirigiendo automáticamente hasta la expirácion de su cache. 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 gestiónar una migración con miles de URLs?
Exporta la lista completa de URLs indexadas desde Google Search Console. Usa una hoja de calculo 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 patron 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 fisicamente 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 cuándo la URL de origen ya no tiene razón de existir. Usa un canonical cuándo ambas URLs deben permanecer en linea (contenido duplicado, parametros de URL, versiónes páginadas).
Una redirección ralentiza mi sitio?
Si. Cada redirección anade 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 metrica de velocidad de carga. Las redirecciónes 301 almacenadas en cache 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 redirecciónes meta refresh?
Si, Google puede seguir las redirecciónes 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 redirecciónes del lado del servidor (301, 302). Las meta refresh también plantean un problema para los demás motores de busqueda, 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 esta 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 transformacion POST a GET.
- Redirección 308: redirección permanente que preserva el método HTTP. Equivalente estricto de la 301 sin transformacion 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. - Canonicalizacion: proceso por el cuál Google elige la URL preferida entre varias URLs que acceden al mismo contenido.
- Cadena de redirección: secuencia de redirecciónes sucesivas dónde una URL redirige hacia una segúnda, que redirige hacia una tercera, etc.
- Bucle de redirección: situación dónde 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 cómo 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 redirecciónes consumen crawl budget, en particular las cadenas de redirecciónes.
- Core Web Vitals: conjunto de metricas de Google (LCP, INP, CLS) que miden el rendimiento de usuario de una página web. Las redirecciónes impactan principalmente el LCP anadiendo 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.
📚 Guias de redirección de dominio relaciónadas
- Vanity URL, link tracking y códigos QR: la guía completa de redirecciónes 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 - Redirections et Google Search: documentación oficial sobre el tratamiento de redirecciónes 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 redirecciónes y contenido duplicado
