SEO de plataformas

TL;DR — A plataforma em que você cria seu site define suas opções de SEO antes de você escrever uma única palavra. Algumas plataformas fazem muita coisa por você automaticamente; outras dão controle total, mas deixam mais configurações a seu cargo. A diferença importa sobretudo para o SEO técnico — títulos, canonicals, sitemaps, dados estruturados, robots.txt e renderização.

Por que a escolha da plataforma afeta o SEO

A maior parte das recomendações de SEO trata o site como uma tela em branco. Na realidade, seu CMS ou construtor de sites já tomou dezenas de decisões de SEO por você — a estrutura de URL, como os sitemaps são gerados, se você pode editar robots.txt, como os metadados são tratados e quais dados estruturados são inseridos automaticamente.

A boa notícia é que a maioria das plataformas importantes cobre bem o básico. As diferenças aparecem quando você precisa fazer algo fora do padrão, corrigir um problema técnico específico ou escalar para dezenas de milhares de páginas.

As cinco categorias

Plataformas CMS tradicionais (WordPress, Drupal, Joomla, HubSpot CMS, Umbraco e Sitecore) são instaladas no seu próprio servidor (ou em um host gerenciado) e dão controle profundo sobre cada configuração de SEO técnico. O WordPress, em particular, tem um ecossistema rico de plugins — Yoast, Rank Math e outros cuidam da maior parte do SEO técnico automaticamente depois de configurados.

Construtores visuais e SaaS de sites (Wix, Squarespace, Webflow, Framer e outros) hospedam seu site e gerenciam a infraestrutura. Eles lidam automaticamente com HTTPS, CDN, sitemaps e metadados básicos, mas em geral restringem a configuração no servidor e a estrutura de URL. O acesso a robots.txt varia: Wix e Squarespace o bloqueiam, enquanto Webflow o expõe diretamente em Settings → SEO. São ótimos para a maioria dos sites, mas limitantes em casos extremos.

CMS headless (Contentful, Strapi, Sanity, Storyblok, Ghost) separa o local onde você escreve o conteúdo de como ele é renderizado. O SEO é determinado inteiramente pela camada de frontend que você escolher — SSG e SSR são opções seguras; CSR exige cuidado. Tudo que os plugins do WordPress tratam automaticamente (metadados, sitemaps, canonicals) agora precisa ser criado de forma explícita.

Frameworks JavaScript (React, Next.js, Vue, Nuxt, Angular, Astro, Svelte) são ambientes de renderização de frontend, não sistemas de gerenciamento de conteúdo. Cada um tem implicações próprias de SEO conforme renderiza as páginas — no servidor, estaticamente no build ou no navegador. Next.js e Nuxt (meta-frameworks) têm o suporte de SEO integrado mais completo.

Plataformas de comércio eletrônico (Shopify, WooCommerce, Magento, BigCommerce) acrescentam preocupações de SEO específicas de comércio: dados estruturados de produtos, navegação facetada, paginação, URLs duplicadas de variantes e coleções e estruturas de URL impostas pela plataforma.

Como usar esta seção

Comece pelo hub da categoria da sua plataforma e depois aprofunde-se no artigo específico. Cada um explica o que a plataforma trata automaticamente, o que ela restringe e quais particularidades específicas costumam causar problemas.

TL;DR — SEO de plataformas trata, na prática, de restrições e padrões: o que sua plataforma decide antes de você tocá-la e quais dessas decisões podem ser substituídas? As lacunas importantes são a arquitetura de renderização (CSR, SSR ou SSG), a possibilidade de editar robots.txt, a inserção de dados estruturados, a flexibilidade da estrutura de URL e a cobertura do sitemap. O restante costuma ser configurável com o plugin ou setup de build adequado.

Avaliando plataformas para SEO

Ao avaliar uma plataforma para SEO, estas são as perguntas que importam em escala:

Arquitetura de renderização — A plataforma entrega HTML pré-renderizado ou o navegador cria a página com JavaScript? HTML estático é o padrão seguro. CSR introduz atrasos de renderização e pode fazer o Googlebot perder conteúdo se houver falha na execução dos scripts. SSR e ISR (regeneração estática incremental) ficam no meio — SSR é rastreável de forma confiável; ISR pode entregar versões desatualizadas a rastreadores se a janela de revalidação for longa demais.

Controle de metadados — Você consegue definir <title>, <meta description> únicos, Open Graph e tags canonical programaticamente para cada página? A maioria das plataformas modernas consegue. A restrição geralmente aparece em catálogos grandes: dá para criar templates de metadados em escala sem desenvolvimento personalizado?

Dados estruturados — A plataforma injeta o schema automaticamente ou isso é manual? O schema de produto do Shopify depende do tema. O WordPress precisa de um plugin. Em setups headless, a implementação explícita é obrigatória.

robots.txt e controle de rastreamento — Você pode editar robots.txt diretamente? A maioria das plataformas permite: o Shopify oferece personalização em qualquer plano por meio de um template de tema robots.txt.liquid, e o Webflow o expõe nativamente em Settings → SEO. Wix e Squarespace são a exceção mais restritiva. Para a maioria dos sites isso não importa; em sites complexos, ainda faz diferença quanto você consegue substituir.

Estrutura de URL — Você pode personalizar o caminho ou ele é imposto pela plataforma? O prefixo /products/ do Shopify é fixo. A maioria das plataformas CMS tradicionais dá controle total.

Sitemap — Ele é gerado automaticamente, mantido à mão ou produzido por plugin? O que é incluído — você consegue excluir páginas ou tipos de post específicos?

Risco de migração — Mudar de plataforma no meio da vida do site significa alterar URLs e correr o risco de quebrar redirecionamentos. Reserve tempo para um mapa de redirecionamentos e um rastreamento completo pós-migração, qualquer que seja a plataforma.

Comparação de SEO de plataformas por restrição

SEO de plataformas é entender o que seu CMS ou construtor de sites faz automaticamente em comparação com o que você precisa configurar manualmente. Toda plataforma toma decisões de SEO técnico antes de você tocá-la — método de renderização, estrutura de URL, geração de sitemap, tratamento de metadados e controle de robots.txt.

CMS tradicional (WordPress, Drupal, Joomla, HubSpot CMS, Umbraco, Sitecore): controle total sobre as configurações de SEO. O WordPress tem o ecossistema de plugins mais rico para automação de SEO. É mais pesado de manter, mas mais flexível.

Construtores SaaS de sites (Wix, Squarespace, Webflow, Framer, Weebly, Duda): tratam HTTPS, CDN, sitemaps básicos e metadados automaticamente. A maioria restringe a estrutura de URL e a configuração no servidor; o acesso a robots.txt varia (Webflow: edição total; Wix/Squarespace: bloqueado). São adequados para a maioria dos sites.

CMS headless (Contentful, Strapi, Sanity, Storyblok, Ghost): o SEO depende inteiramente do framework de frontend escolhido. Use SSG ou SSR; evite CSR. Todo SEO tratado por plugins (sitemaps, canonicals, metadados) precisa ser criado explicitamente.

Frameworks JavaScript (React, Next.js, Vue, Nuxt, Angular, Astro, Svelte): o SEO varia conforme o modo de renderização. Next.js e Nuxt têm suporte SSR/SSG integrado forte. React/Vue puro em modo CSR exige pré-renderização ou SSR para uma indexação confiável.

Plataformas de comércio eletrônico (Shopify, WooCommerce, Magento, BigCommerce): acrescentam preocupações específicas — schema de produto, navegação facetada, URLs duplicadas de coleções e variantes, paginação e estruturas de URL impostas pela plataforma.

Framework de seleção de plataformas para SEO

Etapa 1 — Identifique sua restrição de renderização

• Conteúdo que precisa ranquear → exige SSR ou SSG (HTML estático entregue aos rastreadores)
• Apenas CSR → pré-renderize páginas críticas ou mude para SSR/SSG
• ISR → defina janelas curtas de revalidação para conteúdo que muda com frequência

Etapa 2 — Audite os padrões da plataforma

• O que a plataforma gera automaticamente? (sitemap, canonicals, dados estruturados)
• O que é bloqueado/não configurável? (robots.txt, estrutura de URL, acesso ao <head>)
• O que exige um plugin ou código personalizado?

Etapa 3 — Mapeie seus requisitos de SEO para os recursos da plataforma

• Templates de metadados em escala?
• Tipos personalizados de dados estruturados?
• Navegação facetada / tratamento de parâmetros?
• Hreflang para internacionalização?
• Acesso a arquivos de log para análise de rastreamento?

Etapa 4 — Avalie o custo da migração

• Estrutura de URL atual → você pode preservá-la ou precisa de redirecionamentos?
• Infraestrutura de redirecionamento na nova plataforma?
• Plano de monitoramento pós-migração?

Checklist de migração de plataforma

• Exporte todas as URLs atuais (rastreamento ou sitemap)
• Mapeie URLs antigas → novas; marque as que mudarem
• Implemente redirecionamentos 301 para cada URL alterada
• Defina as tags canonical antes do lançamento
• Envie o novo sitemap ao Search Console
• Rastreie o staging para verificar renderização, títulos, metadados e canonicals
• Monitore erros de rastreamento e cobertura de índice por 4–6 semanas após o lançamento
• Verifique Core Web Vitals na nova plataforma (CDN e tratamento de imagens costumam variar)

Guias aprofundados por plataforma

• WordPress SEO
• Shopify SEO
• Webflow SEO
• Headless SEO de CMS
• Next.js SEO

Registro de alterações