Lista de verificación para la migración de un CMS sin cabeza: antes de pasar de WordPress a Sanity·Strapi·Directus
Al pasar de WordPress a un CMS sin cabeza, no son sólo los datos de sus publicaciones los que realmente necesita proteger. Esta es una lista de verificación práctica que verifica URL, SEO, medios, vista previa, permisos y reversión antes del lanzamiento.
Dejar WordPress no se trata sólo de mover datos. Está cerca de redefinir en el nuevo sistema las direcciones encontradas en las búsquedas, las vistas previas en las que hacen clic los editores, el contexto adjunto a las imágenes y quién puede publicar qué.
Por tanto, la idea de "simplemente sacar el XML y empezar" es peligrosa. La exportación WXR de WordPress contiene datos de contenido como publicaciones, páginas, tipos de publicaciones personalizadas, comentarios, campos personalizados, categorías y usuarios, pero la nueva interfaz no reproduce URL ni funciones de asistencia SEO. La documentación oficial de WordPress también describe WXR como un formato para la transferencia de contenido.
Los fracasos repetidos en las comunidades de práctica son similares. Descubres el historial de redireccionamiento demasiado tarde, te pierdes los datos estructurados y el meta OG que estaba creando tu complemento SEO, y solo después de que el editor real comienza a escribir las vistas previas encuentras tu flujo de trabajo vacío. Este artículo no volverá a comparar cuál es mejor entre Sanity·Strapi·Directus. Si ya ha decidido mudarse, determine en qué orden debe tomar sus decisiones para no perder la búsqueda y las operaciones.
Conclusión de una sola línea: no elija un CMS primero, primero corrija la URL, el modelo de contenido y el flujo de publicación. La plataforma es el medio para implementar esa decisión.
Tres casos en los que deberías parar primero
Todavía no sabemos qué está causando el problema de rendimiento.
Cambiar a headless sin saber qué cuello de botella se encuentra entre los complementos, el procesamiento de imágenes, el caché, el alojamiento o los temas solo puede aumentar la complejidad operativa. La separación del renderizado puede funcionar, pero no resuelve automáticamente el problema que tiene. Primero, medimos el LCP, la capacidad de la imagen, la tasa de aciertos de la caché y los cuellos de botella de la pantalla del administrador de la página real.
No puedo describir mi nueva experiencia de edición en oraciones.
“Un CMS más flexible” no es un requisito. Debe poder responder preguntas como quién redacta, revisa y publica el borrador, cómo se ve el artículo que se está editando en la página real, qué bloques se utilizan para crear la página de destino combinada y quién se encarga de la traducción y la publicación programada.
Lista de URL antiguas y destinos desconocidos
En este caso no deberías iniciar el desarrollo. Para las migraciones de sitios en las que las URL cambian, Google recomienda mapear URL antiguas y nuevas, redireccionamientos permanentes del lado del servidor, un nuevo mapa del sitio y canónico, y monitoreo posterior a la migración. En particular, le recomendamos no realizar varios cambios a la vez. Cambiar CMS, URL y diseño al mismo tiempo es técnicamente una versión, pero son tres cambios en la búsqueda. La guía de migración de sitios de Google Search Central sirve como punto de referencia.
La selección se basa en la operación, no en la tabla de funciones.
| centro de operaciones | Un punto de partida más natural | Verificar primero |
|---|---|---|
| Los equipos de contenido trabajan en torno a documentos estructurados, activos y vistas previas. | Cordura | Pantalla de entrada de Studio, vista previa de borrador/publicado, referencias de documentos y permisos |
| El equipo de desarrollo controla la API y los tipos de contenido como el backend. | correa | Tipo de contenido, transferencia de datos y activos por entorno, derechos de gestión y procedimientos de distribución |
| Los datos SQL existentes y los datos operativos son la clave | directo | Mapeo de base de datos existente, relación de campo de colección y control de acceso específico de rol |
Las vistas previas de Sanity pueden manejar tanto borradores como lanzamientos, pero las vistas previas reales deben diseñarse para incluir la interfaz y la certificación. Consulte primero el Documento de vista previa de Sanity.
En Strapi, es importante decidir qué mover y qué crear entre desarrollo, puesta en escena y producción. Las herramientas de transferencia de datos pueden excluir intencionalmente elementos como usuarios administradores y tokens API, por lo que no debe intentar resolver cuentas operativas y secretos con la transferencia de datos. Consulte la guía de transferencia de datos de Strapi.
Directus mueve modelos de datos entre entornos con instantáneas de esquema y aplicación, y le permite verificar las diferencias mediante un simulacro antes de aplicar. Esta es una buena razón para versionar su esquema junto con su código, pero también debe incluir los campos que cambie en la consola en sus reglas de implementación. Puede utilizar la documentación de Directus CLI como referencia.
Paso 0: Inventario, incluidos los artículos que no se moverán
El primer resultado de una buena migración no es un guión de importación sino una hoja de rúbricas. Reúna la siguiente lista del rastreador, la consola de búsqueda, la herramienta de análisis, el registro del servidor y el administrador de WordPress en una sola clave.
| campo | Razones para dejar atrás |
|---|---|
| URL antigua, URL final, código de estado | Estándares para redirección 1:1 y verificación de cadena/bucle |
| título, descripción, canónico, robots | Para comparar fragmentos de búsqueda y políticas de indexación |
| H1, cuerpo, enlaces internos, archivos adjuntos | Para encontrar resultados de renderizado y enlaces rotos |
| Imágenes OG, datos estructurados, preguntas frecuentes, información del autor | Para restaurar las funciones proporcionadas por complementos y temas. |
| URL de origen de la imagen, alt, título, ubicación de uso | Para simplemente mover archivos y no perder contexto |
| Tipo de publicación, clasificación, etiquetas, autor, idioma | Entradas al nuevo modelo de contenido y diseño de permisos. |
| Fecha de publicación/modificación, vista/conversión/vínculo de retroceso | Primero, decidir qué páginas transferir e inspeccionar, |
El número de excepciones es más importante que el número total de publicaciones. Encuentre slugs duplicados, campañas caducadas, archivos PDF, reglas de complementos de redireccionamiento e imágenes que quedan solo en su biblioteca multimedia. Las páginas con alto tráfico de búsqueda, conversiones y enlaces externos reciben una calificación A y son revisadas por ojos humanos antes de su publicación.
No mueva las páginas que no desea mover al nuevo sitio a la página de inicio. Envíe a una página de reemplazo relevante o devuelva un 404 o 410 si realmente falta el contenido. Google también advierte que los redireccionamientos a páginas de inicio no relacionados pueden interpretarse como 404 suaves. Siga la Guía de migración de Google.
Paso 1: Traduce tus publicaciones de WordPress al nuevo modelo de contenido
La pantalla de edición de WordPress puede parecer fácilmente una sola pieza de texto. En un CMS nuevo, es mejor dividir primero las unidades que se van a reutilizar y validar. Sin embargo, no divida cada párrafo en campos. Las estructuras que un editor nunca reutilizará se convierten en deuda técnica.
Para el contenido escrito, normalmente puedes empezar desde abajo.
- Común: Título, slug, resumen, texto, imagen representativa, autor, fecha de publicación/modificación, estado
- SEO: valores obligatorios para título, descripción, anulación canónica, robots, imágenes OG, datos estructurados
- Relaciones: categorías, etiquetas, publicaciones relacionadas, enlaces de traducción original en varios idiomas
- Bloques de cuerpo: solo cosas que realmente reutilizas, como texto, imágenes, citas, código, tablas y CTA.
Las muestras deben ser de los peores escritos, no de los bonitos. Intente transferir 10 artículos con una combinación de tablas, imágenes en línea, YouTube, galería, código corto, ACF, multilingüe, coautor y publicación reservada. Si esta muestra pasa, el alcance de la metástasis masiva es visible.
Para Sanity, es más seguro dejar la verificación previa y posterior a la importación y el ensayo como procedimientos predeterminados. La CLI oficial también recomienda hacer una copia de seguridad del conjunto de datos exportándolo o copiándolo antes de la aplicación real. Consulte esquema de cordura y migraciones de contenido.
Paso 2: Los medios son una transferencia de referencia, no una transferencia de archivos
Las imágenes son el último problema en surgir. Las miniaturas son visibles, pero las imágenes en línea no son visibles, faltan etiquetas y leyendas, y se pierde la forma en que se usa la misma imagen en varias publicaciones.
En la tabla de asignación de medios, deje al menos la URL existente, el nuevo ID del activo, la nueva URL, el ID del documento utilizado, alt y el título. Mantener los hashes de archivos juntos ayuda a reducir las cargas y repeticiones duplicadas. Los resultados de los registros se realizan en lotes pequeños para que las filas fallidas se puedan volver a ejecutar.
Sanity admite la importación masiva de activos a través de CLI y procesa los mismos archivos para evitar cargas duplicadas. Sin embargo, es posible que se requieran pasos separados para vincular el archivo de la biblioteca multimedia al documento. Deberías leer Importación de activos de Sanity y Guía de vinculación de documentos juntos.
Lo mismo ocurre con Strapi y Directus. Finalizar la carga no es una condición para su finalización. Debe verificar la imagen original, la versión convertida, alt, título, relación del documento, URL de CDN e incluso los permisos de acceso en la página real.
Paso 3: Haga del SEO una condición de bloqueo de lanzamiento en lugar de un elemento de verificación posterior a la implementación
La búsqueda no reconoce el nuevo CMS. Lo que Google ve es el HTML final y la respuesta. Por lo tanto, la revisión de SEO debe realizarse comparando el mismo conjunto de URL en la etapa de preparación, no después de que se haya importado el contenido.
Antes del lanzamiento, todas estas condiciones deben ser ciertas.
- La URL principal existente devuelve 200 a la misma URL, o un único salto 301/308 a la nueva URL exacta.
- La nueva página tiene un canónico autorreferenciado y no queda ningún índice.
- El título, la meta descripción, Open Graph, los robots y JSON-LD se representan según la intención existente.
- Los enlaces internos, imágenes, archivos PDF y hreflang apuntan a la nueva URL final.
- El mapa del sitio contiene solo las URL canónicas HTTPS absolutas que desea indexar.
- No hay errores de autenticación, WAF o JavaScript en la representación móvil ni en el acceso real del bot.
- Rastreamos los sitios antiguos y nuevos respectivamente y diferenciamos 200, 3xx, 4xx, canonical, robots, H1 y title.
Google recomienda 301/308 para redirecciones permanentes y evitar cadenas si es posible. Los enlaces internos y los mapas del sitio también deben apuntar directamente a la nueva URL. Además, el robot de Google debe visitar tanto la URL antigua como la nueva para que la transferencia del sitio se procese por completo, por lo que incluso los sitios de tamaño mediano pueden tardar varias semanas. Consulte también la Guía de redireccionamiento y la Guía de mapas del sitio.
Las mejores estrategias de comercialización son simples. Cambie el CMS, pero no cambie la URL, la estructura de la información, el texto y el diseño al mismo tiempo en la primera versión. Las mejoras se posponen para la próxima versión cuando el índice y la operación sean estables.
Paso 4: Pruebe permisos y vistas previas en personas reales
El hecho de que un desarrollador pueda abrir una vista previa no significa que el editor pueda realizar el trabajo. Pruebe un ensayo de usabilidad de 30 minutos con los roles a continuación.
- Autor: Crea una nueva publicación y completa los campos Imagen y SEO.
- Revisor: verifique la pantalla real y el meta en el borrador de la URL y deje una solicitud de modificación.
- Editor: maneja la emisión de reservas y las reversiones de emergencia.
- Operador: evita que los autores accedan a configuraciones globales, redireccionamientos y secretos de API.
Sanity puede dividir roles y permisos para proyectos, conjuntos de datos y alcance de documentos. Sin embargo, si se trata de un conjunto de datos públicos, el documento oficial especifica que los miembros del proyecto pueden leer el contenido público independientemente de su función. Verifique roles de cordura y no trate los borradores privados y los conjuntos de datos públicos como la misma cosa.
Paso 5: Revertir no se trata de tener una copia de seguridad, se trata de poder revertir
Si algo sale mal, anota qué se hará, en cuántos minutos y quién lo revertirá. La copia de seguridad es sólo el comienzo.
Tarjeta de reversión antes del lanzamiento
- Configuración de DNS, proxy y distribución para apuntar a su antiguo sitio de WordPress
- La versión estable anterior de la nueva interfaz.
- Exportación de datos CMS, hora de creación, lista de activos, registro de importación
- Versiones de archivos de mapeo de URL y reglas de redireccionamiento implementadas
- Quién aprobará la reversión y un enlace al panel de observación
- Condiciones de reversión inmediata: 5xx en la URL principal, no índice grande, error en el flujo de inicio de sesión/pago/consulta
La instantánea/aplicación de Directus ayuda con la gestión de cambios del entorno operativo al identificar diferencias de esquema. Sin embargo, las instantáneas no restauran los datos de contenido ni la implementación de front-end. Una verdadera reversión requiere la capacidad de recuperar el esquema, el contenido, los activos, la interfaz y la redirección, respectivamente.
14 días después del lanzamiento: busque primero anomalías, no tráfico
La fecha de lanzamiento no es una fecha de finalización. Durante las próximas dos semanas, deje de publicar nuevas publicaciones o de realizar cambios importantes en el diseño y simplemente observe los resultados de la migración.
| Punto de vista | Controlar |
|---|---|
| Inmediatamente después del lanzamiento | Código de estado, canónico, robots, meta, datos estructurados, inicio de sesión/formulario/vista previa de ejemplos de URL principales |
| 24 horas | Errores del servidor, aumento de 404, cadenas/bucles de redireccionamiento, imágenes rotas y enlaces internos |
| 3-7 días | Procesamiento de mapas del sitio de Search Console, errores de indexación/rastreo, cambios en la exposición de consultas principales/de marca |
| 14 dias | Registros de tráfico y redireccionamiento para URL antiguas, nuevas tendencias de índices de URL, tiempos de publicación y errores del equipo de contenido |
Google recomienda observar el mapa del sitio, el estado del índice y el rastreo en Search Console después de la migración y, en general, recomienda mantener las redirecciones durante al menos un año. Vincule las Pautas para monitorear un sitio después de su movimiento en su documentación operativa.
Registro de Riesgos: Una tabla que evita que las personas vean los problemas cuando surgen.
| peligro | señal más temprana | prevención | primera respuesta |
|---|---|---|---|
| Falta una URL antigua | 404·유입 급감·외부 링크 오류 | Consolide las URL en el mapa del sitio, el registro, el GSC y las reglas de redireccionamiento | Se agregó mapeo de URL, redirección persistente de un solo salto |
| SEO 플러그인 기능 소실 | Diferencias de título JSON-LD·OG· | Comparación página por página de HTML antiguo y nuevo | Complementación del renderizador de datos meta/estructurados |
| desconexión de referencia de medios | Falta la imagen corporal 404·alt | tabla de asignación de ID de activo e ID de documento | Volver a ejecutar el lote fallido, parche de referencia |
| Sobrediseño de esquema | El editor evita ingresar campos. | Pruebe primero con las 10 muestras más complejas | Consolidación de campos, reducción de bloques. |
| Vista previa/brecha de permisos | Omitir la aprobación por correo electrónico o mensajería | Ensayos y listas de verificación para cada rol. | Complementación de URL de vista previa y políticas de permisos |
| Despliegue irreversible | Responsabilidad/procedimiento de reversión desconocido | Entrenamiento de recuperación previo al lanzamiento. | Regresar a la versión estable desde la interfaz |
Al final, no es el CMS el que se mueve, sino el puesto de responsabilidad.
WordPress esconde muchas cosas dentro de complementos y temas. El CMS sin cabeza traslada esa responsabilidad al modelo de contenido, la API, la interfaz y el proceso de implementación. Por lo tanto, puede ser más gratuito, pero eso no lo hace automáticamente más sencillo.
Una migración bien hecha no se explica con “fuimos a Sanity” o “usamos Directus”. Las URL existentes sobreviven, los editores publican con menos ansiedad que antes y las páginas nuevas mantienen las mismas promesas a las búsquedas y a los usuarios.
Inventario, modelo de contenido, transferencia de pequeñas muestras, verificación de URL/SEO, ensayo del editor real, capacitación de reversión y publicación silenciosa. Este orden es lo primero. Puedes elegir las herramientas más tarde.