WordPress Full Site Editing en 2026: La guía para migrar sin perder SEO ni velocidad

Con WordPress 6.8 y los temas de bloques como estándar, seguir en un tema clásico en 2026 ya no es una decisión neutral: te estás quedando fuera de mejoras de rendimiento, del editor visual completo y de la dirección que está tomando todo el ecosistema de plugins. Pero migrar mal a Full Site Editing (FSE) puede costarte posiciones y velocidad si no lo haces con orden.

Esta es la guía que sigo en cada migración, pensada para no perder nada en el camino.

Antes de tocar nada: auditoría previa

• Exporta un listado completo de URLs indexadas (Search Console → Páginas, o un crawl con Screaming Frog).
• Documenta tus Core Web Vitals actuales — vas a necesitar este baseline para comparar después de la migración.
• Identifica shortcodes, widgets personalizados y funcionalidades del tema clásico que dependan de PHP específico del theme (muchas veces se pierden si no las migras a bloques o patrones equivalentes).
• Haz un backup completo (base de datos + archivos) antes de instalar nada nuevo.

El entorno de staging es no negociable

Nunca migres en producción directamente. Clona el sitio a un staging (la mayoría de hostings modernos lo ofrecen con un clic), y haz ahí todo el trabajo de theme, bloques y patrones. Solo cuando el staging pasa las mismas pruebas de velocidad y funcionalidad que el sitio en vivo, promuévelo a producción.

Mapeo de redirects

Si al migrar cambias estructura de URLs (pasar de un page builder con URLs propias a la estructura nativa de FSE, por ejemplo), necesitas un mapa 1:1 de redirects 301 antes del lanzamiento, no después. Cada URL indexada que cambie de dirección sin redirect es tráfico y autoridad que se pierde.

Construcción del tema de bloques

• Empieza por el theme.json: ahí defines paleta de colores, tipografía y espaciados de forma centralizada, en vez de repetir estilos en cada bloque.
• Usa patrones de bloques (block patterns) para las secciones que se repiten (hero, footer, CTAs) en lugar de reconstruir cada página desde cero.
• Revisa que las plantillas de single.html y archive.html mantengan la misma información estructurada (autor, fecha, categorías) que tenías antes — es fácil perder esto en la migración visual y afecta directamente al SEO.

Pruebas antes de lanzar

1. Compara Core Web Vitals del staging contra el baseline que documentaste al inicio.
2. Verifica que todos los datos estructurados (schema) sigan generándose correctamente — muchos plugins de SEO necesitan reconfigurarse tras un cambio de tema.
3. Revisa que los formularios, botones de WhatsApp y integraciones de terceros sigan funcionando igual.
4. Haz un crawl del staging y compara el conteo de páginas indexables contra el sitio original.

Checklist post-migración

• Redirects 301 verificados uno por uno en las URLs de mayor tráfico
• Sitemap XML regenerado y reenviado en Search Console
• Core Web Vitals iguales o mejores que antes de migrar
• Schema markup validado sin errores
• Monitoreo diario de Search Console durante las primeras dos semanas

FSE no es solo un cambio de editor, es una oportunidad para limpiar años de código heredado de page builders pesados. Bien hecho, sales con un sitio más rápido y más fácil de mantener. Mal hecho, pierdes meses de posicionamiento por errores que se pudieron prevenir con un checklist como este.