Uma busca por "facebook scraper" no GitHub retorna 475 repositórios. Só 62 deles receberam atualização nos últimos seis meses.
Essa distância entre "está disponível" e "realmente funciona" resume a situação do scraping de Facebook no GitHub em 2026.
Passei bastante tempo vasculhando abas de issues, reclamações no Reddit e saídas reais dessas ferramentas. O padrão se repete: a maioria dos projetos mais estrelados está quebrada em silêncio, os mantenedores seguiram em frente e as defesas anti-scraping do Facebook ficaram cada vez mais sofisticadas. Desenvolvedores e usuários de negócios continuam caindo nos mesmos resultados de busca, instalando os mesmos repositórios e esbarrando na mesma saída vazia. Este artigo é um ajuste de realidade para 2026 — uma análise honesta de quais repositórios ainda valem seu tempo, o que o Facebook está fazendo para derrubá-los e quando faz mais sentido pular o GitHub de vez.
Por que as pessoas buscam um Facebook Scraper no GitHub
Os casos de uso por trás dessa busca são os mesmos de anos atrás — mesmo com as ferramentas falhando cada vez mais:
- Geração de leads: extrair contatos de páginas comerciais (e-mails, telefones, endereços) para prospecção
- Monitoramento de marketplace: acompanhar anúncios, preços e informações de vendedores para ecommerce ou arbitragem
- Pesquisa em grupos: arquivar posts e comentários para pesquisa de mercado, OSINT ou gestão de comunidades
- Arquivamento de conteúdo e posts: salvar publicações públicas, reações, imagens e timestamps
- Consolidação de eventos: coletar títulos, datas, locais e organizadores
O apelo do GitHub é óbvio: código visível, custo zero, manutenção comunitária (em tese) e controle total sobre campos e pipelines.
O problema é que estrelas e forks não significam "funciona hoje". Entre os 10 repositórios exatos mais estrelados, todos os 10 estavam desatualizados há mais de 12 meses em abril de 2026. Isso não é um caso isolado — é o padrão.
Em um tópico de novembro de 2025, um usuário resumiu bem depois de seis meses tentando: era "impossível sem pagar por uma aplicação externa de extração de dados" ou usar Python com renderização em JS e bastante poder de processamento. Outro, em uma discussão de abril de 2026, sintetizou assim: "O Facebook é um dos mais difíceis de raspar porque bloqueia automação de forma agressiva" e a automação de navegador é "frágil, já que o Facebook muda o DOM constantemente."
Os casos de uso são reais. A demanda é real. A frustração é muito real. O resto deste artigo é sobre como navegar esse abismo.
O que exatamente é um repositório de Facebook Scraper no GitHub?
Um "Facebook scraper" no GitHub é um script open source — geralmente em Python — que extrai de forma programática dados públicos de páginas, posts, grupos, Marketplace ou perfis do Facebook. Nem todos funcionam do mesmo jeito. Três arquiteturas dominam:
Scrapers com automação de navegador vs. wrappers de API vs. scrapers HTTP diretos
| Abordagem | Stack típico | Ponto forte | Ponto fraco |
|---|---|---|---|
| Automação de navegador | Selenium, Playwright, Puppeteer | Lida com barreiras de login e imita comportamento de usuário real | Lento, pesado em recursos, fácil de identificar se não for configurado com cuidado |
| Wrapper da API oficial | Meta Graph API / Pages API | Estável, documentado e aderente às regras quando aprovado | Muito limitado — a maior parte dos dados públicos de posts/grupos já não está disponível |
| Scraper HTTP direto | requests, parsing de HTML, endpoints não documentados | Rápido e leve quando funciona | Quebra sempre que o Facebook altera a estrutura da página ou as medidas anti-bot |
kevinzg/facebook-scraper é o exemplo clássico de HTTP direto: faz scraping de páginas públicas "sem chave de API" usando requisições diretas e parsing. apurvmishra99/facebook-scraper-selenium é um exemplo de automação de navegador. minimaxir/facebook-page-post-scraper representa a antiga era da Graph API, em que scripts conseguiam puxar posts de páginas e grupos por meio de endpoints oficiais que hoje já não estão amplamente acessíveis.
Os dados normalmente visados nesses repositórios incluem texto do post, timestamps, contagem de reações/comentários, URLs de imagens, metadados da página (categoria, telefone, e-mail, número de seguidores), campos de anúncios do Marketplace e metadados de grupos ou eventos.
Em 2026, o verdadeiro trade-off não é preferência de linguagem. É qual tipo de falha você consegue tolerar.
Auditoria de frescor dos Facebook Scrapers no GitHub em 2026: quais repositórios ainda funcionam?
Auditei os repositórios de Facebook scraper mais estrelados e mais recomendados no GitHub usando dados reais de 2026 — não promessas de README, mas datas reais de commit, filas de issues e relatos da comunidade. Esta é a seção que mais importa.
Tabela completa da auditoria de frescor
| Repositório | Stars | Último push | Issues abertas | Linguagem / runtime | O que ainda raspa | Status |
|---|---|---|---|---|---|---|
| kevinzg/facebook-scraper | 3.157 | 2024-06-22 | 438 | Python ^3.6 | Posts públicos limitados, alguns comentários/imagens, metadados da página | ⚠️ Parcialmente quebrado / desatualizado |
| moda20/facebook-scraper | 110 | 2024-06-14 | 29 | Python ^3.6 | O mesmo que kevinzg + helpers para Marketplace | ⚠️ Fork parcial quebrado / desatualizado |
| minimaxir/facebook-page-post-scraper | 2.128 | 2019-05-23 | 53 | Era Python 2/3, dependente da Graph API | Apenas como referência histórica | ❌ Abandonado |
| apurvmishra99/facebook-scraper-selenium | 232 | 2020-06-28 | 7 | Python + Selenium | Automação de navegador para scraping de páginas | ❌ Abandonado |
| passivebot/facebook-marketplace-scraper | 375 | 2024-04-29 | 3 | Python 3.x + Playwright 1.40 | Anúncios do Marketplace via automação de navegador | ⚠️ Frágil / nichado |
| Mhmd-Hisham/selenium_facebook_scraper | 37 | 2022-11-29 | 1 | Python + Selenium | Scraping geral com Selenium | ❌ Abandonado |
| anabastos/faceteer | 20 | 2023-07-11 | 5 | JavaScript | Voltado à automação | ❌ Arriscado / pouca evidência |
Alguns pontos saltam aos olhos:
- Mesmo o "fork ativo" (moda20) não recebe push desde junho de 2024.
- As filas de issues contam a história real mais rápido do que os READMEs.
- Tanto kevinzg quanto moda20 ainda declaram Python ^3.6 em seus arquivos pyproject.toml — um sinal de que a base de dependências não foi modernizada.
kevinzg/facebook-scraper
O scraper de Facebook em Python mais conhecido no GitHub. O README descreve scraping de páginas, scraping de grupos, login com credenciais ou cookies e campos no nível do post como comments, image, images, likes, post_id, post_text, text e time.
Mas o sinal operacional é fraco:
- Último push: 22 de junho de 2024
- Issues abertas: 438 — incluindo títulos como "Example Scrape does not return any posts"
- O mantenedor não respondeu a issues recentes
Veredito: Parcialmente quebrado. Ainda pode servir para experimentos de baixo volume com páginas públicas e como referência de nomes de campos, mas não é confiável para produção.
moda20/facebook-scraper (fork da comunidade)
O fork mais visível de kevinzg, com opções adicionais e helpers voltados ao Marketplace, como extract_listing (documentado no README).
A fila de issues deixa a quebra explícita:
- "mbasic is gone"
- "CLI 'Couldn't get any posts.'"
- "https://mbasic.facebook.com is no longer working"
Quando a interface simplificada mbasic muda ou desaparece, toda uma classe de scrapers degrada de uma vez.
Veredito: O fork mais relevante, mas também desatualizado e frágil em 2026. Vale testar primeiro se você insiste em uma solução baseada no GitHub, mas não espere estabilidade.
minimaxir/facebook-page-post-scraper
Antes era uma ferramenta Graph API muito prática para coletar posts, reações, comentários e metadados de Páginas públicas e Grupos abertos em CSV. O README ainda explica como usar o App ID e o App Secret de um aplicativo do Facebook.
Em 2026, é um artefato histórico:
- Último push: 23 de maio de 2019
- Issues abertas: 53 — incluindo "HTTP 400 Error Bad Request" e "No data retrieved!!"
Veredito: Abandonado. Fortemente acoplado a um modelo de permissões de API que a Meta desde então restringiu bastante.
Outros repositórios notáveis
- passivebot/facebook-marketplace-scraper: útil para casos de uso do Marketplace, mas a fila de issues inclui "login to view the content", "CSS selectors outdated" e "Getting blocked". Um estudo de caso em uma linha sobre o que quebra no scraping do Marketplace.
- apurvmishra99/facebook-scraper-selenium: tem uma issue literalmente perguntando "Does it work with new Facebook layout?" desde setembro de 2020. Isso já diz quase tudo.
- Mhmd-Hisham/selenium_facebook_scraper e anabastos/faceteer: nenhum dos dois tem atividade atual suficiente para inspirar confiança.
As defesas anti-scraping do Facebook: contra o que todo scraper do GitHub está lutando
A maioria dos artigos sobre o tema oferece avisos vagos do tipo "verifique os termos de uso". Isso não ajuda.
O Facebook tem um dos sistemas anti-scraping mais agressivos entre as grandes plataformas. Entender essas camadas de defesa é a diferença entre um scraper funcionando e uma tarde inteira de saída vazia.
Um post de engenharia da Meta de fevereiro de 2025 descreve uma "Anti Scraping team" que usa análise estática em toda a base de código para identificar vetores de scraping, envia notificações formais de cessar e desistir, desativa contas e depende de sistemas de rate limiting. Isso não é teoria — é compromisso organizacional.
DOM e nomes de classes CSS aleatorizados
O Facebook randomiza de propósito IDs de elementos HTML, nomes de classes e a estrutura das páginas. Como disse um comentarista do r/webscraping: "Nenhum scraper normal consegue funcionar no Facebook. O HTML muda entre um refresh e outro."
O que quebra: XPaths e seletores CSS que funcionavam na semana passada hoje não retornam nada.
Contramedida: Use seletores baseados em texto ou atributos quando possível. Parsing com IA, que lê o conteúdo da página em vez de depender de seletores rígidos, costuma lidar melhor com isso. Espere ter de manter seletores continuamente.
Barreiras de login e gerenciamento de sessão
Muitas áreas do Facebook — perfis, grupos, alguns anúncios do Marketplace — exigem login para visualização. Navegadores headless são redirecionados ou recebem HTML simplificado. A issue do scraper do Marketplace da passivebot tem "login to view the content" como uma das principais reclamações.
O que quebra: requisições anônimas perdem conteúdo ou são redirecionadas completamente.
Contramedida: Use cookies de sessão de uma sessão real no navegador, ou ferramentas de scraping baseadas em navegador que operem dentro da sua sessão logada. Trocar de conta é possível, mas arriscado.
Impressão digital do navegador
O post de engenharia da Meta diz que scrapers não autorizados "comumente se escondem imitando a forma como usuários normalmente usariam um produto" — o que, na prática, indica que qualidade do navegador e qualidade do comportamento são centrais na detecção. Discussões da comunidade em março e abril de 2026 continuam recomendando navegadores anti-detect e fingerprints consistentes.
O que quebra: configurações padrão de Selenium ou Puppeteer são facilmente identificadas.
Contramedida: Use ferramentas como undetected-chromedriver ou perfis de navegador anti-detect. Sessões realistas e fingerprints consistentes importam mais do que simples troca de user-agent.
Rate limiting e bloqueio por IP
O post de engenharia da Meta fala explicitamente de rate limiting como parte da estratégia de defesa, incluindo limitar contagens de listas de seguidores para forçar mais requisições que depois disparam controles de taxa. Na prática, usuários relatam rate limit após postar em 10 grupos com intervalos de 10 segundos.
O que quebra: requisições em massa do mesmo IP são limitadas ou bloqueadas em minutos. IPs de proxy de datacenter geralmente já estão bloqueados de antemão.
Contramedida: rotação de proxies residenciais, não proxies de datacenter, com ritmo de requisição sensato.
Mudanças de schema GraphQL
Alguns scrapers dependem dos endpoints internos de GraphQL do Facebook porque eles retornam dados estruturados mais limpos do que HTML bruto. Mas a Meta não publica garantia de estabilidade para o GraphQL interno, então essas consultas quebram silenciosamente — retornando dados vazios em vez de erros.
O que quebra: a extração estruturada simplesmente não retorna nada.
Contramedida: adicione validações, monitore endpoints de schema e fixe consultas conhecidas como funcionais. Espere manutenção contínua.
Resumo das defesas anti-scraping
| Camada de defesa | Como ela quebra seu scraper | Contramedida prática |
|---|---|---|
| Mudanças de layout / seletores instáveis | XPaths e seletores CSS não retornam nada ou só parte dos campos | Prefira âncoras resilientes, valide com base no conteúdo visível e espere manutenção |
| Barreiras de login | Requisições sem login perdem conteúdo ou são redirecionadas | Use cookies de sessão válidos ou ferramentas baseadas na sessão do navegador |
| Fingerprinting | A automação padrão parece sintética | Use navegadores reais, qualidade consistente de sessão e medidas anti-detect |
| Rate limiting | Saída vazia, bloqueios e throttling | Reduza o ritmo, diminua lotes e faça rotação de proxy residencial |
| Mudanças em consultas internas | A extração estruturada volta vazia sem aviso | Adicione validações e espere manutenção das consultas |
Quando os repositórios do GitHub falham: escolha uma alternativa permitida
Um repositório quebrado não é motivo para procurar outra forma de contornar os controles de uma plataforma. Primeiro esclareça a pergunta de negócio: você precisa de análises em nível de página, transparência publicitária, um diretório público de contatos ou um catálogo de produtos? Muitas dessas necessidades podem ser atendidas com um produto oficial da Meta, uma API com permissão ou uma fonte pública fora da Meta.
Por exemplo, use a Graph API apenas quando o aplicativo e o caso de uso tiverem as permissões exigidas, use os programas de pesquisa da Meta apenas quando houver elegibilidade e use a Meta Ad Library para as informações de publicidade que ela disponibiliza. Para pesquisa de leads, preços e descoberta de negócios locais, prefira sites públicos independentes cujos termos e obrigações de privacidade você possa avaliar diretamente.
Amostras reais de saída: o que você realmente obtém
Todo artigo concorrente mostra trechos de código, mas nunca a saída real. Abaixo está o que você pode esperar de forma realista de cada abordagem.
Exemplo de saída: kevinzg/facebook-scraper (ou fork ativo)
No exemplo do README, um post público raspado retorna JSON como este:
{
"comments": 459,
"comments_full": null,
"image": "https://...",
"images": ["https://..."],
"likes": 3509,
"post_id": "2257188721032235",
"post_text": "Don't let this diminutive version...",
"text": "Don't let this diminutive version...",
"time": "2019-04-30T05:00:01"
}
Observe os campos nulos, como comments_full. Em 2026, espere que mais campos voltem vazios ou ausentes — isso normalmente é sinal de bloqueio, não um bug inofensivo. A saída é JSON bruto e exige pós-processamento.
Exemplo de saída: Facebook Graph API
A atual Pages API da Meta documenta consultas de informações de página como GET /<PAGE_ID>?fields=id,name,about,fan_count. A referência de Page inclui campos como followers_count, fan_count, category, emails, phone e outros metadados públicos — mas apenas com as permissões corretas, como Page Public Content Access ou Page Public Metadata Access.
Isso é um formato de dados muito mais restrito do que a maioria dos usuários de scrapers no GitHub imagina. É centrado em páginas, depende de permissão e não substitui scraping arbitrário de posts públicos ou grupos.
Matriz de tipos de dados do Facebook × rota de acesso
| Tipo de dado do Facebook | Ponto de partida mais indicado | Limitação principal |
|---|---|---|
| Ativos administrados pela sua organização | Ferramentas oficiais de gestão da Meta e APIs aprovadas | Permissões e campos disponíveis variam |
| Observações sobre anúncios | Meta Ad Library | Use apenas os campos e filtros que ela expõe |
| Dados públicos de empresas necessários para pesquisa de leads | Um diretório não-Meta permitido ou site do publisher | Verifique os termos e as obrigações de privacidade da fonte |
| Conteúdo privado, de grupo fechado, protegido por login ou restrito à conta | Não automatize a coleta | Busque um caminho autorizado em vez disso |
Passo a passo: como configurar um Facebook Scraper do GitHub (quando isso faz sentido)
Se você leu a auditoria de frescor e ainda quer seguir pelo GitHub, tudo bem. Aqui está o caminho prático — com observações sinceras sobre onde as coisas quebram.
Passo 1: escolha o repositório certo (use a auditoria de frescor)
Volte à tabela de auditoria. Escolha o repositório menos desatualizado que corresponda à superfície que você quer atingir. Antes de instalar qualquer coisa, verifique a aba Issues — títulos recentes dizem mais sobre a funcionalidade atual do que o README.
Passo 2: configure seu ambiente Python
python3 -m venv fb-scraper-env
source fb-scraper-env/bin/activate
pip install -r requirements.txt
Armadiilha comum: conflitos de versão com dependências, especialmente Selenium/Playwright. Tanto kevinzg quanto moda20 declaram Python ^3.6 em seus pyproject.toml — uma base antiga que pode conflitar com bibliotecas mais novas. O scraper de Marketplace da passivebot fixa playwright==1.40.0, o que é aceitável para experimentação, mas não prova durabilidade.
Passo 3: configure proxies e anti-deteção
Se você pretende fazer algo além de um teste rápido:
- Configure rotação de proxies residenciais (procure provedores com pools de IP específicos para Facebook)
- Se usar automação de navegador, instale undetected-chromedriver ou configure anti-fingerprinting
- Não pule esta etapa — Selenium ou Puppeteer padrão são sinalizados rapidamente
Passo 4: execute um teste pequeno e valide a saída
Comece com uma única página pública, não com um lote grande. Verifique a saída com cuidado:
- Campos vazios ou dados ausentes geralmente significam que as defesas do Facebook estão bloqueando você
- Compare a saída com o que você realmente vê na página no navegador
- Um teste bem-sucedido em uma página vale mais do que um README bonito
Passo 5: lide com erros, rate limits e manutenção
- Implemente lógica de retry e tratamento de erros
- Espere atualizar seletores ou configurações com frequência — isso é manutenção contínua, não algo que se configura uma vez e esquece
- Se você estiver gastando mais tempo mantendo o scraper do que usando os dados, isso é um sinal para reconsiderar a abordagem no-code
Considerações legais e éticas sobre scraping do Facebook
Termos da plataforma, regras de privacidade, obrigações contratuais e leis de proteção de dados podem todos se aplicar. Visibilidade pública não significa autorização geral para coleta automatizada. Minimize os dados, documente a finalidade e a base legal e procure orientação jurídica para programas comerciais ou em grande escala.
Não trate uma extensão do navegador, uma sessão logada ou o rótulo "público" como permissão para automatizar a coleta de produtos da Meta.
Principais conclusões: o que realmente funciona para scraping do Facebook em 2026
Atividade do repositório, fila de issues e regras atuais da plataforma importam mais do que número de stars ou README antigo. Quando a pergunta de negócio diz respeito a um ativo que você administra, comece pelas ferramentas oficiais da Meta e pelas APIs aprovadas. Para pesquisa de mercado, pesquisa de leads e questões de preço, uma fonte permitida fora da Meta muitas vezes é mais fácil de documentar e governar.
Perguntas frequentes
Existe um Facebook scraper funcional no GitHub em 2026?
Sim, mas as opções são limitadas. O mais notável é o fork moda20/facebook-scraper do repositório original de kevinzg — confira a tabela de auditoria de frescor acima para ver o status atual. Ele consegue raspar parcialmente posts públicos e alguns metadados, mas a fila de issues mostra falhas centrais relacionadas ao mbasic e à saída vazia. A maioria dos outros repositórios está abandonada ou completamente quebrada.
Posso raspar o Facebook sem programar?
Use a busca e as ferramentas de gestão do próprio Facebook para pesquisa manual. Para trabalho repetível ou programático, avalie a API oficial e suas permissões, ou redesenhe o fluxo em torno de uma fonte permitida fora da Meta. A conveniência no-code não elimina obrigações da plataforma, de privacidade ou contratuais.
É legal fazer scraping do Facebook?
Os Termos de Serviço do Facebook proíbem coleta automatizada de dados sem permissão. A Meta faz cumprir isso ativamente por meio de bloqueios de conta, notificações formais e processos. A legalidade varia conforme a jurisdição e o caso de uso. Fique nos dados comerciais publicamente disponíveis, evite perfis pessoais e consulte um advogado se operar em escala.
Que dados ainda posso obter pela Facebook Graph API?
Em 2026, a Graph API está bastante restrita. Você consegue acessar dados limitados em nível de página — campos como id, name, about, fan_count, emails, phone — com permissões adequadas, como Page Public Metadata Access. A maior parte dos dados de posts públicos, dados de grupos (a Groups API foi descontinuada) e dados em nível de usuário já não está disponível via API.
Com que frequência os repositórios de Facebook scraper no GitHub quebram?
Com muita frequência. O Facebook altera continuamente a estrutura do DOM, as medidas anti-bot e as APIs internas — não há uma cadência pública, mas relatos da comunidade mostram que scrapers ativos quebram a cada poucas semanas. A fila de issues do fork moda20 em torno do desaparecimento do mbasic é um exemplo recente. Se você depender de um repositório do GitHub, reserve tempo e orçamento para manutenção constante e validação da saída.
Saiba mais
