Facebook Scraper GitHub: что еще работает, а что уже нет

Поиск в GitHub по запросу "facebook scraper" выдает . Только обновлялись за последние шесть месяцев.

Именно этот разрыв между "есть в наличии" и "действительно работает" и определяет всю историю Facebook-скрейпинга на GitHub в 2026 году.

Я потратил немало времени на изучение вкладок issues в репозиториях, жалоб на Reddit и реальных результатов, которые выдают эти инструменты. Картина везде одна и та же: большинство популярных по звездам проектов тихо сломаны, их авторы уже занялись другими вещами, а антискрейпинговая защита Facebook становится все жестче. Разработчики и бизнес-пользователи снова и снова приходят к одним и тем же результатам поиска, ставят одни и те же репозитории и получают один и тот же пустой вывод. Эта статья — проверка реальностью в 2026 году: честный разбор того, какие репозитории еще заслуживают вашего времени, что именно делает Facebook, чтобы ломать их, и когда GitHub лучше вообще не открывать.

Зачем люди ищут Facebook-скрейпер на GitHub

Причины этого поиска те же, что и много лет подряд, — даже если сами инструменты постоянно разваливаются:

• Лидогенерация: извлечение контактных данных бизнес-страниц (email, телефон, адрес) для продаж и outreach
• Мониторинг Marketplace: отслеживание карточек товаров, цен и данных продавцов для ecommerce или арбитража
• Исследование групп: архивирование постов и комментариев для маркетинговых исследований, OSINT или управления сообществом
• Архивация контента и постов: сохранение публичных постов страниц, реакций, изображений и временных меток
• Агрегация событий: сбор названий событий, дат, локаций и организаторов

Привлекательность GitHub очевидна: код на виду, нулевая стоимость, поддержка сообществом, по крайней мере в теории, и полный контроль над полями и пайплайном.

Проблема в том, что звезды и форки не означают "работает прямо сейчас". Среди топ-10 репозиториев по точной фразе и количеству звезд . Это не случайность — это норма.

Один пользователь Reddit в после шести месяцев попыток прямо написал, что без оплаты внешнего инструмента для сбора данных или без Python + JS-рендеринга + серьезных вычислительных ресурсов это "невозможно". Другой в сформулировал это так: "Facebook — один из самых сложных для скрейпинга, потому что они агрессивно блокируют автоматизацию", а браузерная автоматизация "хрупкая, поскольку Facebook постоянно меняет DOM".

Сценарии использования реальные. Спрос реальный. Разочарование — тоже более чем реальное. Дальше — о том, как жить с этим разрывом.

Что вообще такое GitHub-репозиторий с Facebook Scraper?

"Facebook scraper" на GitHub — это open-source скрипт, обычно на Python, который программно извлекает публичные данные со страниц, постов, групп, Marketplace или профилей Facebook. Но работают они по-разному. Доминируют три архитектуры:

Скрейперы на браузерной автоматизации vs. обертки над API vs. прямые HTTP-скрейперы

— классический пример прямого HTTP-подхода: он собирает публичные страницы "без API key", используя прямые запросы и парсинг. — пример браузерной автоматизации. — представитель старой эпохи Graph API, когда скрипты могли тянуть посты страниц и групп через официальные endpoints, которые теперь в широком смысле уже недоступны.

Обычно такие репозитории нацелены на текст постов, временные метки, количество реакций и комментариев, ссылки на изображения, метаданные страницы (категория, телефон, email, число подписчиков), поля карточек Marketplace и метаданные групп или событий.

В 2026 году реальный выбор — не в языке. Вопрос в том, какой тип отказа вы готовы терпеть.

Аудит свежести Facebook Scraper GitHub в 2026: какие репозитории вообще работают?

Я проверил самые звездные и самые рекомендуемые репозитории Facebook scraper на GitHub на реальных данных 2026 года — не по обещаниям в README, а по датам коммитов, очередям issues и сообщениям сообщества. Это самый важный раздел статьи.

Полная таблица аудита свежести

Бросаются в глаза несколько вещей:

• Даже "активный форк" (moda20) не обновлялся с июня 2024 года.
• Очереди issues быстрее показывают реальное положение дел, чем README.
• И kevinzg, и moda20 до сих пор заявляют Python ^3.6 в своих файлах — это признак того, что базовый стек зависимостей давно не модернизировали.

kevinzg/facebook-scraper

Самый известный Python Facebook scraper на GitHub. В его описаны скрейпинг страниц, скрейпинг групп, вход через учетные данные или cookies и поля уровня поста вроде comments, image, images, likes, post_id, post_text, text и time.

Но рабочие сигналы слабые:

• Последний push: 22 июня 2024
• Открытых issues: — включая такие заголовки, как "Example Scrape does not return any posts"
• Мейнтейнер не отвечал на недавние issues

Вердикт: Частично сломан. Еще может быть полезен для небольших экспериментов с публичными страницами и как справочник по названиям полей, но для продакшена ненадежен.

moda20/facebook-scraper (community fork)

Самый заметный форк kevinzg, с дополнительными опциями и хелперами для Marketplace вроде extract_listing (описано в его ).

Очередь прямо показывает характер поломки:

• "mbasic is gone"
• "CLI 'Couldn't get any posts.'"
• "https://mbasic.facebook.com is no longer working"

Когда упрощенный фронтенд mbasic меняется или исчезает, целый класс скрейперов разом деградирует.

Вердикт: Самый заметный форк, но в 2026 году тоже устаревший и хрупкий. Если вы все же хотите GitHub-решение, начать можно с него, но на стабильность не рассчитывайте.

minimaxir/facebook-page-post-scraper

Когда-то это был очень практичный инструмент под Graph API для сбора постов, реакций, комментариев и метаданных публичных страниц и открытых групп в CSV. В его до сих пор объясняется, как использовать App ID и App Secret Facebook-приложения.

В 2026 году это уже исторический артефакт:

• Последний push: 23 мая 2019
• Открытых issues: 53 — включая "HTTP 400 Error Bad Request" и "No data retrieved!!"

Вердикт: Заброшен. Сильно завязан на модель разрешений API, которую Meta с тех пор значительно сузила.

Другие заметные репозитории

• passivebot/facebook-marketplace-scraper: полезен для сценариев Marketplace, но в его есть "login to view the content", "CSS selectors outdated" и "Getting blocked". Почти учебник того, что ломается в скрейпинге Marketplace.
• apurvmishra99/facebook-scraper-selenium: там есть issue с буквальным вопросом еще с сентября 2020 года. Это говорит почти все.
• Mhmd-Hisham/selenium_facebook_scraper и anabastos/faceteer: у них просто недостаточно текущей активности, чтобы им доверять.

Антискрейпинговая защита Facebook: против чего борется каждый GitHub-скрейпер

Большинство статей на эту тему ограничиваются размытыми предупреждениями в стиле "проверьте ToS". Это бесполезно.

У Facebook одна из самых агрессивных антискрейпинговых систем среди крупных платформ. Понимание конкретных уровней защиты — это разница между рабочим скрейпером и полднем пустого вывода.

В собственном описана "Anti Scraping team", которая использует статический анализ по всему кодовому base, чтобы выявлять векторы скрейпинга, рассылает cease-and-desist письма, блокирует аккаунты и опирается на системы rate limiting. Это не гипотеза — это организационно закрепленная практика.

Случайный DOM и имена CSS-классов

Facebook намеренно рандомизирует HTML-идентификаторы, имена классов и структуру страницы. Как написал один комментатор на : "Ни один обычный скрейпер не сможет работать на Facebook. HTML мутирует между обновлениями."

Что ломается: XPath- и CSS-селекторы, которые работали на прошлой неделе, сегодня возвращают пустоту.

Как защищаться: По возможности используйте селекторы по тексту или атрибутам. AI-парсинг, который читает содержимое страницы вместо жесткой привязки к селекторам, справляется лучше. Но обслуживание селекторов — это постоянная статья расходов.

Login wall и управление сессиями

Многие поверхности Facebook — профили, группы, часть объявлений Marketplace — требуют входа, чтобы увидеть контент. Headless-браузеры получают редиректы или упрощенный HTML. В скрейпера passivebot для Marketplace жалоба "login to view the content" — одна из самых частых.

Что ломается: Анонимные запросы теряют контент или вообще перенаправляются.

Как защищаться: Используйте session cookies из реальной браузерной сессии или инструменты браузерного скрейпинга, работающие внутри вашей авторизованной сессии. Ротация аккаунтов возможна, но рискованна.

Цифровой fingerprinting

В инженерном посте Meta говорится, что несанкционированные скрейперы — по сути это заявление о том, что для детекции ключевыми являются качество браузера и качество поведения. Обсуждения сообщества в и по-прежнему советуют антидетект-браузеры и стабильные fingerprint-профили.

Что ломается: Стандартные Selenium- или Puppeteer-настройки распознаются очень быстро.

Как защищаться: Используйте инструменты вроде undetected-chromedriver или антидетект-профили браузера. Реалистичные сессии и стабильные отпечатки важнее, чем простая подмена user-agent.

Rate limiting и блокировки по IP

Инженерный пост Meta прямо говорит о rate limiting как части стратегии защиты, включая ограничение размеров follower lists, чтобы вынудить больше запросов, которые затем . На практике пользователи сообщают, что ограничения срабатывают уже после публикации в .

Что ломается: Массовые запросы с одного IP начинают троттлиться или блокироваться за минуты. Datacenter proxy IP часто заблокированы заранее.

Как защищаться: Ротация residential proxies, а не datacenter-прокси, плюс разумный темп запросов.

Изменения схемы GraphQL

Некоторые скрейперы используют внутренние GraphQL endpoints Facebook, потому что они возвращают более чистые структурированные данные, чем сырой HTML. Но Meta не публикует гарантий стабильности для внутреннего GraphQL, поэтому такие запросы ломаются молча — возвращают пустые данные вместо ошибок.

Что ломается: Структурированное извлечение тихо начинает возвращать пустоту.

Как защищаться: Добавляйте валидацию, отслеживайте schema endpoints и фиксируйте рабочие запросы. Ожидайте постоянного обслуживания.

Сводка по антискрейпинговой защите

Когда GitHub-репозитории не справляются: выход без кода

Большая часть людей, вводящих "facebook scraper github", — не разработчики. Это sales-менеджеры, которым нужны email бизнес-страниц, ecommerce-операторы, отслеживающие цены в Marketplace, или маркетологи, делающие конкурентный анализ. Им не хочется поднимать Python-окружение, дебажить сломанные селекторы или крутить прокси.

Если это про вас, выбор короткий:

Сбор контактных данных со страниц Facebook (email, телефоны)

Если задача — вытащить email и телефоны из разделов "About" на Page, GitHub-репозиторий избыточен. Бесплатные и от сканируют веб-страницу и экспортируют результат в Sheets, Excel, Airtable или Notion. ИИ каждый раз читает страницу заново, поэтому изменения DOM у Facebook ничего не ломают.

Извлечение структурированных данных из Marketplace или бизнес-страниц

Если нужно извлечь карточки товаров, цены, локации или данные о компании, AI Web Scraper от Thunderbit позволяет нажать "AI Suggest Fields" — ИИ читает страницу и предлагает столбцы вроде price, title, location, — а затем нажать "Scrape". Без поддержки XPath, без установки кода. Экспорт прямо в .

Регулярный мониторинг (алерты по ценам в Marketplace, отслеживание конкурентов)

Для постоянного мониторинга — "сообщи мне, когда объявление в Marketplace попадет в мой ценовой диапазон" — от Thunderbit позволяет описать интервал простым языком (например, ) и указать URL. Он запускается автоматически, cron-задача не нужна.

Когда GitHub-репозитории все еще лучший выбор

Если вам нужен глубокий программный контроль, извлечение на больших объемах или собственные data pipelines, GitHub-репозитории (или для структурированного извлечения) — правильный инструмент. Решение простое: для бизнес-пользователей с базовыми задачами извлечения данных — сначала no-code; для разработчиков, строящих data pipelines, — GitHub-репозитории или API.

Примеры реального вывода: что вы реально получаете

В каждой статье у конкурентов есть куски кода, но почти никогда нет реального вывода. Ниже — то, чего можно ожидать на практике от каждого подхода.

Пример вывода: kevinzg/facebook-scraper (или активный форк)

Из для публичного поста получается JSON примерно такого вида:

1{
2  "comments": 459,
3  "comments_full": null,
4  "image": "https://...",
5  "images": ["https://..."],
6  "likes": 3509,
7  "post_id": "2257188721032235",
8  "post_text": "Не дайте этому уменьшенному варианту...",
9  "text": "Не дайте этому уменьшенному варианту...",
10  "time": "2019-04-30T05:00:01"
11}

Обратите внимание на поля, допускающие null, вроде comments_full. В 2026 году ожидайте, что больше полей будет приходить пустыми или отсутствующими — обычно это сигнал блокировки, а не безобидного сбоя. Вывод — сырой JSON, и его нужно дополнительно обрабатывать.

Пример вывода: Facebook Graph API

Текущая у Meta документирует запросы информации о странице вроде GET /<PAGE_ID>?fields=id,name,about,fan_count. В есть такие поля, как followers_count, fan_count, category, emails, phone и другие публичные метаданные — но только при наличии правильных прав, например .

Это гораздо более узкая структура данных, чем ожидает большинство пользователей GitHub-скрейперов. Она завязана на Page, требует разрешений и не заменяет произвольный скрейпинг публичных постов или групп.

Пример вывода: Thunderbit AI Web Scraper

Столбцы, предложенные ИИ Thunderbit для бизнес-страницы Facebook, дают чистую, структурированную таблицу:

Для постов и комментариев вывод выглядит так:

Структурированные столбцы, отформатированные телефоны, данные, готовые к использованию, — без дополнительной постобработки. Контраст с сырым JSON из GitHub-инструментов трудно не заметить.

Матрица Facebook Data Type × лучший инструмент

Ни один инструмент в 2026 году не умеет одинаково хорошо все на Facebook.

Эта матрица позволяет сразу перейти к своему сценарию, не читая всю статью в надежде найти нужный ответ.

Какой подход подходит вашей команде?

• Отделы продаж, извлекающие лиды: начните с Email/Phone Extractor или AI Scraper от Thunderbit. Никакой настройки, результат сразу.
• Ecommerce-команды, мониторящие Marketplace: Scheduled Scraper от Thunderbit или кастомная связка Scrapy + residential proxies, если у вас есть инженерные ресурсы.
• Разработчики, строящие data pipelines: GitHub-репозитории (активные форки) + residential proxies + бюджет на обслуживание. Работы будет много.
• Исследователи, архивирующие контент групп: только браузерный workflow (Thunderbit или Selenium с логином) и проверка соответствия требованиям.

Честная позиция — и та, к которой — в том, что одного надежного решения не существует. Подбирайте инструмент под конкретную задачу.

Пошагово: как настроить Facebook Scraper из GitHub, если это действительно имеет смысл

Если вы прочитали аудит свежести и все равно хотите идти через GitHub, это ваше право. Вот практический путь — с честными замечаниями о том, где все ломается.

Шаг 1: выберите подходящий репозиторий (используйте аудит свежести)

Вернитесь к таблице аудита. Возьмите наименее устаревший репозиторий, который подходит под вашу целевую поверхность. Перед установкой чего-либо загляните во вкладку Issues — свежие заголовки говорят о текущей работоспособности больше, чем README.

Шаг 2: настройте Python-окружение

1python3 -m venv fb-scraper-env
2source fb-scraper-env/bin/activate
3pip install -r requirements.txt

Частая проблема: конфликты версий зависимостей, особенно Selenium/Playwright. И kevinzg, и moda20 заявляют Python ^3.6 в своих — это более старый базовый уровень, который может конфликтовать с новыми библиотеками. Marketplace-скрейпер passivebot фиксирует , что нормально для экспериментов, но не доказывает долговечность.

Шаг 3: настройте прокси и антидетект

Если вы делаете что-то большее, чем быстрый тест:

• Настройте ротацию residential proxy (ищите провайдеров с IP-пулами под Facebook)
• Если используете браузерную автоматизацию, установите undetected-chromedriver или настройте антифингерпринтинг
• Не пропускайте этот шаг — обычный Selenium или Puppeteer быстро попадают под флаги

Шаг 4: запустите небольшой тестовый скрейпинг и проверьте вывод

Начните с одной публичной страницы, а не с большого пакета. Внимательно проверьте результат:

• Пустые поля или отсутствующие данные обычно означают, что вас блокирует защита Facebook
• Сравните вывод с тем, что вы реально видите на странице в браузере
• Успешный тест на одной странице важнее красивого README

Шаг 5: обработка ошибок, rate limits и обслуживание

• Добавьте retry-логику и обработку ошибок
• Будьте готовы регулярно обновлять селекторы или настройки — это постоянное обслуживание, а не "настроил и забыл"
• Если вы тратите больше времени на поддержку скрейпера, чем на использование данных, это сигнал пересмотреть no-code-подход

Юридические и этические аспекты скрейпинга Facebook

Этот раздел короткий и фактологичный. Он не центральный для статьи, но игнорировать его было бы безответственно.

В Facebook сказано, что пользователи "may not access or collect data from our Products using automated means (without our prior permission)." В Meta, обновленных 3 февраля 2026 года, прямо указано, что меры enforcement могут включать suspension, лишение доступа к API и действия на уровне аккаунта.

Это не теория. В описаны активные расследования несанкционированного скрейпинга, cease-and-desist письма и отключение аккаунтов. Meta также на компании, занимающиеся скрейпингом, например в деле Voyager Labs.

Самая безопасная рамка:

• Условия Meta прямо запрещают скрейпинг
• Использование разрешенного API безопаснее, чем несанкционированный скрейпинг
• Публичная доступность не отменяет обязательств по законам о конфиденциальности данных (GDPR, CCPA и т. д.)
• Если вы работаете в больших объемах, проконсультируйтесь с юристом
• Thunderbit предназначен для скрейпинга общедоступных данных и не обходит требования авторизации при cloud scraping

Главные выводы: что реально работает для Facebook-скрейпинга в 2026 году

Большинство GitHub-репозиториев с Facebook scraper в 2026 году либо сломаны, либо ненадежны. Это не попытка напугать — это то, что последовательно показывают даты коммитов, очереди issues и отчеты сообщества.

Немногие активные форки по-прежнему работают для ограниченных данных публичных страниц, но им требуется постоянная поддержка, антидетект-настройка и реалистичное ожидание, что что-то снова сломается. Graph API полезен, но узок по возможностям — он покрывает метаданные уровня страницы при наличии правильных разрешений, а не широкий скрейпинг публичных постов или групп, который нужен большинству.

Для бизнес-пользователей, которым нужны данные Facebook без накладных расходов на разработку, no-code-инструменты вроде предлагают более надежный и менее затратный в поддержке путь. ИИ каждый раз заново читает страницу, поэтому изменения DOM не ломают ваш workflow. Вы можете бесплатно попробовать и экспортировать данные в Sheets, Excel, Airtable или Notion.

Практическая рекомендация: начните с таблицы аудита свежести. Если вы не разработчик, сначала попробуйте no-code-вариант. Если вы разработчик, вкладывайтесь в GitHub-настройку только если у вас есть технические ресурсы — и терпение — чтобы ее поддерживать. И независимо от выбранного пути подбирайте инструмент под конкретную задачу, а не надейтесь на одно решение для всего.

Если хотите глубже разобраться в сборе данных из соцсетей и связанных инструментах, у нас есть гайды по , и . Также можно посмотреть разборы на .

Часто задаваемые вопросы

Есть ли в 2026 году рабочий Facebook scraper на GitHub?

Да, но вариантов мало. Самый заметный — форк от исходного репозитория kevinzg — см. актуальный статус в таблице аудита свежести выше. Он может частично собирать публичные посты страниц и некоторые метаданные, но очередь issues показывает основные поломки вокруг mbasic и пустого вывода. Большинство остальных репозиториев заброшены или полностью сломаны.

Можно ли собирать данные Facebook без кода?

Да. Инструменты вроде и бесплатных Email/Phone Extractors позволяют извлекать данные Facebook прямо из браузера за несколько кликов, без Python и без настройки GitHub. ИИ каждый раз читает страницу заново, поэтому при изменении layout вам не нужно поддерживать селекторы.

Законно ли скрейпить Facebook?

Facebook запрещают автоматический сбор данных без разрешения. Meta активно обеспечивает исполнение через блокировки аккаунтов, cease-and-desist письма и . Законность зависит от юрисдикции и сценария использования. Ограничивайтесь общедоступными бизнес-данными, избегайте личных профилей и при больших объемах консультируйтесь с юристом.

Какие данные еще можно получить через Facebook Graph API?

В 2026 году сильно ограничен. Вы можете получить ограниченные данные уровня страницы — поля вроде id, name, about, fan_count, emails, phone — при наличии правильных разрешений, например . Большая часть данных публичных постов, данных групп ( ) и данных на уровне пользователей через API больше недоступна.

Как часто ломаются GitHub-репозитории Facebook scraper?

Очень часто. Facebook постоянно меняет структуру DOM, антибот-механизмы и внутренние API — официального графика нет, но отчеты сообщества показывают поломки каждые несколько недель у активных скрейперов. Очередь issues форка moda20 вокруг исчезновения mbasic — недавний пример. Если вы полагаетесь на GitHub-репозиторий, закладывайте регулярное обслуживание и валидацию вывода.

Узнать больше