curl -sS -D - -o /dev/null "$OLD_URL"

Siga las redirecciones y consulte las cabeceras de cada respuesta

curl -sS -L -D - -o /dev/null "$OLD_URL"

Muestre el estado final y la dirección final para registrar el resultado

curl -sS -L -o /dev/null
-w 'estado=%{http_code} destino_final=%{url_effective}\n' "$OLD_URL"

El registro de validación debe conservar la primera respuesta, la dirección de destino, la respuesta final y el contenido de la página. La persona responsable de tecnología debe confirmar el tipo de regla de redirección permanente adecuado para el entorno de despliegue real; no basta con concluir que en el navegador «parece que redirige».

Considere bloqueantes para el lanzamiento las cadenas de redirecciones innecesarias, las redirecciones de vuelta a la dirección antigua, los destinos en dominios de prueba y las páginas de destino inexistentes. Preste especial atención a no comprobar únicamente la regla de la página de inicio y dejar fuera los artículos y las páginas de detalle de producto.

## 5. ¿Cómo validar conjuntamente el contenido de las páginas y la etiqueta canonical?

Que una dirección se abra es solo el requisito mínimo. Se recomienda seleccionar páginas representativas de cada plantilla y comprobar que estén completos el título, el encabezado principal, el cuerpo del contenido, los textos alternativos de las imágenes, los enlaces internos y los botones de consulta, para evitar que la importación deje únicamente la estructura vacía de las páginas.

La etiqueta canonical puede incluirse en la comprobación de las direcciones canónicas, pero no debe considerarse un sustituto de la resolución de todos los problemas de migración. Durante la validación, registre la dirección canónica declarada por cada página y confirme que coincide con la página de producción definida en el proyecto; busque especialmente referencias que sigan apuntando al dominio antiguo, a un dominio de previsualización o a una página no relacionada.

Los sitios multilingües también deben comprobar la correspondencia entre las versiones de cada idioma. Una página de producto en chino no debería enlazar a la página de inicio en inglés como consecuencia de una sustitución masiva. Es necesario probar mediante clics reales el selector de idioma, los enlaces del pie de página y los enlaces de contenido recomendado incluidos en el cuerpo.

Compare también la información esencial antes y después de la migración. Las condiciones de precios, el alcance del servicio, la información que respalda los casos de éxito y los datos de contacto no deben desaparecer accidentalmente al cambiar de plantilla. En las páginas de las que depende el equipo comercial, conviene que la persona responsable del negocio participe en la validación, en lugar de limitarse a una revisión de las respuestas técnicas por parte de desarrollo.

## 6. ¿Qué revisar en el mapa del sitio? Compárelo primero con la lista de páginas de producción

Se recomienda elaborar primero una «lista de páginas de producción que se prevé publicar y hacer accesibles para su descubrimiento en buscadores» y compararla después con el mapa del sitio generado. No dé por terminada la revisión por el mero hecho de que «ya se ha generado un archivo XML».

Compruebe especialmente lo siguiente:

- Si las direcciones del mapa pertenecen al dominio y al entorno de producción.
- Si las nuevas rutas posteriores a la migración se han incluido según lo previsto.
- Si se han incorporado direcciones eliminadas, que todavía redirigen o que aún no están listas para hacerse públicas.
- Si las páginas incluidas en el mapa coinciden con las direcciones canónicas que declaran.
- Si faltan categorías completas, como directorios multilingües, páginas de paginación de artículos o categorías de productos.
- Si está claramente definida la persona responsable de actualizar el mapa y volver a publicarlo.

Si cambia el número de entradas del mapa, investigue de dónde procede la diferencia: ¿se debe a una fusión planificada de contenidos o a omisiones en la importación o errores en los criterios de filtrado? Conviene guardar copias de los archivos anteriores y posteriores a la migración para poder compararlos elemento por elemento.

El mapa del sitio es solo una parte de la validación de la migración. Después de enviarlo, todavía hay que comprobar el acceso, el contenido y la evolución del estado de páginas concretas; el envío no permite prometer resultados de indexación, posiciones o tráfico.

## 7. ¿Qué comprobar en Search Console antes y después del lanzamiento?

![7. ¿Qué comprobar en Search Console antes y después del lanzamiento?](https://we0-frontend.oss-cn-beijing.aliyuncs.com/growth-covers/3ae5ab5b-404e-4812-9473-4305e47b4bb6.png)

Antes del lanzamiento, confirme que el equipo puede acceder a las propiedades del sitio correspondientes y que las personas responsables no perderán sus permisos cuando deje de intervenir el proveedor anterior. Registre las páginas de destino importantes, las consultas de búsqueda, los clics y las impresiones previos a la migración, junto con la fecha de observación, para disponer de un punto de partida para las comparaciones posteriores.

Después del lanzamiento, se recomienda comprobar y registrar lo siguiente en este orden:

1. **Propiedad y permisos**: si la propiedad que se está consultando corresponde al sitio implicado en la migración y si las personas responsables siguen teniendo acceso.
2. **URL representativas**: revise el estado de rastreo e indexación y la información de la dirección canónica de las páginas clave, distinguiendo los registros históricos de los cambios posteriores.
3. **Mapas del sitio**: compruebe qué se ha enviado, el estado de procesamiento y los avisos relacionados; si aparece una incidencia, vuelva al archivo real para investigarla.
4. **Problemas de las páginas**: organice las incidencias por directorio y plantilla; no se centre únicamente en las cifras totales.
5. **Rendimiento**: compare las consultas, los clics y las impresiones de las páginas antiguas junto con sus nuevas páginas correspondientes, no solo los de la página de inicio.

Si también cambia el dominio, confirme por separado si el procedimiento de cambio de dirección es aplicable a su caso. No confunda un cambio de herramienta de creación web dentro del mismo dominio con una migración entre dominios.

Cuando detecte un problema, reúna en una misma incidencia la dirección de la página, el aviso observado, la fecha y hora de observación y el resultado de la nueva prueba. No elimine páginas ni modifique reglas repetidamente basándose únicamente en una captura de pantalla aislada.

## 8. ¿Cómo organizar la validación y la reversión el día del lanzamiento?

Se recomienda dividir el lanzamiento en preparación, cambio, repetición de pruebas y observación. Durante la preparación, congele los cambios importantes de contenido, haga copias de seguridad de los datos de las páginas y de la configuración, y confirme que puede mantenerse el acceso necesario al sitio antiguo.

Después del cambio, pruebe primero el recorrido de negocio esencial: entrada desde una dirección antigua, lectura de la información del producto, envío del formulario, recepción de la notificación y seguimiento comercial. Las comprobaciones de SEO y de captación de clientes potenciales deben realizarse en paralelo, para evitar que las páginas sean accesibles pero nadie reciba las consultas.

Las condiciones que bloquean el lanzamiento deben acordarse de antemano. Por ejemplo, que no se pueda acceder a páginas de producto clave, que numerosos puntos de acceso antiguos carezcan del destino previsto, que las páginas de producción sigan sujetas a restricciones del entorno de pruebas o que falle el proceso de consulta. Si se produce alguna de estas situaciones, la persona responsable debe decidir si se corrige o se revierte el cambio, en lugar de discutir los criterios mientras se realiza el lanzamiento.

La reversión también debe contar con instrucciones operativas: quién puede ejecutarla, qué configuraciones hay que restaurar y cómo confirmar que la recuperación ha sido correcta. No espere al día de la migración para descubrir que el sitio antiguo ya se ha eliminado o que han caducado los permisos de acceso a la cuenta del proveedor anterior.

## 9. Si cambia el rendimiento después de la migración, ¿cómo investigar de forma ordenada?

Se recomienda investigar primero los problemas técnicos y de contenido reproducibles y abordar después el rendimiento general en buscadores. El orden puede ser: si las páginas son accesibles, si los puntos de acceso antiguos llegan al destino correcto, si el contenido está completo, si se han actualizado los enlaces internos y si el mapa del sitio coincide con las declaraciones de las páginas.

Al comparar datos, analice conjuntamente la dirección antigua y la nueva de una misma página de negocio. Si solo consulta el historial de la nueva dirección, puede pasar por alto los datos anteriores a la migración; si solo observa los totales del sitio, puede ocultar las pérdidas de un directorio importante.

Registre también los cambios de publicidad, las modificaciones o eliminaciones de contenido, las campañas estacionales y los ajustes de configuración de analítica realizados durante el mismo periodo, para no atribuir todas las variaciones al cambio de plataforma. Conviene resolver en cada ronda un grupo definido de problemas y registrar los resultados de las nuevas pruebas, reduciendo el riesgo de que varios cambios superpuestos impidan identificar la causa.

No existe un plazo de recuperación único aplicable a todos los sitios web. La validación de la migración puede establecer un calendario interno de revisiones, pero no debe presentarlo como una promesa sobre los plazos de procesamiento de los motores de búsqueda.

## 10. Al elegir una plataforma de creación web con IA, ¿cómo preguntar por sus capacidades de migración?

Generar páginas y dar continuidad al sitio antiguo son dos trabajos de validación distintos. El [sitio oficial de we0](https://we0.ai/zh) presenta procesos de descripción de necesidades en lenguaje natural, creación con múltiples agentes, ajustes visuales y despliegue con dominio. Las empresas pueden utilizar esta información para evaluar la forma de crear el sitio, pero deben solicitar por separado una demostración de la conservación de rutas antiguas, la configuración de redirecciones y los métodos de prueba posteriores a la migración; no deben dar por hecho que estas tareas se realizarán automáticamente.

Como referencia de otro tipo de producto, el [sitio oficial de Readdy](https://readdy.ai/zh) presenta la exportación de código, el alojamiento de dominios y herramientas relacionadas con SEO y GEO. Durante la compra, conviene preguntar además quién mantendrá la configuración de despliegue después de exportar, quién gestionará las reglas de rutas y quién investigará las incidencias. Los nombres de las funciones no sustituyen un documento de responsabilidades del proyecto.

El [artículo de presentación de Wan Xiaozhi en la comunidad de desarrolladores de Alibaba Cloud](https://developer.aliyun.com/article/1773673) aborda la creación conversacional de sitios web y el proceso de despliegue, pero la página indica que el contenido ha sido aportado por un usuario. Puede ayudar al equipo a comprender los escenarios de creación web, pero no debe tratarse como un compromiso del proveedor sobre el alcance de la entrega de la migración de este proyecto.

Se recomienda pedir a las plataformas candidatas o al equipo de implementación que realicen una demostración con un pequeño grupo de páginas antiguas reales antes de decidir la compra y el plan de lanzamiento. La demostración debe abarcar distintas plantillas y situaciones anómalas, no limitarse a generar una nueva página de inicio.

## Preguntas frecuentes

### Si no cambia el dominio y solo cambia la plataforma de creación web, ¿también hace falta una lista de migración?

Sí. Se recomienda comprobar que las rutas, el contenido principal, las declaraciones de las páginas, los enlaces internos y el proceso de consulta mantienen la coherencia. Que el dominio no cambie no significa que todos los resultados del despliegue vayan a ajustarse automáticamente al plan original.

### ¿Se pueden redirigir todas las páginas antiguas a la página de inicio?

No se recomienda utilizarlo como solución por defecto. Primero hay que determinar si existe una nueva página relacionada que pueda recibir a los usuarios de cada página antigua. Cuando no haya contenido sustitutivo, también debe documentarse claramente el tratamiento, en lugar de utilizar la página de inicio para ocultar la ausencia de contenido.

### ¿La migración termina al enviar el mapa del sitio?

No. También hay que completar las pruebas de los puntos de acceso antiguos, la revisión de las páginas clave y la validación de los recorridos de negocio, además de seguir registrando los cambios de estado en Search Console. El envío no sustituye las pruebas de acceso real.

## Herramientas relacionadas

- **Tabla de correspondencia de URL**: permite gestionar las rutas antiguas, las nuevas, su tratamiento y las personas responsables.
- **curl**: permite consultar las cabeceras de respuesta, la secuencia de redirecciones y la dirección final.
- **Google Search Console**: permite organizar los registros de comprobación de los estados del sitio y de su rendimiento en buscadores.
- **Herramientas de desarrollo del navegador**: permiten volver a probar la carga de las páginas, los enlaces y las solicitudes de los formularios.

## Enlaces relacionados

- [we0: creación web, ajustes de páginas y proceso de despliegue](https://we0.ai/zh)
- [Readdy: presentación de la creación web, la exportación de código y las herramientas de gestión](https://readdy.ai/zh)
- [Comunidad de desarrolladores de Alibaba Cloud: escenarios de creación web con IA de Wan Xiaozhi](https://developer.aliyun.com/article/1773673)

## Resumen

La validación de un cambio de plataforma de creación web no se limita al nuevo sitio: abarca todo el recorrido desde los puntos de acceso antiguos hasta el nuevo contenido y, después, hasta la acción de consulta. Primero se debe crear una tabla de correspondencia de URL; después, probar las redirecciones, el contenido de las páginas, el mapa del sitio y los recorridos de negocio; y, por último, continuar la investigación con ayuda de Search Console. Las capacidades de la plataforma deben confirmarse mediante demostraciones con páginas reales, y las responsabilidades de migración y las condiciones de reversión deben quedar documentadas antes del lanzamiento.