Cambiar de dominio sin perder posicionamiento es un objetivo de planificación, no una garantía. La forma de reducir el riesgo consiste en conservar la relación entre contenidos, redirigir cada URL al destino pertinente y comprobar las señales del sitio antes y después del cambio.
Una dirección antigua puede seguir llegando a tus clientes desde buscadores, correos y enlaces guardados mucho después del cambio de marca. El trabajo de migración consiste en cuidar esos recorridos y comprobar que cada persona llega a una respuesta pertinente.
Un dominio nuevo afecta más que la portada: enlaces, imágenes, correos, analítica, integraciones y perfiles externos pueden depender del anterior. Conviene tratarlo como un proyecto con inventario y responsables, aunque el diseño se mantenga igual.
Diferencia cambio de dominio, hosting y estructura
Cambiar de dominio significa que varía la dirección principal del sitio. Cambiar de hosting puede mantener todas las URLs. Modificar la estructura altera rutas dentro de un dominio. Es posible hacer varias cosas a la vez, pero cada cambio amplía lo que necesitas validar.
Si el motivo es únicamente mejorar el alojamiento, considera mantener el dominio y las rutas. Si necesitas una nueva marca, intenta no mezclar el traslado con una eliminación masiva de contenidos. Cuantos más elementos cambien, más difícil será explicar una variación de rendimiento.
1. Construye el inventario de URLs antes del traslado
Combina las rutas del sitemap, un rastreo del sitio, las páginas con clics en Search Console y las URLs utilizadas en campañas o materiales comerciales. El menú no contiene necesariamente todo lo que importa. Añade documentos y recursos que reciben enlaces.
Guarda también títulos, directivas, canonicals y métricas de referencia. Define qué URLs se mantienen, cuáles tienen equivalente y cuáles se retiran. Para una página que desaparece, no fuerces una redirección hacia un destino que no resuelve la misma necesidad.
2. Prepara un mapa de correspondencias
| URL de origen, ejemplo | Destino o decisión | Validación |
|---|---|---|
| dominio-anterior.example/servicio/ | dominio-nuevo.example/servicio/ | Mismo servicio y contenido accesible. |
| dominio-anterior.example/blog/guia/ | dominio-nuevo.example/blog/guia/ | Artículo y recursos completos. |
| Una página retirada sin equivalente | Decisión documentada; posible 404 o 410. | No enviar a la portada por defecto. |
| Una URL histórica que ya redirigía | Destino final pertinente. | Evitar cadenas innecesarias. |
Los dominios del ejemplo son ilustrativos. En tu archivo utiliza URLs completas y añade estado esperado, responsable y resultado de prueba. Mantén una fila por URL antigua: una regla general puede ayudar, pero no reemplaza comprobar las excepciones.
3. Valida el destino antes de hacerlo público
Comprueba que el nuevo dominio tiene certificado válido y sirve el contenido correcto. Revisa navegación, formularios, compra si existe, medios y páginas legales. Identifica las protecciones del entorno de pruebas para retirarlas en el momento adecuado sin exponer antes una copia indexable.
Verifica que canonicals, enlaces internos y sitemap señalan las URLs definitivas. Si hay idiomas, revisa también sus relaciones. Busca referencias al dominio antiguo en plantillas, botones, scripts y documentos que el usuario pueda descargar.
4. Implementa y prueba las redirecciones
Para un traslado permanente, configura redirecciones permanentes del lado del servidor según la plataforma. Cada URL antigua debe llevar a su equivalente con el menor recorrido razonable. Google recomienda mantener las redirecciones durante al menos un año; conviene conservarlas más si usuarios o enlaces siguen utilizando el dominio anterior.
Distingue la redirección del señalamiento de la URL preferida: nuestra guía de canonical explica el papel y los límites de esa etiqueta.
Prueba tanto páginas populares como rutas de distintas plantillas. Revisa HTTP y HTTPS, con y sin www, y URLs que ya redirigían. No confundas un mensaje visual de «página movida» con una respuesta de redirección correcta.
Conserva la propiedad y los certificados necesarios del dominio anterior mientras atienda solicitudes. Si caduca o deja de responder, las redirecciones no podrán funcionar. Asegura también que cambiar la web no elimina registros de correo que deban permanecer.
5. Qué comprobar al cambiar el dominio en WordPress
Haz una copia de la base de datos y archivos. Revisa la dirección de WordPress y la dirección del sitio, pero no limites el cambio a esos dos campos: el contenido y los plugins pueden guardar URLs absolutas.
Si además reconstruyes el sitio, revisa la arquitectura de información antes de cambiar rutas que podrían conservarse.
Si utilizas una sustitución de URLs, haz primero una simulación y emplea herramientas compatibles con datos serializados. Revisa qué tablas pertenecen al sitio y evita una sustitución global sin respaldo. Las reglas de redirección deben vivir donde realmente se atiende el dominio anterior, aunque WordPress ya funcione en el nuevo.
Después comprueba imágenes, enlaces permanentes, formularios y tareas programadas. Abre el sitio sin sesión para ver lo que recibe un visitante. Un administrador autenticado puede ver contenido o saltarse cachés que afectan a los usuarios reales.
6. Informa del cambio y supervisa las dos propiedades
Verifica las propiedades necesarias en Search Console y utiliza la herramienta de cambio de dirección cuando el traslado cumpla sus condiciones. Envía el sitemap del nuevo sitio y revisa los informes de ambas propiedades. Una herramienta de aviso no sustituye redirecciones ni corrige contenido perdido.
Actualiza perfiles empresariales, enlaces propios, campañas y firmas que controlas. Prioriza los destinos con tráfico o valor comercial. Si cambias también correos, prepara un proyecto separado para sus cuentas y entregabilidad.
Ejemplo de mapa: qué hacer con páginas que ya no encajan
Imagina una empresa que cambia de marca y aprovecha para reorganizar tres servicios en dos. Copiar las rutas antiguas mediante una regla general solo resuelve parte del traslado: una de las páginas ya no tiene un equivalente exacto. Esa excepción necesita una decisión editorial antes de configurar el servidor.
Revisa qué buscaban los usuarios de esa página y qué ofrecía. Si el servicio se integra de verdad en una página nueva, esa puede ser una correspondencia pertinente. Si desaparece y no hay sustituto, enviar al visitante a cualquier servicio crea una expectativa falsa. Documenta la retirada y evalúa una respuesta de ausencia adecuada.
Para una guía que mantiene su contenido, el destino normalmente debería ser la misma guía bajo el dominio nuevo. Para una categoría consolidada, revisa si la selección y los criterios de compra se conservan. La equivalencia se define por la necesidad resuelta, no por que ambas URLs contengan una palabra parecida.
Incluye una columna de justificación en el mapa. «Mismo contenido», «servicio integrado» o «retirado sin sustituto» permite auditar decisiones después. Si semanas más tarde alguien pregunta por una ruta, el equipo sabrá qué se acordó y no tendrá que improvisar otra redirección.
Cómo probar una redirección más allá de la portada
Elige una muestra por tipo de ruta y comprueba el recorrido completo. Una URL antigua puede redirigir correctamente al dominio nuevo y, desde allí, pasar por otra redirección hasta la versión final. El resultado visual quizá parezca normal, pero el recorrido revela reglas que conviene simplificar cuando sea posible.
Anota la URL solicitada, la respuesta inicial, los pasos intermedios y el destino final. Después revisa el contenido del destino. Un código de respuesta esperado no compensa una ficha que muestra otro producto o una página que pide iniciar sesión.
Incluye direcciones copiadas de enlaces reales y variantes que el sitio utilizaba. También comprueba URLs con parámetros importantes para funciones del negocio. Decide cuáles deben conservarse y cuáles pueden descartarse; una regla que elimina todo lo situado después de un signo de interrogación podría romper una función legítima.
Finalmente, revisa enlaces internos. Aunque las redirecciones atiendan las rutas antiguas, la nueva web debería enlazar directamente a sus destinos actuales. Esta limpieza facilita la navegación y reduce dependencias del dominio anterior dentro del propio sitio.
El dominio también está conectado a formularios, pagos y herramientas
Haz una lista de servicios que reconocen el dominio: analítica, formularios, CRM, pagos, calendarios, widgets, correos transaccionales y sistemas de acceso. Algunos requieren autorizar la nueva dirección o actualizar una URL de retorno. La migración debe reservar tiempo para comprobar esas dependencias.
Prueba cada recorrido con un caso identificable. Envía un formulario de prueba y verifica su recepción en el destino previsto. Si existe compra, utiliza el procedimiento permitido por el proveedor para revisar retorno y confirmación. No des por terminada una integración porque el botón siga apareciendo.
En medición, distingue continuidad de configuración y continuidad de datos. Cambiar una dirección visible no garantiza que las etiquetas, filtros o referencias de dominio sigan interpretando bien el tráfico. Registra el momento del cambio para que los futuros reportes tengan contexto.
El correo merece una revisión separada. Si la marca cambia también sus direcciones, habrá decisiones sobre buzones, alias y comunicaciones. Si el correo permanece en el dominio anterior, conserva los registros y servicios necesarios. Un proyecto web no debería cancelar por accidente una infraestructura que todavía utiliza el equipo.
Cómo preparar el lanzamiento para que todos sepan qué comprobar
Divide el plan en preparación, corte y seguimiento. Para cada fase escribe responsable, requisito de entrada y evidencia de salida. La preparación termina cuando el destino está listo y el mapa aprobado; el corte comienza cuando existe una ventana acordada y una copia recuperable.
El día del cambio, utiliza una lista pequeña de comprobaciones críticas: portada, servicios prioritarios, contacto, compra cuando corresponda, rutas antiguas de mayor valor y acceso móvil. Después amplía a la muestra completa. Así el equipo distingue un bloqueo que exige detenerse de un detalle que puede corregirse sin interrumpir la operación.
Define quién tiene capacidad para cambiar DNS, redirecciones y configuración de aplicación. Si esas personas no estarán disponibles, resuelve antes el acceso autorizado. Tener una lista perfecta y depender de una cuenta inaccesible durante el lanzamiento puede prolongar una incidencia evitable.
Reserva un registro de incidentes con hora, URL, síntoma y solución aplicada. Las conversaciones ayudan a coordinarse, pero no sustituyen ese registro. Una corrección de emergencia que nadie documenta puede explicar después por qué dos secciones quedaron con comportamientos distintos.
Qué puedes prometer y qué necesitas observar
El equipo puede comprometerse con inventario, implementación, pruebas y seguimiento definidos. Las posiciones dependen además de cómo se procesen las señales y de un entorno competitivo que sigue cambiando. Separa esos planos al aceptar el proyecto.
Comprueba primero que las páginas importantes existen y se sirven correctamente. Después observa descubrimiento, indexación y rendimiento por familias de consultas. Conserva la línea base anterior y evita comparar una semana de alta demanda con otra de baja actividad sin explicar esa diferencia.
Si detectas una pérdida concentrada, utiliza el mapa para revisar esa familia antes de rehacer toda la migración. Puede existir una excepción mal resuelta, contenido omitido o una señal inconsistente. El valor del trabajo previo aparece precisamente cuando necesitas diagnosticar con rapidez y recuperar una decisión concreta.
7. Define cuándo considerar terminado el proyecto
El lanzamiento termina cuando el sitio funciona; la migración necesita seguimiento. Conserva una lista de URLs críticas y verifica su respuesta, contenido y destino. Compara consultas y páginas entre periodos equivalentes, sin sumar propiedades de manera que dupliques registros.
Documenta incidencias y correcciones. Si una sección cae y otra se mantiene, analiza la sección afectada antes de cambiar todo el sitio. Evita prometer que el posicionamiento será idéntico al día siguiente: Google puede necesitar tiempo para procesar el traslado y los resultados pueden fluctuar.
Antes de fijar el día del cambio, prepara tus URL principales y sus destinos. Podemos revisar el mapa y el plan de lanzamiento contigo.
Fuentes y documentación consultada
Documentación consultada el 27 de septiembre de 2026.
Preguntas frecuentes sobre el cambio de dominio y el SEO
¿Cambiar el nombre del dominio siempre hace perder SEO?
No necesariamente, pero puede haber fluctuaciones y errores de implementación. El objetivo es reducir riesgos y conservar señales útiles, no prometer posiciones invariables.
¿Cuánto tiempo debo conservar el dominio anterior?
Google recomienda mantener las redirecciones al menos un año. Mantener el dominio más tiempo puede ser útil si siguen existiendo enlaces y visitas a las direcciones antiguas.
¿Basta con cambiar la dirección en WordPress?
No. También debes revisar referencias guardadas, contenido, redirecciones, certificados, enlaces y herramientas conectadas.
¿Puedo cambiar diseño y dominio al mismo tiempo?
Puedes hacerlo, pero aumenta la complejidad y dificulta aislar problemas. Separa cambios cuando sea viable y documenta las correspondencias.
