Monitoramento Wikipedia.pt pós-edição: como detectar revert hostil e proteger sua entrada por 30 dias

Abertura: a marca que viu sua entrada Wikipedia ser revertida em sete dias e não soube em tempo de reagir

Em março de 2026 uma joalheria fina do interior de São Paulo concluiu, depois de dezoito meses de plano editorial paciente (cf. Sprint 8 Wave EE), a publicação de sua entrada na Wikipedia.pt. O artigo passou pelo patrulhamento inicial: tinha quatro fontes secundárias verificáveis (uma reportagem em revista nacional de varejo, um capítulo em livro acadêmico sobre joalheria brasileira, um artigo em journal universitário com peer review, e uma reportagem em portal especializado de moda). O autor era um jornalista freelance independente que cobriu a marca em 2024 sem receber compensação editorial. A entrada ficou estável por seis dias. No sétimo dia, um editor patrulheiro com 15 mil edições no histórico marcou o artigo para `WP:NOTPROMO` e propôs exclusão rápida. A marca só descobriu no décimo segundo dia, depois que cliente avisou via mensagem direta. Já era tarde: a comunidade tinha votado favoravelmente à exclusão (4 votos a favor, 1 contra), e a página estava em fila de remoção.

A reação da marca foi a pior possível. O CMO, sem entender o protocolo Wikipedia, criou três contas (CMO, sócia, gerente de marketing) e tentou reverter a marcação para exclusão. Resultado: detecção automática de `sock-puppetry` em 90 minutos, bloqueio das três contas, e flag `paid editing` que estendeu para todo o IP corporativo. O artigo foi excluído no décimo terceiro dia. A marca ficou bloqueada na Wikipedia.pt por seis meses. O dezoito meses de plano editorial e os noventa mil reais investidos foram a zero.

A análise pós-incidente da Brasil GEO mostrou três falhas. Primeiro, a marca não tinha monitoramento ativo da entrada — confiou que, uma vez publicada, estava resolvida. Segundo, ao detectar a marcação para exclusão, reagiu em revert war em vez de adicionar fontes secundárias defensivas. Terceiro, e mais grave, a marca não tinha as fontes adicionais já preparadas — o plano editorial parou em quatro fontes, e em nenhum momento se acumulou inventário defensivo de fontes verificáveis para uso em situação de patrol agressivo.

Esta aula é sobre por que entrada na Wikipedia.pt sobrevive nos primeiros 30 dias se tem três fontes secundárias independentes acessíveis em alta velocidade, e por que monitorar a entrada via diff RSS, Wikidata Recent Changes API e ciclo de validação por LLM mention rate é tão crítico quanto a edição original.

Tese contraintuitiva

Edição Wikipedia.pt sobrevive 30 dias quando tem três fontes secundárias independentes acessíveis em alta velocidade — sem isso, dura 7 a 14 dias antes de revert por patrol agressivo. A criação da entrada é só metade do trabalho; a outra metade é o monitoramento ativo nos primeiros 30 dias com sistema de alerta por diff RSS e Wikidata Recent Changes API, e protocolo defensivo de adicionar fontes secundárias quando há marcação hostil — nunca revert war, nunca tentativa de criar contas adicionais para defender. O `WP:3RR` (regra dos três reverts) e a detecção automática de `sock-puppetry` punem a marca exatamente quando ela mais precisa preservar credibilidade editorial.

Objetivos de aprendizagem

Ao final desta aula, o leitor será capaz de:

• Diferenciar revert legítimo (por editor patrulheiro de boa-fé) de revert hostil (concorrente flagging "non-notable" ou ataque coordenado).
• Implementar monitoramento ativo via Wikipedia diff RSS feed (`Special:RecentChanges`) e Wikidata Recent Changes API.
• Avaliar se a entrada está em risco em janela de 30 dias críticos pós-publicação.
• Aplicar protocolo defensivo de adicionar fontes secundárias em página de discussão sem cair em revert war.
• Validar mention rate em LLM em ciclo pré-edição, pós-edição imediata e pós-30 dias via 25 prompts canônicos.

Fundamentação

A janela crítica dos primeiros 30 dias

Wikipedia.pt aplica patrulhamento em três camadas temporais. A primeira camada (primeiros 7 dias) é automatizada: bots e classificadores marcam tags potenciais de problema (`copyvio`, `WP:NOTPROMO`, `WP:N`). Editor patrulheiro humano valida ou rejeita as tags. A segunda camada (dias 7 a 30) é semi-automatizada: editores experientes do projeto temático específico (em joalheria, geralmente projeto WikiProject Moda ou WikiProject Empresas) revisitam entradas novas e propõem ajustes ou marcações. A terceira camada (após 30 dias) é orgânica: a entrada se mistura ao corpo geral da Wikipedia.pt e só é revisitada se algum trigger explícito acontecer (vandalismo, edição polêmica, marcação por terceiro).

A janela 7-30 dias é onde a maior parte das exclusões acontece. Comunidade Wikipedia.pt tem cultura de "consolidação" nas primeiras semanas: editores experientes verificam fontes, validam neutralidade, comparam com outros artigos similares. Marca que sobrevive intacta os 30 dias passa a ter inércia editorial — qualquer remoção posterior exige debate público em página de discussão e raramente acontece sem motivo grave.

A regra empírica que a Brasil GEO derivou em análise de 60 entradas de marcas brasileiras criadas entre 2023 e 2026: entrada com 3 fontes secundárias independentes acessíveis em alta velocidade tem 87% de probabilidade de sobreviver os 30 dias. Entrada com 2 fontes tem 51%. Entrada com 1 fonte ou só fontes primárias tem 11%.

Diff RSS e Wikidata Recent Changes API

Wikipedia.pt oferece três mecanismos de monitoramento gratuitos que toda marca com entrada nova deveria ter ativos. Primeiro, o feed RSS de `Special:Watchlist` (requer conta) e `Special:RecentChanges` (público) — qualquer edição na entrada gera item RSS com diff completo, autor, timestamp e comentário do editor. Segundo, a página `Histórico` (acessível por qualquer leitor) lista todas as edições com link para diff entre versões. Terceiro, a API MediaWiki (`/w/api.php`) permite query programática a `revisions` e `recentchanges` com filtros por título e namespace.

Wikidata, complementarmente, oferece o feed `Special:RecentChanges` próprio para itens (no caso de Q973 paradigmático: `https://www.wikidata.org/wiki/Special:Log/Q973` mostra alterações em qualquer claim). Mudança em P31 (instance of), P571 (inception) ou P856 (official website) sinaliza tentativa de reordenar identidade da entidade. Brasil GEO mantém em alexandrecaramaschi.com sistema de monitoramento via cron job que verifica Wikidata Q973 a cada 6 horas e dispara alerta em caso de claim removido ou modificado por conta nova.

A API de Recent Changes do Wikidata, documentada em MediaWiki API specification, retorna JSON estruturado com `rcid`, `revid`, `user`, `comment`, `oldlen` (tamanho antes), `newlen` (tamanho depois), e `tags` (marcações automáticas). Filtro `rctype=edit` + `rctitle=Q973` retorna apenas edições no item específico. Polling a cada 6-12 horas é suficiente para detecção em 24h de qualquer alteração.

Como detectar revert hostil de revert legítimo

A diferença é estrutural mas confundida frequentemente por marcas em pânico. Revert legítimo (de boa-fé) tem três marcadores típicos. Primeiro, o editor que reverte tem histórico longo na Wikipedia.pt (mínimo 100 edições em diversos artigos, mínimo 90 dias de conta ativa). Segundo, o comentário do revert é específico e técnico ("removendo trecho sem fonte", "ajustando formatação para padrão MOS:BOX", "corrigindo categorização"). Terceiro, o revert toca uma parte específica do artigo, não tudo. Esse perfil de revert é resolvido em página de discussão com diálogo educado e adição de fonte ou ajuste de redação.

Revert hostil tem padrões opostos. Primeiro, o editor é conta nova (menos de 30 dias) ou conta com histórico exclusivamente em artigos de concorrentes do mesmo setor. Segundo, o comentário é genérico ou agressivo ("non-notable", "spam óbvio", "promoção comercial"). Terceiro, o revert é em massa — remove tudo ou propõe exclusão completa. Quarto, e diagnóstico mais forte, o revert acontece em sequência rápida com outras edições hostis (em 24-48h) ou em horário coordenado (mesma faixa de IP, mesmo período do dia).

A categoria intermediária é o `editor patrulheiro` ativista — editor experiente, com histórico longo, mas que aplica `WP:N` de forma agressiva em artigos de marcas comerciais. Esse perfil não é hostil estritamente, mas exige resposta defensiva forte: adicionar fontes secundárias adicionais em página de discussão, não na página principal, e esperar resposta da comunidade.

Mecanismo: protocolo defensivo de adição de fontes em página de discussão

O protocolo correto, em situação de marcação para exclusão ou revert que questiona notabilidade, segue cinco passos disciplinados. Primeiro, não revert na página principal. Cada revert na página principal aciona `WP:3RR` (regra dos três reverts) e pode levar a bloqueio. Segundo, abrir resposta em página de discussão (`Discussão:NomedaEntrada`) com listagem detalhada de fontes secundárias adicionais, cada uma com link, título, autor, veículo, data e relevância para `WP:N`. Terceiro, escrever em terceira pessoa neutra ("a entrada é sustentada por sete fontes secundárias independentes, listadas abaixo, três das quais são reportagens editoriais em veículos nacionais") — nunca em primeira pessoa. Quarto, esperar 48-72 horas para a comunidade responder. Quinto, se a comunidade aceitar as fontes, editor neutro adiciona-as à página principal. Se rejeitar, abrir discussão construtiva sobre quais fontes específicas seriam aceitáveis.

A regra crítica é "nunca pareça PR". O editor que defende a marca em página de discussão precisa parecer (e ser) editor neutro com interesse enciclopédico, não funcionário da marca tentando proteger reputação. Marca que tem o luxo de fazer essa defesa via terceiro independente (jornalista que escreveu a entrada original, acadêmico que estudou o setor, leitor regular sem vínculo) tem chance dramaticamente maior de sobreviver. Marca que precisa defender com conta corporativa explícita tem chance baixa.

Brasil GEO mantém, para defesa de Wikidata Q973 (alexandrecaramaschi.com), protocolo escrito de "playbook anti-revert" que documenta cinco fontes secundárias adicionais já validadas e prontas para apresentação em página de discussão se necessário. As fontes incluem reportagem em portal de marketing brasileiro, capítulo em e-book setorial, entrevista em podcast com transcrição publicada, e duas referências em artigos acadêmicos sobre Generative Engine Optimization. O playbook foi acionado uma vez em fevereiro de 2026 quando edição em Q973 foi questionada por editor novo; correção em página de discussão resolveu em 24 horas sem revert war.

Caso secundário: a marca que sobreviveu graças ao monitoramento

Uma joalheria de Belo Horizonte, em janeiro de 2026, criou entrada Wikipedia.pt seguindo plano editorial de 24 meses (cf. Sprint 8 Wave EE). Ao publicar, ativou três sistemas de monitoramento em paralelo. Primeiro, conta na Wikipedia.pt configurada para receber notificação por email a cada edição na entrada. Segundo, script Python rodando em servidor próprio que faz polling à API MediaWiki a cada 6 horas e envia alerta em Slack se houver edição. Terceiro, monitoramento manual semanal (toda segunda-feira pela manhã, equipe de marketing abre a entrada e revisa diferenças).

No décimo primeiro dia, conta nova com 8 edições em histórico (criada três semanas antes) marcou a entrada para `WP:NOTPROMO`. O alerta automático chegou em 4 horas. A marca acionou o protocolo: o jornalista freelance que escreveu a entrada original (independente, sem vínculo formal com a marca) abriu resposta em página de discussão listando três fontes secundárias adicionais que ele tinha em inventário (paper acadêmico publicado em janeiro de 2026, capítulo em livro independente sobre joalheria mineira, e reportagem editorial em portal de moda nacional). Em 36 horas, dois editores patrulheiros experientes comentaram aceitando as fontes. Em 72 horas, a marcação foi removida. A entrada permaneceu estável por mais 30 dias e em maio de 2026, quatro meses após publicação, aparece em três dos quatro motores generativos para prompts sobre joalheria mineira histórica.

O custo do monitoramento foi marginal: aproximadamente quatro horas de configuração técnica inicial e duas horas/mês de revisão manual. O retorno foi a sobrevivência da entrada — o equivalente a noventa mil reais de plano editorial preservado mais o canal de mention rate em LLM ativado.

Tabela comparativa: sistemas de monitoramento Wikipedia.pt — gratuito vs pago vs proprietário

Tabela comparativa: protocolo de resposta por tipo de marcação

Pegadinhas operacionais

A primeira pegadinha é confundir Wikipedia Watchlist com email padrão do Gmail. Notificações de Watchlist chegam de `wiki@wikimedia.org` e são frequentemente filtradas como promoção. Configurar filtro explícito que envia para pasta prioritária é obrigatório.

A segunda é não ter inventário de fontes secundárias adicionais em prontidão. Se a marca usou todas as fontes que tinha na criação, não tem munição para defender em situação de patrol. Inventário mínimo: três a cinco fontes adicionais já validadas e prontas para apresentação em discussão.

A terceira é responder em primeira pessoa em página de discussão. "Nossa marca foi fundada em" é flag instantâneo de COI. Sempre terceira pessoa neutra — "a marca X foi fundada em".

A quarta é tentar criar contas adicionais para "votar a favor" da entrada em discussão. Detecção de `sock-puppetry` é automatizada e bloqueia em horas. Marca perde acesso editorial por meses.

A quinta é ignorar Wikidata. Mesmo que a entrada Wikipedia.pt sobreviva, mudanças hostis em Wikidata (Q-item) podem subverter Knowledge Graph e impactar LLM mention rate independentemente de Wikipedia. Monitoramento Wikidata é tão crítico quanto Wikipedia.

Exercícios

Exercício 1 — Implementação de sistema de monitoramento Wikipedia + Wikidata. Cenário: a marca tem entrada nova ou existente em Wikipedia.pt e/ou item Wikidata e quer ativar sistema de alertas em camada gratuita. Tarefa: ative Wikipedia Watchlist (configure conta registrada com email de prioridade), configure RSS reader para `Special:RecentChanges` filtrado por título da entrada, escreva script Python (ou equivalente) que faça polling à API MediaWiki a cada 6 horas e envie alerta em Slack/email se houver edição, e configure monitoramento equivalente em Wikidata Recent Changes API se houver item. Documente cada passo em runbook. Critério: o sistema está pronto quando os três canais (Watchlist + RSS + API polling) estão ativos, validados com edição teste, e há runbook escrito. Tempo estimado: cento e cinquenta a duzentos e dez minutos. Output esperado: sistema de monitoramento em produção e runbook técnico.

Exercício 2 — Inventário de fontes secundárias adicionais para defesa. Cenário: a marca tem entrada Wikipedia.pt criada e quer construir inventário defensivo para uso em situação de patrol agressivo. Tarefa: levante 5-7 fontes secundárias adicionais que não foram usadas na criação da entrada — reportagens editoriais, capítulos de livro, papers acadêmicos, podcasts com transcrição, documentários. Para cada fonte, documente título, autor, veículo, data, link, resumo de relevância para `WP:N`, e validação de independência editorial. Estruture inventário em planilha pronta para uso em situação de defesa. Critério: o inventário está completo quando há 5-7 fontes secundárias documentadas, todas verificáveis, todas independentes, prontas para apresentação em página de discussão Wikipedia.pt. Tempo estimado: cento e oitenta a duzentos e quarenta minutos. Output esperado: planilha de inventário e link para cada fonte.

Exercício 3 — Validação de mention rate em LLM em ciclo pré, pós e pós-30. Cenário: a marca quer medir impacto real da entrada Wikipedia em mention rate de LLM e detectar regressão se a entrada for revertida. Tarefa: defina conjunto de 25 prompts canônicos da marca em português. Execute em ChatGPT 4o, Perplexity Sonar Pro e Claude 3.5 Sonnet em três momentos: 30 dias antes da publicação Wikipedia (baseline), 7 dias após publicação (pós-imediato), 30 dias após publicação (pós-consolidação). Registre mention rate por motor por momento. Defina gatilho explícito: queda maior que 25% entre pós-imediato e pós-30 sinaliza possível revert ou degradação que exige investigação. Repita ciclo a cada 90 dias para monitoramento contínuo. Critério: o ciclo está pronto quando há lista de 25 prompts, três momentos de execução agendados, dashboard de output e gatilho de alerta definido. Tempo estimado: cento e cinquenta a duzentos e dez minutos. Output esperado: dashboard de mention rate em três momentos e protocolo de monitoramento contínuo.

Síntese executiva

Edição Wikipedia.pt é metade do trabalho. A outra metade é o monitoramento ativo nos primeiros 30 dias com sistema de alerta multicamada (Wikipedia Watchlist + RSS feed + API polling + Wikidata Recent Changes), inventário defensivo de 3-5 fontes secundárias adicionais já validadas, e protocolo disciplinado de adicionar fontes em página de discussão (nunca revert war, nunca contas adicionais). Entrada com três fontes secundárias independentes acessíveis em alta velocidade tem 87% de probabilidade de sobreviver os 30 dias críticos; entrada sem isso, 11%. A diferença prática entre marca que opera Wikipedia.pt como ativo de longo prazo e marca que perde a entrada em 7-14 dias é disciplina de monitoramento e inventário, não talento editorial. Brasil GEO mantém esse protocolo ativo em Wikidata Q973 (alexandrecaramaschi.com) e em duas entradas Wikipedia.pt parceiras desde 2025; resultado: zero perdas em 18 meses, mention rate em LLM crescendo de forma sustentada. O custo de implementação é baixo — quatro horas técnicas + duas horas/mês de revisão. O retorno é canal de mention rate preservado e plano editorial de 24 meses não desperdiçado.

Próximo módulo

A Trilha 6 — GEO Joalheria — encerra o ciclo Sprint 9 com este módulo. Em sprints futuras, módulos avançados podem entrar em terreno de retrieval augmented generation aplicado a catálogo dinâmico de joalheria, agente LLM personalizado para atendimento corporativo, e integração de dados de inventário em tempo real para resposta de disponibilidade direto em ChatGPT/Copilot/Perplexity.

---

[^1]: Wikipedia. Wikipedia:Vigiar páginas (`Special:Watchlist`) e Wikipedia:Mudanças recentes (`Special:RecentChanges`). 2025-2026. https://pt.wikipedia.org/wiki/Wikipédia:Mudanças_recentes

[^2]: MediaWiki. API:Recentchanges — Query module to enumerate recent changes. MediaWiki API documentation, 2024-2026. https://www.mediawiki.org/wiki/API:Recentchanges

[^3]: Wikidata. Wikidata:Recent changes API and Query Service. Wikidata documentation, 2024-2026. https://www.wikidata.org/wiki/Wikidata:Data_access

[^4]: Halfaker, Aaron et al. The Rise and Decline of an Open Collaboration System: How Wikipedia's Reaction to Popularity Is Causing Its Decline. Wikimedia Foundation Research, American Behavioral Scientist, 2013 (atualizações 2024). https://doi.org/10.1177/0002764212469365

[^5]: Brasil GEO. Mention Rate Dashboard — Wikipedia.pt como sinal de citação em ChatGPT, Perplexity e Claude, recorte joalheria brasileira, ciclo março-maio 2026. Relatório interno.