Migración de CMS y SEO

TL;DR — Una migración de CMS traslada su sitio web a un sistema distinto, por ejemplo al cambiar de plataforma de publicación, de plataforma de comercio electrónico o de arquitectura de front-end. Conserve aquello en lo que los motores de búsqueda y los usuarios ya confían: URL, contenido, títulos, etiquetas canónicas, reglas de robots, datos estructurados, enlaces internos, imágenes y páginas renderizadas. Si las URL deben cambiar, mapee y redirija cada URL antigua a su reemplazo más cercano. Pruebe la nueva plataforma en staging, compárela con el sitio actual, ensaye el lanzamiento y mantenga un rollback que restaure tanto la aplicación como sus datos.

¿Qué es una migración de CMS?

Una migración de CMS sustituye el sistema de gestión de contenidos o la plataforma que crea y sirve un sitio web. Pasar de WordPress a un sistema headless, de Drupal a otro CMS empresarial, o de una plataforma de ecommerce a otra son ejemplos habituales.

El diseño visible puede seguir siendo similar mientras la salida técnica cambia por completo. La nueva plataforma puede generar URL, HTML, metadatos, navegación, filtros, paginación, imágenes, datos estructurados, redirecciones y directivas de robots distintos.

¿Toda migración de CMS es una migración de URL?

No. Una migración de CMS puede mantener idéntica cada URL pública. Esa suele ser la opción más segura cuando la estructura de URL existente funciona.

En el momento en que cambia un esquema, un nombre de host, una ruta, una convención de barra final, un nombre de archivo o un parámetro significativo, el proyecto también se convierte en una migración de URL. Añada el trabajo de mapeo, redirecciones, enlaces internos, canonicalización y sitemaps de la guía de migraciones web.

¿Qué significa la “paridad SEO”?

La paridad SEO significa que la nueva plataforma conserva el comportamiento útil y visible para la búsqueda de la anterior. No es una paridad de diseño píxel a píxel.

Para cada tipo de página importante, compare:

• URL indexable y código de estado HTTP;
• título, descripción, encabezados y contenido principal;
• canonical, directivas de robots y hreflang;
• datos estructurados;
• enlaces internos rastreables y navegación;
• imágenes, video, PDF y otros medios;
• salida móvil y renderizada;
• rendimiento y fiabilidad del servidor.

La paridad también incluye mejoras intencionadas. Documéntelas por separado para que un cambio útil no se confunda con un defecto de la migración.

¿Por qué las migraciones de CMS pierden tráfico?

Las migraciones de CMS suelen perder tráfico porque la nueva plataforma no reproduce algún comportamiento importante. Entre los ejemplos habituales están las URL antiguas que devuelven 404, las etiquetas canónicas que apuntan a staging, los enlaces de categoría que desaparecen, el contenido del cuerpo que solo se carga tras un clic, las variantes de producto que se convierten en duplicados indexables o las redirecciones heredadas que nunca llegan a transferirse.

El nombre de la plataforma rara vez es la causa. Lo es el sitio generado.

¿Cuál es el proceso básico?

1. Inventaríe las URL, plantillas, contenidos, señales, enlaces, recursos, redirecciones e integraciones del sitio actual.
2. Decida si las URL se mantendrán iguales.
3. Escriba requisitos de paridad medibles para cada plantilla y comportamiento del sistema.
4. Mapee los campos de contenido y migre los datos al nuevo CMS.
5. Rastree y renderice el entorno de staging y compárelo después con la línea base guardada.
6. Pruebe las redirecciones si alguna URL cambia.
7. Ensaye el congelamiento de contenido, la sincronización final de datos, el despliegue, la purga de caché y el rollback.
8. Lance, valide producción de inmediato y monitorice por plantilla y por cohorte de URL.

La Website Migration Checklist proporciona la secuencia compartida del proyecto por fases. Esta guía se centra en lo que un nuevo CMS puede cambiar dentro de cada fase.

¿Conviene corregir todos los problemas de SEO antiguos durante la migración?

Corrija los defectos de alta confianza cuando la nueva plataforma fuese a reproducirlos, pero no combine todo el rediseño, la reescritura de contenidos, el cambio de arquitectura y la limpieza de URL en una sola versión. Google recomienda cambiar una sola cosa importante cada vez, siempre que sea posible, en su guía sobre traslados de sitios.

Separe los defectos que deben corregirse de las mejoras opcionales. Se necesita una línea base estable para diagnosticar qué ocurrió tras el lanzamiento.

TL;DR — Un replatforming es una migración de contratos entre dos sistemas de generación de páginas. Inventaríe cada fuente actual de URL, plantilla, campo de contenido, regla de enlazado interno, control de indexación, canonical, anotación hreflang, objeto de schema, URL de medios, faceta, redirección e integración. Decida el alcance de URL iguales frente a URL modificadas antes de que la configuración de la plataforma se consolide. Traduzca el inventario en pruebas de paridad, no en una lista de comprobación genérica. Migre los datos, rastree el HTML sin procesar y el DOM renderizado en staging, compare por plantilla y por cohorte de URL protegidas, ensaye el cutover y el rollback de datos, y monitorice después las cohortes por separado para que una plantilla rota no quede oculta dentro de los totales globales del sitio.

Clasifique el replatforming antes de elegir el plan

Una migración de CMS puede contener varios cambios:

Escriba cada capa dentro del alcance. Una “migración de CMS” que además cambia la estructura de URL, el hosting, el renderizado y la navegación son cuatro migraciones que comparten un mismo lanzamiento.

Decida pronto entre mantener las URL o cambiarlas

La conservación de las URL suele ser la opción por defecto cuando las URL existentes son útiles y la nueva plataforma puede admitirlas. No acepte un “la plataforma no puede hacer eso” sin medir el costo de las redirecciones, el nuevo rastreo, las integraciones actualizadas, los enlaces profundos perdidos y la complejidad operativa.

El cambio de URL aún puede justificarse cuando la estructura actual es inestable, expone tecnología obsoleta, crea duplicados o no puede representar la nueva arquitectura de la información. La decisión debe tomarse antes de construir temas, rutas, importaciones y feeds en torno a un patrón nuevo.

Las URL modificadas necesitan todo el flujo de trabajo de migración de estructura de URL: inventario maestro, disposición explícita, mapeo uno a uno o de varios a uno justificado, redirecciones permanentes, enlaces internos directos, anotaciones actualizadas, nuevos sitemaps y monitorización.

Construya el inventario del estado actual a partir de varios sistemas

La base de datos del CMS actual no es el inventario del sitio web. Combine:

• URL rastreables de uno o varios rastreos;
• sitemaps XML y exportaciones de feeds;
• páginas de destino de la analítica y páginas de Search Console;
• logs del servidor, incluidas las URL huérfanas o heredadas que los rastreadores siguen solicitando;
• páginas de destino de backlinks y de campañas;
• bibliotecas multimedia, PDF, imágenes, video y recursos descargables;
• búsqueda interna, navegación por facetas, paginación y patrones de ordenación;
• reglas de redirección del CMS, el servidor, el CDN y el código de la aplicación;
• consumidores de API, aplicaciones, correo electrónico, medios de pago, afiliación, localización y feeds.

Asigne a cada URL una entidad de contenido, una plantilla, un estado de indexabilidad, un destino canónico, una importancia por tráfico y enlaces, y un destino previsto. El inventario es el libro de reconciliación después de la importación.

Inventaríe el modelo de contenido, no solo el texto de las páginas

El mapeo del modelo de contenido describe cómo se trasladan los campos y las relaciones. Incluya:

• títulos, resúmenes, bloques de cuerpo, autores, fechas y fechas de actualización;
• taxonomías, elementos padre, colecciones, categorías y etiquetas;
• slugs, variantes de locale, sobrescrituras de canonical y controles de robots;
• origen de la imagen, texto alternativo, pies de foto, dimensiones, recortes y puntos focales;
• contenido relacionado, breadcrumbs, navegación principal y enlaces contextuales;
• identificadores de producto, precios, disponibilidad, reseñas, variantes y ofertas;
• propiedades de datos estructurados y relaciones entre entidades;
• redirecciones, alias, estados no publicados, programación y permisos.

La presencia del campo no basta. Pruebe las reglas de transformación, el comportamiento con valores nulos, la codificación, la conversión de Markdown o de texto enriquecido, los componentes incrustados y las referencias. Un campo migrado que se renderiza vacío sigue siendo contenido perdido.

Convierta la paridad en criterios de aceptación

Los requisitos de paridad deben escribirse por plantilla. Una página de producto y un artículo no comparten el mismo contrato de contenido, schema, paginación ni enlazado interno.

Para cada plantilla, defina:

• estado e indexabilidad esperados;
• regla de generación del canonical;
• comportamiento de la metaetiqueta robots y de X-Robots-Tag;
• campos de origen del título, la descripción, el H1 y el contenido principal;
• tipos de datos estructurados requeridos y alineación con las propiedades visibles;
• reglas de breadcrumbs, navegación, enlaces relacionados y paginación;
• comportamiento de hreflang y de locale;
• comportamiento de los recursos y metadatos de imagen;
• requisitos del HTML sin procesar y requisitos del DOM renderizado;
• umbrales de rendimiento y disponibilidad;
• comportamiento de la analítica y del consentimiento.

Separe las decisiones de conservar, eliminar y mejorar. Eso evita que el equipo de QA restaure un defecto conocido o acepte una pérdida accidental como si fuera una mejora.

Pruebe el HTML sin procesar y la salida renderizada

La estrategia de renderizado es una decisión de replatforming, no un detalle de implementación de los desarrolladores. La documentación de SEO en JavaScript de Google explica que rastrea, renderiza y después indexa las páginas con JavaScript. También señala que el renderizado en servidor o el prerenderizado sigue siendo una buena idea porque ayuda a usuarios y rastreadores, y no todos los bots ejecutan JavaScript.

Para cada plantilla protegida, compare el HTML sin procesar con el DOM renderizado:

• ¿Está presente el contenido principal sin que medie una interacción del usuario?
• ¿Son los enlaces elementos <a href> reales con destinos resolubles?
• ¿Coinciden los códigos de estado con los estados de error, o cada ruta devuelve un caparazón de error soft 404?
• ¿Están presentes y son coherentes las directivas canonical y robots?
• ¿Se pueden rastrear el JavaScript, el CSS, las API y los recursos necesarios?
• ¿Los fallos de hidratación o de API eliminan contenido?
• ¿El renderizado móvil contiene contenido principal y metadatos equivalentes?

Google advierte de que, cuando encuentra noindex, puede omitir el renderizado, por lo que usar JavaScript para eliminar un noindex inicial puede fallar. Indique la indexabilidad prevista en la respuesta original.

Conserve la lógica de canonical y de control de indexación

Las reglas de canonical suelen degradarse de una lógica de plantilla deliberada a un “canonical propio en todo”. Eso puede exponer duplicados creados por filtros, parámetros de seguimiento, paginación, vistas de impresión o variantes.

Documente cada regla como entradas y salidas esperadas. Pruebe:

• host, esquema, ruta, barra y codificación absolutos del canonical;
• canonicals propios en las páginas que deben ser indexables;
• destinos canonicales para las variantes duplicadas;
• interacciones entre la metaetiqueta robots y X-Robots-Tag;
• comportamiento del canonical en respuestas distintas de 200;
• inclusión en el sitemap únicamente de las URL canonicales previstas;
• coherencia entre la salida de escritorio, la móvil y la renderizada.

Utilice el Canonicalization Checker en páginas representativas y valide después las plantillas de forma masiva con un rastreador.

Reconstruya los datos estructurados a partir del nuevo modelo de origen

Los datos estructurados rara vez se transfieren de forma automática porque las nuevas plantillas y campos cambian. Mapee cada propiedad a su nueva fuente y confirme después que el marcado describe el contenido visible de la página.

Google recomienda probar los datos estructurados con la herramienta Rich Results Test durante el desarrollo y monitorizar los informes de resultados enriquecidos después del despliegue, porque los problemas de plantillas o de servido pueden romperlos. Consulte la introducción a los datos estructurados de Google.

Valide tanto la sintaxis como la elegibilidad. Que un validador dé el visto bueno no garantiza un resultado enriquecido, y un objeto sintácticamente válido puede seguir describiendo el producto, el artículo, el breadcrumb, el autor, el precio o la disponibilidad equivocados.

Conserve la función del enlazado interno, no solo el número de enlaces

La paridad de enlaces internos significa que las páginas importantes siguen siendo detectables mediante rutas de rastreo equivalentes o mejores. Compare:

• navegación principal y de utilidades;
• breadcrumbs y jerarquía de categorías;
• productos relacionados, artículos relacionados y enlaces contextuales;
• paginación y alternativas al botón de cargar más;
• pie de página y selectores de idioma y de mercado;
• enlaces dentro del contenido del cuerpo migrado;
• número de páginas huérfanas, profundidad de clic y distribución de enlaces entrantes.

Un diseño nuevo puede mantener el mismo número total de enlaces mientras elimina los enlaces que realmente sostenían las páginas profundas. Analice los cambios por destino y por plantilla.

Trate las facetas, los parámetros y la búsqueda interna como requisitos de producto

Las plataformas suelen imponer un nuevo comportamiento de filtrado y ordenación. Documente qué combinaciones deben ser rastreables, indexables, canonicalizadas, enlazadas o bloqueadas. Pruebe el orden de los parámetros, los resultados vacíos, las selecciones múltiples, la paginación y el comportamiento en móvil.

No copie una regla general de robots de la plataforma antigua si la nueva genera rutas distintas. La exclusión mediante robots puede reducir el rastreo, pero por sí sola no puede consolidar señales ni eliminar URL ya indexadas.

Utilice el Faceted Navigation Auditor para explorar los patrones de parámetros y valide después los controles de rastreo e indexación elegidos para el sitio.

Migre los medios como URL de primer nivel

La migración de medios abarca más que copiar archivos. Conserve o mapee de forma explícita:

• URL de imágenes, video, PDF y descargas;
• texto alternativo, pies de foto, títulos y contexto circundante;
• dimensiones de imagen, formatos, variantes responsive y URL de origen estables;
• reproductores de video, miniaturas, transcripciones y datos estructurados;
• estado de los PDF, cabeceras canonical, enlaces y controles de acceso;
• rutas de CDN, URL firmadas, reglas de hotlinking y comportamiento de la caché.

La guía actual de Google sobre indexación mobile-first recomienda mantener equivalentes el contenido, los metadatos, los datos estructurados y los recursos rastreables importantes en móvil y en escritorio. También advierte de que cambiar las URL de las imágenes puede provocar una pérdida temporal en la búsqueda de imágenes mientras se procesan las nuevas URL. Consulte las prácticas recomendadas de indexación mobile-first.

Transfiera las redirecciones y el comportamiento ante errores

Las redirecciones heredadas pueden vivir en el CMS, en .htaccess, en nginx, en el middleware de la aplicación, en balanceadores de carga y en reglas del CDN. Expórtelas y aplánelas antes del lanzamiento. Una plataforma nueva suele empezar con una tabla de redirecciones vacía y descarta en silencio años de historial acumulado de URL.

Pruebe también el contenido que falta de verdad. La plataforma debe devolver un 404 o un 410 real, no una plantilla 200 con el texto “no encontrado”. Conserve las experiencias de error personalizadas sin enmascarar el resultado HTTP.

Si las URL cambian, pruebe cada URL antigua mapeada. Utilice el Redirect Map Builder como libro de revisión y el Bulk HTTP Status Code Checker para la verificación una vez desplegado.

Mantenga el entorno de staging privado y comprobable

El acceso a staging debe equilibrar la protección y el rastreo autorizado. Prefiera autenticación, VPN o controles de red, y conceda acceso explícito a los sistemas de QA. Si existen controles temporales de robots o noindex, regístrelos en un libro de eliminación previo al lanzamiento y demuestre que no están presentes en producción.

Construya un rastreo de staging a partir del inventario de destino completo, no solo de la navegación. Compárelo con la línea base por plantilla y por cohorte de importancia. El Staging vs. Production SEO Diff ayuda con muestras emparejadas; un rastreo completo cubre la cobertura sistémica.

Reconcilie la migración antes del lanzamiento

La reconciliación responde a cuatro preguntas:

1. ¿Se importó cada entidad de contenido prevista?
2. ¿Produjo cada entidad la URL pública esperada o un estado deliberado sin URL?
3. ¿Superó cada destino esperado el contrato de su plantilla?
4. ¿Recibió cada URL antigua la disposición aprobada?

Utilice recuentos por tipo de contenido, locale, estado, indexabilidad y plantilla. Los totales globales del sitio pueden coincidir mientras falta todo un idioma, una categoría, un archivo de autor o una clase de medios.

Ensaye el cutover y el rollback

El ensayo debe incluir un volumen de datos similar al de producción y la secuencia real:

• congelamiento de contenido o inicio de la sincronización de deltas;
• importación final de la base de datos y de los medios;
• despliegue de redirecciones y de reglas en el edge;
• activación de la aplicación, la caché, las colas, el índice de búsqueda y los feeds;
• cambio de DNS o de balanceador de carga si cambia la infraestructura;
• pruebas de humo y rastreo en producción;
• rollback de código, configuración, esquema de base de datos y escrituras.

El rollback de la base de datos es la parte difícil. Revertir el código de la aplicación después de que los usuarios creen pedidos, cuentas, comentarios o contenido en el nuevo esquema puede perder o corromper datos. Defina correcciones hacia adelante (roll-forward) y una reconciliación junto con el rollback técnico.

Valide producción en orden de dependencias

La validación en producción debe avanzar del fallo sistémico al detalle de la página:

1. DNS, TLS, estado y disponibilidad del host.
2. Robots.txt, autenticación, WAF y directivas de robots globales.
3. Página de inicio más una página de cada plantilla protegida.
4. Canonicals, hreflang, schema, enlaces, recursos y renderizado.
5. Inventarios completos de redirecciones y de destinos.
6. Analítica, consentimiento, formularios, checkout, feeds, API y búsqueda.
7. Cohortes de rastreo, indexación, tráfico y conversión.

Corrija los defectos de plantilla antes que las URL individuales. Un solo fragmento de canonical erróneo puede afectar a millones de páginas.

Monitorice por cohortes después del lanzamiento

La monitorización por cohortes agrupa las URL según lo que cambió. Entre las cohortes útiles están las páginas con la misma URL, las páginas redirigidas, los productos, las categorías, los artículos, los locales, las plantillas renderizadas, los medios, las facetas y las páginas con más enlaces.

Haga seguimiento de las respuestas correctas, los fallos de redirección, las discrepancias de canonical, la indexabilidad, la integridad del renderizado, los enlaces internos, el estado del sitemap, los canonicals seleccionados por Google, los clics, las impresiones, las conversiones y la actividad de los rastreadores. Compare periodos equivalentes y anote las campañas ajenas, la estacionalidad, los cambios de algoritmo y las actualizaciones de medición.

Una línea de tráfico agregada no puede decirle si una plantilla nueva falló mientras otra creció.

Resumen para IA

• Una migración de CMS cambia el sistema que genera las páginas; también puede cambiar las URL, el renderizado, el diseño, la arquitectura, el hosting y las integraciones.
• Decida el alcance de URL iguales frente a URL modificadas antes de construir el enrutamiento y las importaciones de la plataforma.
• Construya el inventario a partir de rastreos, sitemaps, logs, analítica, Search Console, backlinks, medios, redirecciones y consumidores posteriores.
• Mapee los campos de contenido, las relaciones, la taxonomía, los metadatos, los medios, el schema y los estados del flujo de trabajo, no solo el texto del cuerpo.
• Defina contratos comprobables por plantilla para el estado, la indexabilidad, el canonical, los robots, el contenido, los enlaces, el schema, el hreflang, los recursos, el renderizado y el rendimiento.
• Compare el HTML sin procesar y la salida renderizada. El contenido principal y los enlaces rastreables no deben depender de la interacción del usuario.
• Trate las facetas, la paginación, la búsqueda interna, las redirecciones heredadas y el comportamiento real ante un 404 como requisitos de la plataforma.
• Reconcilie las entidades importadas, los destinos generados, las pruebas de plantilla y la disposición de cada URL antigua antes del lanzamiento.
• Ensaye la sincronización final, el despliegue, la validación y un rollback consciente de los datos.
• Monitorice tras el lanzamiento por plantilla y por cohorte de cambio, no solo el tráfico global del sitio.

Documentación oficial

Google

• Traslado de sitios con cambios de URL cubre el mapeo de URL, las redirecciones, las anotaciones, los enlaces, los sitemaps y la monitorización.
• Cambiar el alojamiento se aplica cuando también cambia la infraestructura pero las URL públicas no.
• Conceptos básicos del SEO de JavaScript explica el rastreo, el renderizado, la indexación y el comportamiento del canonical y de los robots.
• Buenas prácticas de indexación centrada en móviles cubre la paridad de contenido, metadatos, schema, medios y recursos.
• Introducción a los datos estructurados recomienda validar durante el desarrollo y después del lanzamiento.
• Directrices generales de datos estructurados explica los requisitos técnicos y de calidad.

Bing

• Migración de sitios web con Bing cubre las migraciones de CMS, las auditorías, las redirecciones, los logs y la monitorización. Su referencia a la Site Move Tool está obsoleta; utilice las Bing Webmaster Tools actuales e IndexNow.
• IndexNow notifica a Bing y a los motores participantes las URL añadidas, actualizadas o eliminadas.

Citas de la fuente

• “Plan your changes to your site one after the other, not everything at the same time.” (traducción) «Planifica los cambios de tu sitio uno después de otro, no todos a la vez». Google Search Central. Ir a la indicación
• Paráfrasis: Para las URL modificadas, la documentación de traslados de Google indica que cada destino debe identificarse a sí mismo como canonical. Indicación sobre el canonical
• “When Google encounters the noindex tag, it may skip rendering and JavaScript execution” (traducción) «Cuando Google encuentra la etiqueta noindex, puede omitir el renderizado y la ejecución de JavaScript»_ Google Search Central. Ir a la indicación sobre noindex
• Paráfrasis: Google sigue recomendando el renderizado en servidor o el prerenderizado como una opción de entrega eficiente para usuarios y rastreadores. Indicación sobre el renderizado
• “Be sure to check your structured data using the Rich Results Test during development” (traducción) «Asegúrate de comprobar tus datos estructurados con la prueba de resultados enriquecidos durante el desarrollo». Google Search Central. Ir a la indicación sobre validación

Lista de comprobación para la migración de CMS

Alcance y decisiones

• Se han enumerado todas las capas de cambio: CMS, datos, plantillas, renderizado, arquitectura, URL, infraestructura, analítica e integraciones.
• Se ha aprobado el alcance de URL iguales o modificadas antes de implementar las rutas.
• Se han separado las decisiones de conservar, eliminar y mejorar.
• Se han asignado responsables y criterios de aprobación o rechazo por plantilla.

Inventario y migración

• Se han combinado rastreos, sitemaps, logs, analítica, Search Console, backlinks y feeds.
• Se han inventariado medios, facetas, paginación, búsqueda interna, redirecciones, API y aplicaciones.
• Se ha mapeado cada campo de contenido, relación, taxonomía, locale y estado del flujo de trabajo.
• Se han reconciliado los recuentos de entidades y las URL por tipo de contenido, locale, plantilla y estado.

QA en staging

• Los rastreadores autorizados pueden acceder a staging mientras se impide su descubrimiento público.
• Se han probado el HTML sin procesar y el DOM renderizado en cada plantilla protegida.
• Se han comparado estado, títulos, encabezados, contenido, canonicals, robots, hreflang y schema.
• Se han comparado navegación, breadcrumbs, enlaces relacionados, paginación y enlaces del cuerpo.
• Se han probado facetas, parámetros, búsqueda, resultados vacíos, variantes y errores reales.
• Se han probado URL de medios, metadatos, formatos, incrustaciones y datos estructurados.
• Se han importado, aplanado y probado las redirecciones heredadas.
• Se han probado analítica, consentimiento, formularios, checkout, feeds, API y búsqueda.

Lanzamiento y monitorización

• Se ha ensayado la secuencia final de sincronización y congelamiento de contenido y datos.
• Se ha ensayado el plan de rollback o de roll-forward de la aplicación y de la base de datos.
• Los controles temporales de staging figuran en el libro de eliminación.
• Se ha validado producción en orden sistémico, luego por plantilla y luego por URL.
• Los sitemaps contienen las URL canónicas previstas que responden correctamente.
• La monitorización está segmentada por plantilla, locale, importancia y cohorte de cambio.

El contrato de replatforming

Utilice cuatro libros enlazados:

1. Libro de entidades: cada registro de contenido y cada relación que deba migrar.
2. Libro de URL: cada URL antigua y su resultado igual, movido, consolidado, retirado o excluido.
3. Contrato de plantilla: cada comportamiento de página generada y sus pruebas de aprobación o rechazo.
4. Libro de dependencias: cada feed, integración, recurso, verificación, redirección, tarea y proceso de negocio que la plataforma sostiene.

La migración solo está reconciliada cuando los libros coinciden. Una entidad de contenido sin una URL esperada, o una URL pública sin una entidad propietaria ni un comportamiento deliberado del sistema, necesita revisión.

La matriz de paridad

¿Necesita la migración de CMS un flujo de trabajo de traslado de URL?

Errores de replatforming que generan pérdidas

Elegir las URL después de construir la plataforma. Por qué falla: el enrutamiento, las importaciones, las plantillas, los feeds y las redirecciones se consolidan en torno a valores por defecto accidentales. Haga esto en su lugar: tome la decisión de conservar frente a cambiar antes de la implementación.

Llamar paridad SEO a una coincidencia visual. Por qué falla: el estado, el HTML sin procesar, los canonicals, los robots, los enlaces, el schema, el contenido móvil y los errores pueden diferir detrás del mismo diseño. Haga esto en su lugar: pruebe los contratos de plantilla en las respuestas sin procesar y renderizadas.

Migrar solo el sitemap. Por qué falla: los sitemaps omiten URL huérfanas, redirigidas, heredadas, parametrizadas y de recursos que todavía reciben tráfico o enlaces. Haga esto en su lugar: combine rastreos, logs, analítica, Search Console, backlinks y feeds.

Introducir todas las mejoras en el lanzamiento. Por qué falla: los cambios simultáneos de contenido, arquitectura, renderizado, URL y diseño dificultan el diagnóstico de las regresiones. Haga esto en su lugar: separe los defectos obligatorios de las mejoras posteriores y escalone los cambios cuando sea posible.

Tratar el rollback como un despliegue de código. Por qué falla: las escrituras en el nuevo esquema, los pedidos, las subidas y las ediciones de contenido pueden no sobrevivir a un rollback de la aplicación. Haga esto en su lugar: planifique también la reconciliación de datos y las correcciones hacia adelante.

Fallos habituales del replatforming

Los recuentos de destino son inferiores al inventario de origen

Causa probable: importaciones fallidas, estados excluidos, huecos de locale, tipos de contenido no admitidos o deduplicación de entidades. Solución: reconcilie por tipo de contenido, locale, estado del flujo de trabajo y plantilla en lugar de comparar un único total.

Las páginas devuelven 200 pero pierden contenido en los rastreos

Causa probable: renderizado en cliente, recursos bloqueados, fallos de API, carga solo por interacción o errores de hidratación. Solución: compare el HTML sin procesar y el renderizado, los errores de consola y de red, y la vista renderizada de la herramienta URL Inspection en páginas representativas.

Google selecciona canonicals inesperados

Causa probable: reglas de canonical copiadas, destinos antiguos o de staging, rutas duplicadas, conflictos de enlazado interno, conflictos de sitemap o contenido sustancialmente cambiado. Solución: alinee el canonical de la plantilla, los enlaces directos, las redirecciones y el sitemap con la URL prevista y permita después un nuevo rastreo.

Las páginas de categoría o de producto se convierten en trampas de rastreo

Causa probable: nuevas rutas de facetas, orden de los parámetros, combinaciones infinitas, rutas de calendario o búsqueda interna rastreable. Solución: defina las combinaciones permitidas, enlace solo las páginas útiles, devuelva estados vacíos honestos y aplique controles de canonical o de indexación según el requisito de producto.

Los enlaces heredados empiezan a devolver 404

Causa probable: las redirecciones existían fuera del CMS antiguo o el nuevo motor de reglas cambió el orden. Solución: recopile las reglas de todas las capas antiguas, aplane las cadenas y pruebe el inventario histórico completo de URL.

Los datos estructurados se validan pero describen la entidad equivocada

Causa probable: un mapeo de campos incorrecto o una plantilla que renderiza datos del elemento padre, valores de marcador de posición o caché obsoleta. Solución: compare el marcado con el contenido visible y con los registros de origen. La validación de la sintaxis por sí sola no puede demostrar la exactitud semántica.

Herramientas para el QA de la migración de CMS

• SEO Migration Planner & Validator combina la revisión del mapa, la verificación de redirecciones, el estado de las URL antiguas y la comparación de sitemaps.
• Redirect Map Builder ayuda a revisar los resultados de URL exactos, inciertos, consolidados, sin coincidencia y retirados cuando cambian las rutas.
• Staging vs. Production SEO Diff compara estado, redirecciones, canonicals, directivas, cabeceras seleccionadas, schema y contenido.
• Canonicalization Checker diagnostica las señales de canonical observables en una página representativa.
• Schema Validator comprueba la sintaxis de los datos estructurados y las entidades extraídas; utilice la Rich Results Test de Google para la elegibilidad en las funciones de Google.
• Faceted Navigation Auditor explora los riesgos de rastreo y de parámetros que introducen los nuevos filtros.
• Link Analyzer comprueba los enlaces internos renderizados en plantillas representativas.
• Bulk HTTP Status Code Checker valida las cohortes de URL de destino e históricas después del despliegue.

Demuestre que la migración de CMS se lanzó correctamente

Prueba de reconciliación entre entidades y URL

• Prueba a ejecutar: Una la exportación de entidades de origen, la exportación de entidades de destino, el libro de URL esperadas y el rastreo de destino mediante un ID de contenido estable.
• Resultado esperado: Cada entidad dentro del alcance tiene su estado y su URL aprobados; cada destino público tiene una entidad propietaria o un propósito de sistema documentado.
• Interpretación del fallo: Huecos en la importación, duplicados, colisiones de rutas o estados excluidos han dejado contenido ausente o han creado páginas no previstas.
• Ventana de monitorización: Antes del lanzamiento, tras la sincronización final y después de cualquier reparación de la importación.
• Disparador de rollback: Un tipo de contenido o un locale protegido no puede reconciliarse antes de la decisión de lanzamiento.

Prueba del contrato de plantilla

• Prueba a ejecutar: Rastree y renderice una muestra estratificada de cada plantilla protegida, comparando estado, contenido, metadatos, canonicals, directivas, schema, enlaces, recursos y salida móvil.
• Resultado esperado: Todos los requisitos de conservación se cumplen y cada diferencia corresponde a un cambio intencionado aprobado.
• Interpretación del fallo: Un componente, un mapeo de campos, una ruta o una capa de renderizado está cambiando de forma sistémica la salida visible para la búsqueda.
• Ventana de monitorización: En staging, inmediatamente después del lanzamiento y tras las correcciones de plantilla.
• Disparador de rollback: Una plantilla global o de alto valor pierde indexabilidad, contenido, integridad del canonical o una función crítica y no puede repararse dentro de la ventana.

Prueba de redirecciones y estados de error

• Prueba a ejecutar: Pase cada URL antigua por el Bulk HTTP Status Code Checker o por un rastreador completo y pruebe rutas que se sabe que faltan.
• Resultado esperado: Las URL movidas alcanzan sus equivalentes aprobados mediante una única redirección permanente; las URL conservadas siguen respondiendo correctamente; las URL retiradas devuelven el 404 o 410 previsto.
• Interpretación del fallo: Reglas ausentes, orden incorrecto, cadenas de redirecciones, errores soft 404 o un enrutamiento genérico están ocultando la disposición prevista.
• Ventana de monitorización: En staging cuando sea posible, en la hora del lanzamiento y tras cada cambio de reglas.
• Disparador de rollback: Un fallo sistémico de las reglas deja URL protegidas no disponibles o las envía a destinos irrelevantes.

Ensayo de rollback consciente de los datos

• Prueba a ejecutar: Ejecute el rollback documentado en un ensayo similar a producción, incluidas las escrituras creadas después del cutover.
• Resultado esperado: El código, el esquema, el contenido, los pedidos, las sesiones, las subidas, las colas y las integraciones alcanzan un estado coherente definido, sin pérdidas silenciosas.
• Interpretación del fallo: El plan puede restaurar el software pero no puede reconciliar los datos producidos por la nueva plataforma.
• Ventana de monitorización: Antes del lanzamiento y tras cambios materiales de esquema o de cutover.
• Disparador de rollback: No existe una ruta segura de rollback ni de roll-forward para las escrituras críticas.

Recursos que merecen su tiempo

Mis textos relacionados

• Una migración de sitio web necesita más que una lista de comprobación para tener éxito cubre el proceso compartido del proyecto, el staging, la paridad y la monitorización.
• Redirecciones para SEO cubre la capa de redirecciones que debe transferirse o reconstruirse cuando el replatforming cambia las rutas.

Guías relacionadas en este sitio

• Migraciones de sitios cubre los tipos de migración, los riesgos comunes y el proceso universal.
• Lista de comprobación de migración de sitios ofrece una secuencia lista para el proyecto.
• Lista de comprobación de SEO para rediseño de sitios se aplica cuando cambian las plantillas pero las URL se mantienen estables.
• JavaScript SEO cubre el renderizado y el descubrimiento con más profundidad.

Desde el sector

• Google: Traslado de sitios con cambios de URL
• Google: Conceptos básicos del SEO de JavaScript
• Google: Indexación centrada en móviles
• Google: Datos estructurados
• Bing: Migración de sitios web con Bing
• Bing: IndexNow

Ponga a prueba sus conocimientos: SEO para migración de CMS y replatforming

Cinco preguntas sobre alcance, paridad, renderizado, reconciliación y rollback. Elija una respuesta para cada una y compruebe después.

Registro de cambios