Migración SEO para rediseño de sitio, cambio de dominio o migración de CMS

¿Qué cubre una migración SEO?

Una migración SEO coordina los cambios técnicos y de contenido necesarios para mover un sitio sin dejar atrás páginas importantes. Aplica a rediseños, cambios de dominio, cambios de marca y migraciones de CMS.

La primera decisión es el alcance: enumera cada hostname, versión de idioma y grupo de páginas afectado. Luego identifica las páginas con tráfico de búsqueda, enlaces entrantes o valor comercial. Estas son prioridades de migración, no páginas para eliminar sin cuidado.

El Launch Spec registra el tipo de migración, responsables, secuencia de lanzamiento, fuentes de URLs y verificaciones de aceptación. También anota lo que no cambia, para que el equipo pueda separar los problemas de migración del trabajo de rediseño no relacionado. Si las menciones de asistentes de IA son importantes, incluye las URLs actualmente citadas y las páginas de referencia importantes en la línea base. Esto le da al equipo un registro para comparar después del lanzamiento.

Para un trabajo más amplio de búsqueda con IA más allá de la migración, consulta visibilidad en búsqueda con IA y nuestra auditoría GEO.

¿Cómo se deben mapear las URLs y redirecciones?

Un mapa de URLs de migración debe dar a cada URL antigua conservada un destino claro, y a cada URL eliminada una disposición deliberada. Constrúyelo antes de implementar las reglas de redirección.

• Exporta las URLs actuales desde un rastreo del sitio y los datos de analítica o búsqueda disponibles.
• Empareja cada página antigua con la página nueva equivalente más cercana, no automáticamente con la página de inicio.
• Marca las páginas sin sucesor para revisión; decide si conservarlas, consolidarlas o retirarlas.
• Verifica que los enlaces internos, las referencias canónicas, las alternativas de idioma y la navegación usen las URLs finales.
• Prueba rutas representativas, incluyendo páginas anidadas y patrones de URL cambiados, en staging.

Mantén el mapeo en un archivo compartido con URL de origen, URL de destino, responsable de la página y estado de revisión. Señala cadenas de redirección, bucles, barras inclinadas inconsistentes y versiones mixtas de protocolo o hostname antes del lanzamiento. Una redirección no sustituye a un destino relevante: si la nueva página responde a una necesidad diferente, revisa el mapeo o el plan de contenido.

AEOTech verifica el mapa contra la línea base de rastreo durante la Revisión del Spec, luego registra las correcciones en el Run Log. Esto deja claro qué URLs han sido revisadas y cuáles aún necesitan una decisión del responsable. Si también estás reconstruyendo las señales técnicas de búsqueda con IA, coordina la migración con AEO técnico en lugar de tratarlo como un lanzamiento separado.

¿Qué debe pasar antes de que el nuevo sitio esté en vivo?

Staging es el lugar para confirmar que el nuevo sitio está listo para recibir tráfico y que las señales clave de página se han transferido. La revisión debe usar plantillas representativas así como URLs prioritarias individuales.

Separa los controles temporales de staging de los ajustes destinados a producción. Confirma quién los eliminará o reemplazará en el lanzamiento, y agrega esa tarea a la lista de verificación de lanzamiento. Compara las plantillas de página antiguas y nuevas en busca de contenido faltante, encabezados, navegación y referencias importantes; una redirección técnicamente válida no puede restaurar información omitida en la página de destino.

Documentamos las verificaciones y los elementos abiertos en el Launch Spec, con un responsable designado para cada problema no resuelto. Si tu equipo mantiene archivos destinados a guiar a los rastreadores de IA, trátalos como una decisión técnica separada y revisa el trabajo con llms.txt y rastreadores junto con las tareas de migración. No uses un archivo nuevo como sustituto de redirecciones sólidas, páginas accesibles o contenido preciso.

¿Cómo monitoreamos una migración después del lanzamiento?

El monitoreo posterior al lanzamiento compara el sitio en vivo con la línea base previa a la migración y convierte los problemas observados en correcciones asignadas. El propósito es detectar y corregir problemas mientras el contexto del lanzamiento aún está claro.

1. Confirma que las páginas prioritarias y las rutas principales del sitio carguen en el dominio de producción.
2. Vuelve a verificar los destinos de las redirecciones y los grupos de URLs listados en el mapa de migración.
3. Revisa las señales de rastreo y tráfico contra la línea base registrada.
4. Registra cambios inesperados, URLs afectadas, evidencia y la persona responsable de la corrección.
5. Vuelve a verificar los elementos resueltos y registra el resultado en el Readout.

Las fluctuaciones temporales después del lanzamiento son normales, por lo que la revisión debe centrarse en patrones y errores concretos en lugar de una sola instantánea. Por ejemplo, una caída en una plantilla requiere una investigación diferente a un error de redirección limitado a un pequeño grupo de URLs. El Run Log mantiene esos hallazgos vinculados a páginas y correcciones específicas.

El Readout resume las verificaciones completadas, los problemas abiertos y las próximas acciones en lenguaje sencillo para los responsables de marketing y técnicos. Si necesitas trabajo continuo de visibilidad después del período de migración, compara este proyecto con monitoreo de visibilidad en IA. Para un plan de contenido más amplio, consulta contenido para respuestas de IA.

¿Qué puede cambiar después de un relanzamiento del sitio?

Un plan de migración puede controlar el trabajo de implementación y verificación, pero no puede controlar cómo las plataformas procesan el sitio modificado. Los buscadores deciden cuándo volver a rastrear y reevaluar las URLs, y los asistentes de IA eligen qué fuentes citar; ni el momento ni las citas continuas están bajo nuestro control.

Usa el Readout para separar la entrega de los resultados de la plataforma. Debe mostrar qué redirecciones y señales de página se verificaron, qué correcciones se completaron y qué queda abierto. Esa evidencia permite a tu equipo actuar sobre un problema técnico identificable en lugar de adivinar a partir de un cambio amplio de visibilidad.

Para proyectos con un cambio de marca importante, registra los nuevos nombres de organización y producto de manera consistente en todo el sitio y los materiales de apoyo. Nuestro trabajo de entidad y grafo de conocimiento puede abordar esa necesidad separada. Para un cambio de dominio con una reescritura sustancial de contenido, incluye tanto el mapa de URLs como la lista de cambios de página en la revisión; la cobertura de redirecciones por sí sola no describirá lo que cambió para los visitantes.

Para comenzar, envía a AEOTech el dominio actual, el dominio planificado o la migración de CMS, una exportación de URLs antiguas, acceso a staging y tu ventana de lanzamiento prevista. Revisaremos los datos, definiremos las verificaciones en un Launch Spec y confirmaremos el alcance de la migración antes de que comience la implementación.

Precios

Precios iniciales en USD. Paquetes a medida y descuentos por volumen bajo solicitud. Pago en USDT, USDC, BTC, ETH, SOL, TON o con el token de tu proyecto.

Cómo trabajamos

1. Recopilar los datos de migraciónComparte el sitio actual, los cambios planificados, la exportación de URLs, el acceso a analítica y la ventana de lanzamiento. Confirmamos los dominios, grupos de páginas y responsables afectados.
2. Establecer la línea baseRastreamos el sitio actual y registramos las señales de tráfico y URLs disponibles para comparación. Las páginas prioritarias y las menciones conocidas de IA se incluyen cuando se proporcionan.
3. Crear y revisar el mapaEmparejamos las URLs antiguas con los destinos previstos y revisamos los requisitos de redirecciones, metadatos y datos estructurados en el Launch Spec.
4. Verificar staging y lanzamientoProbamos los grupos de páginas acordados y registramos las acciones pendientes antes del lanzamiento. En el lanzamiento, el equipo sigue la lista de verificación e informa los problemas a través del Run Log.
5. Monitorear e informarComparamos las verificaciones posteriores al lanzamiento con la línea base, rastreamos las correcciones y entregamos un Readout con el trabajo completado y las próximas acciones.