Migración SEO en divisiones de sitios y carve-outs

TL;DR — Una división de sitio separa el sitio web de una empresa en dos. La parte difícil no es escribir redirecciones. Es decidir quién es propietario de cada página, dominio, cuenta, imagen, descarga, enlace y dato histórico. Conviene mantener sin cambios las URL adecuadas siempre que sea posible. Cuando una página se traslada de verdad, su URL antigua debe redirigirse a la página nueva equivalente. Si no hay reemplazo, debe devolverse un 404 o un 410 real. Deben probarse ambas carteras de sitios nuevas, porque un carve-out puede romper el sitio del vendedor con la misma facilidad que el del comprador.

Qué es una división de sitio o carve-out

Una división de sitio es una migración en la que parte de un sitio web pasa a ser una cartera de sitios independiente. Suele producirse tras una desinversión, una escisión, la venta de un producto, una separación regional o la disolución de una empresa conjunta.

Una migración de dominio normal es en su mayor parte de uno a uno: el sitio antiguo se traslada al sitio nuevo. Un carve-out es de uno a muchos. Algunas páginas se quedan con el vendedor, otras pasan al comprador, otras se copian temporalmente bajo licencia, otras se retiran, y los sistemas compartidos tienen que seguir funcionando mientras cambia la propiedad.

Eso genera tres tareas:

1. Decidir la propiedad. ¿Quién controla cada dominio, URL, activo de contenido, cuenta y servicio después de la transacción?
2. Preservar el significado. ¿La nueva página del comprador sustituye realmente a la página antigua del vendedor para el usuario?
3. Demostrar la independencia. ¿Puede cada parte rastrear, publicar, medir, proteger y operar su cartera de sitios cuando terminen los servicios de transición?

La regla de las redirecciones

Una URL trasladada solo debe redirigirse cuando el destino sea su reemplazo real. Una página de producto vendida junto con el negocio normalmente puede redirigirse al mismo producto en el sitio del comprador. Una página corporativa de empleo que conserva el vendedor no debería redirigirse a la página de inicio del comprador solo porque tenga enlaces.

Google desaconseja enviar muchas URL antiguas a un único destino irrelevante, porque eso puede tratarse como un error soft 404. Recomienda redirecciones permanentes del lado del servidor, como 301 y 308, para los traslados permanentes. Véase la guía de traslado de sitios de Google.

Preparación antes de la fecha de separación

La cartera de sitios debe inventariarse mientras aún existan las personas, los sistemas y los permisos. Como mínimo, deben registrarse:

• dominios, subdominios, dominios antiguos, DNS, certificados, alojamiento y reglas de CDN;
• todas las URL indexables, además de imágenes, videos, PDF, scripts y feeds;
• Search Console, analítica, gestión de etiquetas, publicidad, consentimiento y perfiles de empresa;
• propietarios de contenido, licencias, autores, marcas, datos de producto y archivos fuente;
  • redirecciones, etiquetas canónicas, hreflang, datos estructurados, mapas del sitio y reglas de robots;
• proveedores, API, autenticación, búsqueda, formularios y repositorios compartidos.

El contrato y los asesores jurídicos determinan la propiedad legal. El trabajo del equipo de SEO consiste en exponer los casos en los que una separación propuesta depende de un activo o un derecho que no se ha asignado.

Cómo se ve el éxito

Después del lanzamiento, las páginas trasladadas del comprador deberían ser rastreables, indexables, enlazadas internamente, medibles y mapeadas desde sus URL antiguas. Las páginas que conserva el vendedor deberían seguir funcionando. Los datos históricos y los accesos deberían conservarse de forma adecuada, mientras que las antiguas partes pierden el acceso operativo según el calendario acordado.

Eso es un carve-out exitoso. Que dos sitios se pongan en marcha es solo la parte visible.

TL;DR — Un carve-out debe tratarse como un programa de separación de activos con una migración SEO incluida. Se necesita una matriz de derechos que abarque URL, contenido, dominios, datos, enlaces, cuentas, infraestructura y personas. A cada URL heredada debe asignársele una disposición explícita: conservar, trasladar, consolidar, duplicar temporalmente con derechos documentados o retirar. Solo deben mapearse los traslados equivalentes; los activos compartidos deben preservarse o sus referencias deben sustituirse, la medición debe separarse sin descartar el historial y las transiciones deben secuenciarse según las dependencias de DNS, redirecciones, autenticación, consentimiento y servicios de transición. Ambas carteras deben monitorizarse por cohorte de URL. Una ganancia del lado del comprador no justifica un daño del lado del vendedor.

Definición del perímetro de la separación

El punto de partida es el perímetro de la transacción, que después debe traducirse a un perímetro digital. La entidad jurídica, la línea de producto, la marca, la geografía y el contrato con el cliente pueden trazar el límite de forma distinta cada uno. No debe darse por hecho que una carpeta de URL sea la respuesta definitiva.

Se debe crear una matriz de derechos con una fila por activo y estos campos:

El acuerdo de servicios de transición (TSA, por sus siglas en inglés) es el término de la operación que conviene aprender. Define los servicios que una de las partes sigue prestando temporalmente después del cierre. Para el SEO, un TSA puede cubrir el alojamiento de redirecciones, el DNS, un CMS, una CDN de imágenes, exportaciones de analítica, herramientas de consentimiento o personal que sabe cómo funciona el sistema de publicación. A cada dependencia se le debe asignar un responsable, un nivel de servicio, una fecha de finalización, una prueba de salida y un plan alternativo.

Inventario de URL con evidencia completa

Se deben combinar varias fuentes en lugar de confiar solo en el mapa del sitio:

• rastreos de producción y exportaciones del CMS o de la base de datos;
• mapas del sitio XML, registros del servidor y de la CDN, páginas de destino de analítica y páginas de Search Console;
• URL enlazadas externamente, páginas de destino de pago, feeds y perfiles de empresa;
• imágenes, videos, PDF, archivos descargables, JavaScript, CSS, endpoints de API y redirecciones antiguas.

Google indica explícitamente a los propietarios de sitios que incluyan los recursos incrustados en un traslado y que utilicen mapas del sitio, registros, analítica, datos del CMS e informes de enlaces para identificar las URL importantes. La documentación actual enumera esas fuentes.

A cada URL debe asignársele una única disposición:

• Conservar: permanece en el vendedor y mantiene su URL.
• Trasladar: se transfiere a una página equivalente del comprador.
• Consolidar: varias páginas se convierten realmente en un único reemplazo completo.
• Uso dual temporal: aparece en ambas carteras de sitios con derechos documentados, con un propietario y una fecha de caducidad.
• Retirar: no tiene un reemplazo útil y devuelve 404/410.
• En espera: no puede lanzarse hasta que se resuelva la propiedad, los derechos o el destino.

Sin celdas en blanco. «Ya lo decidiremos después del lanzamiento» es una decisión de aceptar un fallo no gestionado.

Diseño de los mapeos en torno a la equivalencia para las personas

El comprador adquiere un negocio, no automáticamente todas las señales de búsqueda asociadas al vendedor. Una redirección se justifica cuando el destino satisface esencialmente la misma intención del usuario y da continuidad al mismo tema, producto o servicio.

Los mapeos deben revisarse con los responsables de contenido, producto, asuntos jurídicos y marca. Cada fila debe puntuarse:

• sucesor exacto;
• consolidado pero equivalente;
• incierto y requiere revisión manual;
• sin equivalente, devolver 404/410;
• prohibido porque el activo o la reclamación no se transfiere.

Las cadenas deben evitarse resolviendo las reglas antiguas directamente al destino final. Google afirma que puede seguir cadenas largas, pero recomienda redirecciones directas y mantener bajas las cadenas inevitables, idealmente no más de tres y menos de cinco. Las redirecciones permanentes deben mantenerse durante al menos un año, y más tiempo cuando sea posible. Google documenta ambos puntos.

Desenrede los activos y servicios compartidos

Las dependencias compartidas son donde los carve-outs se complican.

Hosts de recursos

Una página trasladada puede seguir cargando imágenes desde la CDN del vendedor, fuentes desde un dominio corporativo, PDF desde un DAM compartido o JavaScript desde un host de la empresa matriz. Las solicitudes deben inventariarse a partir de rastreos con renderizado y de los registros del navegador y de red. Para cada dependencia, se debe elegir entre transferir, copiar, alojamiento con licencia estable o sustitución. Las referencias deben actualizarse y deben probarse la caché, CORS, las reglas de robots, las firmas, las restricciones de hotlinking y la caducidad.

Contenido y datos de producto

El contenido de origen debe separarse de las páginas renderizadas. Las descripciones de producto, las especificaciones, las reseñas, las biografías de los autores, la memoria de localización y los campos de datos estructurados pueden proceder de sistemas ajenos al CMS. Los especialistas jurídicos y de datos determinan si cada uno puede transferirse. No deben resolverse derechos poco claros copiándolo todo.

Identidad y transacciones

Los formularios, el inicio de sesión, la recuperación de cuentas, el proceso de compra, las suscripciones y los portales de soporte pueden cruzar el límite de la separación. Deben probarse los recorridos de las personas y los estados indexables que los rodean. La visibilidad en buscadores no es una victoria si la página envía a un cliente a un flujo de cuenta que la nueva empresa no puede operar.

Separación segura de Search Console y la medición

El historial debe preservarse antes de cambiar los accesos. Los datos de referencia deben exportarse por cohorte de URL, consulta, país, dispositivo y apariencia en la búsqueda. Deben registrarse el alcance de la propiedad y la zona horaria. Debe mantenerse un archivo de solo lectura conforme a las reglas de datos de la transacción.

Para Search Console:

1. Inventariar las propiedades de tipo Domain y URL-prefix, las personas usuarias, los propietarios y los métodos de verificación.
2. Verificar las propiedades de destino del comprador antes del lanzamiento.
3. Preservar la verificación del vendedor necesaria para monitorizar las URL antiguas y las redirecciones.
4. Transferir o establecer la titularidad del comprador mediante controles aprobados.
5. Revocar el acceso anterior solo después de superar las pruebas de monitorización y traspaso acordadas.

Google distingue entre propietarios, usuarios con permisos totales y usuarios con permisos restringidos. Los tokens de verificación pueden otorgar control, por lo que el diseño de accesos corresponde a seguridad y no a una hoja de cálculo de SEO compartida. Google documenta los permisos de Search Console.

En analítica y etiquetado, debe definirse qué parte puede conservar datos históricos a nivel de usuario o de carácter comercial. A menudo, la base de referencia más segura para el SEO es una exportación agregada aprobada más nuevas propiedades de destino, y no copiar una cuenta entera. Deben reconstruirse los eventos, el consentimiento y la configuración entre dominios, las referencias, las reglas de canales y las uniones con resultados de negocio; después verifíquelos con transacciones de prueba.

Secuenciación de la transición

Se deben utilizar olas basadas en dependencias, no en recuentos arbitrarios de URL:

1. Plano de control: registro de dominios, DNS, certificados, CDN, alojamiento, secretos, titularidad de las cuentas y monitorización.
2. Preparación del destino: plantillas, contenido, recursos, accesibilidad, analítica, consentimiento, robots, etiquetas canónicas, hreflang, datos estructurados y mapas del sitio.
3. Cohorte piloto: una sección coherente y de menor volatilidad cuyo rendimiento pueda medirse de forma independiente.
4. Contenido principal: cohortes de producto, categoría, soporte y editorial de alto valor.
5. Cola larga y legado: páginas huérfanas, archivos, redirecciones antiguas, perfiles e integraciones.
6. Salida del TSA: sustituir o terminar cada dependencia compartida y revocar los accesos.

Google recomienda dividir los traslados grandes cuando resulte útil, a la vez que advierte de que un piloto puede no ser representativo de un traslado de todo el sitio. También recomienda cambiar una variable importante cada vez y lanzar en momentos de menor tráfico cuando sea posible. Esas expectativas figuran en su guía de traslado de sitios.

Puertas de lanzamiento

Una cohorte no debe lanzarse hasta que:

• la propiedad y los derechos tengan un estado documentado;
• las páginas de destino devuelvan el estado previsto y rendericen su contenido principal;
• los robots y las directivas meta de producción permitan el rastreo y la indexación previstos;
• las etiquetas canónicas, hreflang, los datos estructurados, los enlaces internos y los mapas del sitio usen las URL finales;
• las reglas de redirección superen pruebas exactas, representativas y adversariales;
• la analítica, el consentimiento, las conversiones y la recopilación de registros superen recorridos de prueba;
• la capacidad, la monitorización, la titularidad de los incidentes, la reversión y la comunicación estén listas;
• la cartera de sitios conservada por el vendedor supere su propia batería de pruebas de regresión.

Seguimiento por cohortes, no por totales agregados

Deben crearse cohortes fijas antes del lanzamiento: URL conservadas del vendedor, URL trasladadas del comprador, URL retiradas, URL de transición compartida y URL de control que no deberían cambiar. Compare a los 7, 14, 30 y 90 días, teniendo en cuenta la estacionalidad y las publicaciones no relacionadas.

Se debe hacer seguimiento de:

• las solicitudes a URL antiguas y los resultados de las redirecciones;
• el rastreo, la indexación, las impresiones, los clics, las posiciones y las conversiones de las URL nuevas;
• las regresiones en las páginas conservadas del vendedor;
• los errores de servidor, la latencia, el volumen de rastreo y el comportamiento de la caché;
• la selección de canónicas, la reciprocidad de hreflang, la elegibilidad para resultados enriquecidos y los enlaces internos;
• las dependencias del TSA, las credenciales que caducan, la renovación de certificados y los activos sin resolver.

No debe prometerse una fecha fija de recuperación. Google afirma que los traslados importantes pueden fluctuar mientras las URL se vuelven a rastrear y a indexar, y que la finalización se produce URL por URL. Los sitios grandes pueden tardar más. El patrón de transición esperado debe utilizarse como contexto, no como excusa para una implementación defectuosa.

Reflexiones finales

El archivo de redirecciones no es el plan del carve-out. El plan es una respuesta demostrable a quién es propietario de cada activo, qué debería encontrar el usuario, cómo opera cada empresa de forma independiente y cuándo termina cada dependencia temporal.

Resumen con IA

• Tratar el carve-out como una cartera de sitios que se convierte en dos, no como un cambio de dominio normal.
• Inventariar URL, derechos, dominios, cuentas, datos, infraestructura, enlaces y personas.
• Asignar a cada URL una disposición: conservar, trasladar, consolidar, uso dual temporal, retirar o en espera.
• Redirigir solo a un sucesor genuino; usar 404/410 cuando no exista ninguno.
• Probar los recursos y servicios ajenos al CMS, especialmente CDN, DAM, formularios, identidad, datos de producto, consentimiento y analítica.
• Preservar el historial con el alcance adecuado, establecer la nueva titularidad y revocar los accesos antiguos según un calendario acordado.
• Lanzar por cohorte de dependencia y realizar pruebas de regresión de la cartera de sitios conservada por el vendedor.
• Monitorizar por separado las cohortes de comprador, vendedor, retiradas, de transición y de control sin cambios.

Qué establece la guía oficial

• Google: traslados de sitios con cambios de URL: mapeo, redirecciones permanentes, recursos, entorno de pruebas, mapas del sitio, monitorización y resolución de problemas.
• Google: redirecciones y la Búsqueda: métodos de redirección admitidos e interpretación de las señales.
• Google: canonicalización: señales canónicas y por qué las redirecciones son más fuertes que las anotaciones por sí solas.
• Google: versiones localizadas: hreflang recíproco e implementaciones entre dominios.
• Google: usuarios y permisos de Search Console: titularidad, niveles de usuario y controles de verificación.

Estas fuentes explican el comportamiento de los sistemas de búsqueda. No deciden cuestiones de propiedad, licencias, privacidad, empleo, fiscalidad ni los términos de la transacción. Esas decisiones deben derivarse a especialistas.

Citas de la fuente

• “Split your move into smaller steps, if that makes sense for your site.” (traducción) «El traslado puede dividirse en pasos más pequeños si eso tiene sentido para el sitio.» — Google Search Central. Ir a la cita

Lista de verificación del carve-out

Antes del diseño

• Congelar el perímetro de la transacción y nombrar los activos sin resolver.
• Inventariar dominios, URL, archivos, derechos, cuentas, sistemas, proveedores y personas.
• Exportar rastreos, mapeos, redirecciones, GSC, analítica, registros, enlaces y posiciones.
• Identificar cada dependencia compartida y el TSA propuesto.
• Crear cohortes de URL de vendedor, comprador, retiradas, de transición y de control.

Antes del lanzamiento

• Asignar una disposición y un responsable de la evidencia a cada URL.
• Aprobar cada redirección por equivalencia para las personas y por derechos.
• Validar recursos, formularios, autenticación, consentimiento, analítica y conversiones.
• Verificar el rastreo en producción, las etiquetas canónicas, hreflang, los datos estructurados, los enlaces internos y los mapas del sitio.
• Probar la reversión y las regresiones del lado del vendedor.
• Asignar personal a la monitorización y la respuesta a incidentes.

Después del lanzamiento

• Rastrear todas las URL antiguas y verificar el destino final.
• Inspeccionar las URL importantes en Search Console y comparar las cohortes de indexación.
• Monitorizar registros, errores, latencia, tráfico, posiciones y resultados en ambas carteras de sitios.
• Resolver las dependencias del TSA antes de sus fechas de salida.
• Revocar los accesos y rotar los secretos cuando se superen las puertas de traspaso.

ROME: rights (derechos), ownership (titularidad), meaning (significado), execution (ejecución)

Se utilizan cuatro puertas para cada activo:

1. Derechos: ¿Puede la empresa de destino usarlo, modificarlo, alojarlo y redirigirlo?
2. Titularidad: ¿Quién controla el dominio, la cuenta, el código, el contenido y la renovación?
3. Significado: ¿Es el destino propuesto genuinamente equivalente para las personas?
4. Ejecución: ¿Puede el destino renderizarlo, medirlo, protegerlo y mantenerlo de forma independiente?

Una fila que no supere alguna de las puertas no está lista para migrar.

Decisión sobre una URL heredada

SOP del día del lanzamiento

1. Confirmar la versión firmada del mapa de URL y sus responsables en el registro de cambios.
2. Hacer una instantánea del estado de DNS, CDN, redirecciones, robots, mapa del sitio, analítica y certificados.
3. Publicar la cohorte de destino y ejecutar pruebas de humo antes de activar las redirecciones.
4. Activar las redirecciones directas; rastrear URL exactas, muestreadas, sin correspondencia, con parámetros y de recursos.
5. Validar los recorridos clave de las personas y la medición en tiempo real en las carteras del comprador y del vendedor.
6. Enviar los nuevos mapas del sitio e inspeccionar URL representativas de alto valor.
7. Publicar la actualización de estado con incidentes, responsables, siguiente punto de control y estado de reversión.
8. Mantener al equipo disponible hasta que se superen la ventana de observación y las pruebas de negocio.

Formas habituales en que fracasan los carve-outs

• La carpeta equivale a la propiedad: el límite legal y operativo rara vez coincide con un único directorio ordenado.
• La lógica del derecho por el tráfico: que el tráfico sea valioso no demuestra que el comprador sea propietario de la página ni que pueda recibir su redirección.
• Todo a la nueva página de inicio: las redirecciones irrelevantes confunden a los personas y pueden tratarse como errores soft 404s.
• Copiar ahora y decidir después: la duplicación temporal se convierte en contenido permanente y sin gobierno.
• QA solo del comprador: los cambios en el código compartido y en las redirecciones rompen el sitio del vendedor sin que se note.
• El TSA como arquitectura: los servicios temporales caducan. Cada dependencia necesita una salida.
• Eliminar los accesos antiguos de inmediato: la monitorización y el histórico desaparecen antes del traspaso.
• No revocar nunca los accesos antiguos: las partes anteriores conservan el control una vez pasada la ventana aprobada.

Herramientas para este trabajo

• SEO Migration Planner & Validator: permite revisar mapas, redirecciones desplegadas, resultados de las URL antiguas, diferencias entre mapas del sitio e historial archivado.
• Redirect Map Builder: permite proponer y revisar manualmente los mapeos de URL, conservar las filas sin correspondencia, aplanar las cadenas y exportar las reglas.
• Rastreador más rastreo con navegador y renderizado: inventariar las URL y las solicitudes de recursos compartidos.
• Registros de servidor y de CDN: demostrar las solicitudes de bots, los códigos de estado, las redirecciones y el tráfico conservado.
• Exportaciones de Search Console y de analítica: establecer cohortes previas al cierre y monitorizar la transferencia.
• Inventarios de DNS, certificados, dependencias y secretos: demostrar la separación operativa.

Pruebas que deben superarse

Recursos

Trabajo verificado de Patrick

• The Role of SEO in Mergers and Acquisitions: due diligence, la decisión de fusionar, la integración por fases, la demanda de la marca antigua y la monitorización posterior a la adquisición.
• A Website Migration Takes More Than a Checklist: el proceso de Patrick de planificación, línea base, cambio de URL, pruebas y monitorización, incluidas las divisiones de sitios.

Documentación oficial

• Documentación de Google sobre traslados de sitios: inventario de URL, mapeo, redirecciones permanentes, traslados por fases, monitorización y resolución de problemas.
• El modelo de permisos de Search Console de Google: propietarios, usuarios, métodos de verificación y eliminación de tokens.
• Bing Webmaster Guidelines: guía actual sobre redirecciones, rastreo/renderizado y eliminaciones.

Del resto del sector

• KPMG’s Digital Separation Blueprint: contexto de modelo operativo y de servicios de transición para un carve-out; no es política de SEO ni asesoramiento jurídico.
• Caso de estudio de 9thCO sobre migración web en operaciones de M&A: un ejemplo de consolidación multidominio reportado por el proveedor.
• Guía de migración de sitios de Search Engine Land: cobertura de planificación, consolidación, lanzamiento y post-lanzamiento.
• Tutorial de auditoría de redirecciones de Screaming Frog: un flujo de trabajo recuperable para probar a escala el conjunto de URL antiguas.

Relacionado en este sitio: Site Migrations, Website Migration Checklist y SEO Due Diligence for M&A.

Prueba de conocimientos

Registro de cambios