Cambiar de dominio sin perder SEO: cómo migramos dgtl.io a withdgtl.com
Cómo migramos dgtl.io a withdgtl.com sin perder SEO: auditoría de 87 referencias, redirects 301, cambio de dirección en Search Console y continuidad DKIM.
Sergio
CEO, DGTL
Hace poco cambiamos nuestro propio dominio. dgtl.io pasó a ser withdgtl.com: un sitio en producción, 141 páginas en inglés y español, 20 posts de blog con posiciones que no queríamos quemar y un pipeline de ventas a mitad de conversación en las direcciones de correo viejas.
Esto es lo que nadie te cuenta de un cambio de dominio. Google procesa los redirects 301 bien desde hace una década. Lo que te golpea es todo lo demás: el canonical hardcodeado que nadie revisó, el logo del JSON-LD apuntando al host viejo, el registro DKIM que nunca se creó en el dominio nuevo y que manda tus propuestas a spam la misma semana en que anuncias el nombre nuevo. Esas pérdidas son silenciosas. Nada falla, nada alerta, y el daño se acumula por meses antes de que alguien lo conecte con el rebranding.
Este es el playbook que corrimos con nosotros mismos. Róbatelo.
Empieza con una auditoría de referencias, no con un mapa de redirects
Antes de tocar DNS, corrimos una búsqueda del dominio viejo en todo el código y el contenido. El conteo: 87 referencias hardcodeadas. No ocho. Ochenta y siete, en un codebase que consideramos ordenado.
Se agruparon en seis categorías:
- URLs canónicas y alternates hreflang en la capa de metadata
- URLs de imágenes Open Graph y de tarjetas sociales
- JSON-LD: la url de Organization, el logo y el publisher de cada Article
- Configuración de sitemap y RSS
- Plantillas de email transaccional y las direcciones dentro de ellas
- Links en markdown dentro de los posts del blog
Más una cola larga que no vimos venir: dos variables de entorno, la configuración del CSP, el web manifest, un redirect de Cal.com y un workflow de GitHub Actions que usaba la URL vieja como health check.
Cada referencia terminó en una hoja con tres columnas: archivo, categoría, responsable. La auditoría tomó dos días, y fueron los dos días más valiosos de toda la migración. Si te saltas este paso, vas a publicar un sitio que redirige perfecto mientras le dice a Google, dentro de su propio structured data, que sigue viviendo en la dirección vieja.
Los 301: aburridos, de un solo salto y para siempre
La capa de redirects es donde todos se obsesionan. Es la parte fácil. Cinco reglas:
Preservan la ruta y cubren todo el host. dominio-viejo.com/blog/post redirige a dominio-nuevo.com/blog/post, con wildcard para subdominios y rutas que ya nadie recuerda.
Un solo salto. HTTP viejo a HTTPS viejo a HTTPS nuevo es una cadena. Cada salto extra diluye señal y suma latencia. Resuélvelo en el edge, no en la aplicación.
Los query strings sobreviven. Nuestro modelo de atribución depende de que los parámetros utm y el ?source= lleguen vivos al otro lado.
Código permanente. 301 o 308, nunca 302. Un redirect temporal le dice a Google que no mueva nada.
El dominio viejo no expira jamás. Renovamos dgtl.io por diez años. La autoridad que fluye por esos redirects se evapora el día que caduque el registro, y los dominios expirados de empresas reales se compran y se usan para phishing.
Después prueba en serio. Exporta las 500 URLs con más impresiones desde Search Console, pásalas todas por curl y verifica que cada una haga un redirect permanente de un solo salto a la misma ruta en el dominio nuevo. A nosotros la prueba nos atrapó tres rutas que rebotaban por un redirect legado de una reestructura anterior: un salto se había convertido en tres.
Search Console y la ventana de dos propiedades
La secuencia importa más que la velocidad:
- Verifica la propiedad del dominio nuevo con un registro TXT en DNS días antes del cambio.
- Cambia el DNS y despliega los redirects.
- Envía el cambio de dirección desde la propiedad vieja.
- Reenvía los sitemaps de ambos idiomas en la propiedad nueva.
- Mantén las dos propiedades abiertas al menos seis meses.
La señal útil vive en la propiedad vieja: los 404 de rutas olvidadas, los backlinks apuntando a URLs legadas raras. En nuestro caso, el bache duró entre dos y cuatro semanas de impresiones caídas antes de que las curvas volvieran a su tendencia. Coincide con lo que Google documenta y casi nadie cree: las posiciones se transfieren. Se transfieren si, y solo si, los redirects son totales y las señales on-page están de acuerdo con ellos.
El email es donde los rebrandings mueren en silencio
Un dominio nuevo tiene cero reputación de envío. Si cambias el sitio web y el email el mismo día, combinaste un bache de posicionamiento con un cráter de entregabilidad, por decisión propia.
Escalónalos. Nuestra secuencia, repartida en seis semanas:
- Semana 1: crea el dominio de envío en tu plataforma de email, publica SPF y DKIM (dos llaves de 2048 bits, para poder rotarlas después) y DMARC en p=none con reportes agregados activos.
- Semanas 2 a 5: calienta el dominio con correo real de bajo volumen. Hilos internos, algunos hilos con clientes, el newsletter al segmento más activo. Lee los reportes DMARC cada semana.
- Semana 6: mueve el volumen transaccional y de outbound, y sube DMARC a p=quarantine.
Mantén los buzones del dominio viejo vivos y con reenvío al menos un año. Los prospectos a mitad de negociación van a responder hilos viejos, y esas respuestas tienen que llegar.
El barrido de activos y la regla del corte único
El último pase es identidad: regenerar las imágenes OG con el wordmark nuevo (tenemos cinco rutas dinámicas de OG y las cinco traían el logo viejo horneado), cambiar el favicon y los íconos del manifest, actualizar la URL del logo en el JSON-LD de Organization, las bios de redes, las firmas de correo, las plantillas de propuestas, la organización de GitHub. LinkedIn y Slack cachean los previews de links por semanas, así que fuerza el refresco con el debugger de compartido de cada plataforma donde exista.
Y aquí va la parte con opinión: haz el corte de una sola vez. El "período de transición" con los dos dominios sirviendo el sitio en vivo es la peor opción disponible. Divide tu autoridad de enlaces, crea contenido duplicado, confunde al knowledge graph sobre cuál entidad eres y entrena a tu propio equipo a seguir compartiendo URLs viejas porque todavía funcionan. Elige una fecha, mueve sitio y activos en 48 horas, deja que el email siga su propio calendario de calentamiento y deja que los 301 hagan su trabajo.
Todo esto corre sobre un checklist por una razón: cada modo de falla en una migración es silencioso por defecto. El sitio sigue arriba y el demo sale bien, y seis semanas después alguien pregunta por qué los leads orgánicos cayeron 30% y a nadie se le ocurre revisar el registro DKIM.
Una cosa más que esta migración nos confirmó. Un rebranding es trabajo de Studio y de Marketing en el mismo sprint. Naming, wordmark y sistema de activos por un lado; SEO técnico, redirects y entregabilidad por el otro. Si se lo entregas solo a una agencia de marca, obtienes una identidad hermosa con posiciones destruidas. Si se lo entregas solo a un equipo de SEO, conservas el tráfico y publicas una marca más débil. Es el mismo argumento de por qué construimos DGTL en Quito: las prácticas funcionan mejor juntas. Si un cambio de nombre o de dominio está en tu roadmap, Studio corre el lado de identidad y Marketing corre el lado de búsqueda, bajo un solo contrato.
Relacionado: Diseño de marca que convierte → · Clusters temáticos y GEO → · Por qué Quito →