SEO de plataformas

TL;DR — La plataforma con la que construyes tu sitio determina tus opciones de SEO antes de que escribas una sola palabra. Algunas plataformas hacen mucho por ti automáticamente; otras te dan un control total, pero dejan más aspectos para que los configures. La diferencia importa sobre todo en el SEO técnico: títulos, canonicals, sitemaps, datos estructurados, robots.txt y renderizado.

Por qué la elección de la plataforma afecta al SEO

La mayoría de los consejos de SEO tratan un sitio web como un lienzo en blanco. En realidad, tu CMS o constructor de sitios web ya ha tomado decenas de decisiones de SEO por ti: la estructura de las URL, cómo se generan los sitemaps, si puedes editar robots.txt, cómo se gestiona la metadata y qué datos estructurados se inyectan automáticamente.

La buena noticia es que la mayoría de las plataformas principales cubren bien los aspectos básicos. Las diferencias aparecen cuando necesitas hacer algo no estándar, corregir un problema técnico específico o escalar a decenas de miles de páginas.

Las cinco categorías

Las plataformas de CMS tradicional (WordPress, Drupal, Joomla, HubSpot CMS, Umbraco, Sitecore) se instalan en tu propio servidor (o en un hosting administrado) y te ofrecen un control profundo sobre cada ajuste de SEO técnico. WordPress, en particular, cuenta con un amplio ecosistema de plugins: Yoast, Rank Math y otros se encargan automáticamente de gran parte del SEO técnico una vez configurados.

Los constructores de sitios web visuales y SaaS (Wix, Squarespace, Webflow, Framer y otros) alojan tu sitio y administran la infraestructura. Gestionan automáticamente HTTPS, CDN, sitemaps y metadata básica, pero la mayoría restringe la configuración del servidor y la estructura de las URL. El acceso a robots.txt varía según el constructor: Wix y Squarespace lo bloquean, mientras que Webflow lo expone directamente en Settings → SEO. Son excelentes para la mayoría de los sitios, pero limitantes en casos especiales.

Un CMS headless (Contentful, Strapi, Sanity, Storyblok, Ghost) separa el lugar donde escribes el contenido de la forma en que se renderiza. El SEO queda totalmente determinado por el renderizador frontend que elijas: SSG y SSR son opciones seguras; CSR exige cuidado. Todo lo que los plugins de WordPress gestionan automáticamente (metadata, sitemaps, canonicals) ahora debes construirlo de forma explícita.

Los frameworks de JavaScript (React, Next.js, Vue, Nuxt, Angular, Astro, Svelte) son entornos de renderizado frontend, no sistemas de gestión de contenidos. Cada uno tiene sus propias implicaciones para el SEO según cómo renderice las páginas: en el servidor, de forma estática durante la compilación o en el navegador. Next.js y Nuxt (metaframeworks) ofrecen el mayor soporte de SEO incorporado.

Las plataformas de ecommerce (Shopify, WooCommerce, Magento, BigCommerce) añaden consideraciones de SEO específicas del ecommerce: datos estructurados de producto, navegación por facetas, paginación, URL duplicadas por variantes y colecciones, y estructuras de URL bloqueadas por la plataforma.

Cómo usar esta sección

Empieza por el hub de la categoría de tu plataforma y después profundiza en el artículo de la plataforma específica. Cada uno explica qué gestiona automáticamente la plataforma, qué restringe y qué particularidades propias suelen causar problemas.

TL;DR — El SEO de plataformas trata en realidad de restricciones y valores predeterminados: ¿qué decide tu plataforma antes de que la toques y cuáles de esas decisiones puedes anular? Las carencias importantes son la arquitectura de renderizado (CSR frente a SSR y SSG), la posibilidad de editar robots.txt, la inyección de datos estructurados, la flexibilidad de la estructura de URL y la cobertura del sitemap. El resto suele poder configurarse con el plugin o la preparación de compilación adecuados.

Evaluación de plataformas para SEO

Al evaluar una plataforma para SEO, estas son las preguntas que importan a escala:

Arquitectura de renderizado — ¿La plataforma sirve HTML prerenderizado o el navegador construye la página con JavaScript? El HTML estático es la opción segura predeterminada. CSR introduce retrasos de renderizado y puede hacer que Googlebot no detecte contenido si no logra ejecutar los scripts. SSR e ISR (regeneración estática incremental) quedan entre ambos: SSR se puede rastrear de forma fiable; ISR puede servir versiones obsoletas a los rastreadores si la ventana de revalidación es demasiado larga.

Control de metadata — ¿Puedes definir etiquetas <title>, <meta description>, Open Graph y canonical únicas para cada página mediante programación? La mayoría de las plataformas modernas puede hacerlo. La restricción suele aparecer en catálogos grandes: ¿puedes crear plantillas de metadata a escala sin desarrollo personalizado?

Datos estructurados — ¿La plataforma inyecta schema automáticamente o hay que hacerlo manualmente? El schema de producto de Shopify depende del tema. WordPress necesita un plugin. Las implementaciones headless requieren una configuración explícita.

robots.txt y control de rastreo — ¿Puedes editar robots.txt directamente? La mayoría de las plataformas lo permiten: Shopify admite la personalización en cualquier plan mediante una plantilla de tema robots.txt.liquid, y Webflow la ofrece de forma nativa en Settings → SEO. Wix y Squarespace son las excepciones más restrictivas. En la mayoría de los sitios no importa; en los sitios complejos siguen importando las diferencias en cuánto puedes anular.

Estructura de URL — ¿Puedes personalizar la ruta o la impone la plataforma? El prefijo /products/ de Shopify es fijo. La mayoría de las plataformas de CMS tradicional te ofrecen un control total.

Sitemap — ¿Se genera automáticamente, se mantiene de forma manual o mediante un plugin? ¿Qué se incluye? ¿Puedes excluir páginas o tipos de entrada específicos?

Riesgo de migración — Cambiar de plataforma durante la vida del sitio implica cambios de URL y el riesgo de redirecciones rotas. Presupuesta un mapa de redirecciones y un rastreo completo posterior a la migración, independientemente de la plataforma.

Comparación del SEO de plataformas por restricción

El SEO de plataformas consiste en entender qué hace automáticamente por ti tu CMS o constructor de sitios web y qué debes configurar manualmente. Cada plataforma toma decisiones de SEO técnico antes de que la toques: método de renderizado, estructura de URL, generación del sitemap, gestión de metadata y control de robots.txt.

CMS tradicional (WordPress, Drupal, Joomla, HubSpot CMS, Umbraco, Sitecore): control total sobre todos los ajustes de SEO. WordPress tiene el ecosistema de plugins más amplio para automatizar el SEO. Requiere más mantenimiento, pero es la opción más flexible.

Constructores de sitios web SaaS (Wix, Squarespace, Webflow, Framer, Weebly, Duda): gestionan automáticamente HTTPS, CDN, sitemaps básicos y metadata. La mayoría restringe la estructura de las URL y la configuración del servidor; el acceso a robots.txt varía (Webflow: edición total; Wix/Squarespace: bloqueado). Son adecuados para la mayoría de los sitios.

CMS headless (Contentful, Strapi, Sanity, Storyblok, Ghost): el SEO depende por completo del framework frontend elegido. Usa SSG o SSR; evita CSR. Todo el SEO gestionado mediante plugins (sitemaps, canonicals, metadata) debe construirse de forma explícita.

Frameworks de JavaScript (React, Next.js, Vue, Nuxt, Angular, Astro, Svelte): el SEO varía según el modo de renderizado. Next.js y Nuxt tienen un sólido soporte incorporado de SSR/SSG. React/Vue puro en modo CSR necesita prerenderizado o SSR para una indexación fiable.

Plataformas de ecommerce (Shopify, WooCommerce, Magento, BigCommerce): añaden problemas específicos de SEO para ecommerce: schema de producto, navegación por facetas, URL duplicadas por colecciones y variantes, paginación y estructuras de URL bloqueadas por la plataforma.

Framework de selección de plataforma para SEO

Paso 1 — Identifica tu restricción de renderizado

• El contenido que debe posicionarse → necesita SSR o SSG (HTML estático entregado a los rastreadores)
• Solo CSR → prerenderiza las páginas fundamentales o cambia a SSR/SSG
• ISR → establece ventanas de revalidación cortas para el contenido que cambia con frecuencia

Paso 2 — Audita los valores predeterminados de la plataforma

• ¿Qué genera automáticamente la plataforma? (sitemap, canonicals, datos estructurados)
• ¿Qué está bloqueado o no se puede configurar? (robots.txt, estructura de URL, acceso a <head>)
• ¿Qué requiere un plugin o código personalizado?

Paso 3 — Asocia tus requisitos de SEO con las capacidades de la plataforma

• ¿Plantillas de metadata a escala?
• ¿Tipos de datos estructurados personalizados?
• ¿Navegación por facetas o gestión de parámetros?
• ¿Hreflang para sitios internacionales?
• ¿Acceso a archivos de registro para analizar el rastreo?

Paso 4 — Evalúa el coste de la migración

• Estructura de URL actual → ¿puedes conservarla o necesitas redirecciones?
• ¿Infraestructura de redirecciones en la plataforma nueva?
• ¿Plan de supervisión posterior a la migración?

Lista de comprobación para migrar de plataforma

• Exporta todas las URL actuales (rastreo o sitemap)
• Asocia las URL antiguas → nuevas; marca las que cambien
• Implementa redirecciones 301 para cada URL modificada
• Define las etiquetas canonical antes del lanzamiento
• Envía el sitemap nuevo a Search Console
• Rastrea el entorno de staging para verificar el renderizado, los títulos, la metadata y los canonicals
• Supervisa los errores de rastreo y la cobertura del índice durante 4–6 semanas tras el lanzamiento
• Comprueba Core Web Vitals en la plataforma nueva (CDN y gestión de imágenes suelen variar)

Análisis detallados por plataforma

• SEO para WordPress
• SEO para Shopify
• SEO para Webflow
• SEO para CMS headless
• SEO para Next.js

Registro de cambios