A REST API do WordPress está pública — e é assim que clonam o site

Não é sitemap, não é RSS: é wp-json no ar para o mundo

WordPress documenta a REST API como interface oficial. Desde que entrou no núcleo, leitura de post, página, mídia e, em muitos sites, usuário fica disponível sem cookie. O endereço padrão é `/wp-json/`. A coleção de posts é `/wp-json/wp/v2/posts`. Dá para pedir campo, página, quantidade. Cem itens por página é um pedido comum. Cada item traz título, slug, link, conteúdo em HTML, shortcode, o que o banco tiver no post.

Quem copia site “na unha” ainda pode usar sitemap, feed ou um GET em cada URL. Isso gasta request, quebra layout, perde shortcode. A REST devolve o registro. É o atalho que eu vejo em operação de spam: clonar o site várias vezes e espalhar backlink de qualidade ruim apontando para o domínio original. O seu servidor ainda paga a CPU dessa leitura.

Na gravação eu abri um publisher grande em WordPress — a Capricho, da Abril — e a lista pública estava lá: IDs, títulos, depois o post inteiro com HTML. Se uma redação desse tamanho deixa o endpoint aberto, a maioria dos blogs também deixa. Eu não estou convidando ninguém a clonar o acervo alheio. Estou mostrando que o padrão do CMS é entregar o acervo em JSON.

O que a API devolve, e por que “esconder” o site não resolve

Com a lista de posts você pagina. Com o ID, abre o objeto único. Imagem, categoria, tag, autor: há rotas para quase tudo que o tema já mostra. Na era de agente de código, o passo “leia a REST e monte um site estático” cabe num parágrafo. Antes pedia script. Agora pede paciência de uma geração.

Página pública continua copiável. Bloquear botão direito nunca impediu isso. A REST é pior porque empacota o banco e ainda usa o seu PHP. Restringir leitura anônima fecha o pacote. Não fecha o Print Screen. Não fecha quem baixa o HTML da matéria aberta. Fecha a clonagem industrial barata.

Integração legítima — app, headless, ferramenta de marketing — muitas vezes precisa da REST. Quase sempre precisa de autenticação para escrever. Para ler, o núcleo não exige login. É esse desnível que eu corto: anônimo não lista o acervo; usuário logado e aplicação com credencial seguem falando com a API.

Três jeitos de fechar a leitura anônima

O filtro do núcleo é `rest_authentication_errors`. A lógica oficial de “desligar para quem não está logado” é: se já existe erro, devolva; se a pessoa está logada, deixe passar; senão, devolva um `WP_Error` com 401 ou 403. Isso vai em plugin pequeno ou no `functions.php` de um filho de tema que você controla. Eu, no vídeo, pedi o snippet ao ChatGPT em vez de decorar o gancho. O gancho certo é esse, não um `die()` genérico em `wp-json`.

Se o site já passa pela Cloudflare, uma regra de WAF ou de configuração no `/wp-json*` bloqueia ou desafia o anônimo sem mexer em PHP. Cuidado para não quebrar o próprio painel e o Gutenberg, que falam com a REST autenticada. Exceção para cookie de sessão, ou bloqueio só de GET anônimo, evita sequestro do editor.

Plugin de performance como o Perfmatters expõe a opção de desativar a REST API para visitantes. Outros plugins de “hardening” fazem o mesmo. Prefira um interruptor que você entende: se amanhã um formulário ou um bloco do editor parar, você sabe o que ligou de volta.

1. Abra `/wp-json/wp/v2/posts` numa janela anônima e confirme o JSON.
2. Restrinja a REST a `is_user_logged_in()` via `rest_authentication_errors`.
3. Se usar Cloudflare, crie regra na rota `/wp-json` com exceção para o admin logado.
4. Teste o editor (Gutenberg), o app móvel e qualquer integração que leia post.
5. Reabra a janela anônima: a lista não deve sair. O HTML da matéria pública, sim — e isso é esperado.

Isso não substitui atualizar o WordPress, e eu estou saindo dele

Fechar a REST não é firewall completo. Plugin abandonado, senha fraca, xmlrpc, arquivo de backup no document root: lista antiga. A REST pública é só o item que quase ninguém desliga porque “veio assim”. Eu chutei, no vídeo, que a maior parte dos WordPress da internet está aberta. Não tenho censo. Tenho o padrão de instalação e os publishers que ainda servem `/wp-json` sem login.

Eu estava abandonando WordPress e levando site para Cloudflare quando gravei. A dica permanece para quem fica: menos superfície anônima, menos clone preguiçoso, menos CPU doada para o JSON do spam. Quem precisa de headless de verdade configura autenticação, não deixa o acervo no GET público.

Copiar conteúdo alheio para republicar continua sendo problema de direito autoral, com ou sem API. O que eu quero cortar é a facilidade operacional e o uso do meu servidor como fonte da cópia. O restante é jurídico, não interruptor.

Na sequência

1. Teste `/wp-json/wp/v2/posts` deslogado antes e depois da mudança.
2. Mantenha REST autenticada se o editor ou um app dependem dela.
3. Não bloqueie `/wp-admin` junto com `/wp-json` sem testar Gutenberg.
4. Trate sitemap e RSS como canais menores; a REST é o atalho gordo.
5. Documente a regra da Cloudflare para a próxima pessoa não “corrigir” e reabrir.

Onde isso quebra