Поиск по GitHub по запросу "facebook scraper" выдаёт 475 репозиториев. Но только 62 из них обновлялись за последние шесть месяцев.
Именно этот разрыв между «репозиторий существует» и «репозиторий реально работает» и есть вся суть Facebook scraping на GitHub в 2026 году.
Я потратил много времени на изучение issue-трекеров, жалоб на Reddit и реального результата, который дают эти инструменты. Картина повторяется везде: большинство популярных проектов тихо сломались, мейнтейнеры ушли, а антискрейпинговые защиты Facebook становятся всё жёстче. Разработчики и бизнес-пользователи продолжают находить одни и те же результаты, ставить одни и те же репозитории и получать один и тот же пустой вывод. Эта статья — проверка реальностью в 2026 году: честный разбор того, какие репозитории ещё заслуживают внимания, что именно Facebook делает, чтобы их ломать, и когда GitHub лучше сразу обойти стороной.
Почему вообще ищут Facebook Scraper на GitHub
Причины такого поиска годами остаются одними и теми же — даже если сами инструменты один за другим ломаются:
- Лидогенерация: сбор контактных данных бизнес-страниц (email, телефоны, адреса) для outreach
- Мониторинг маркетплейсов: отслеживание товарных объявлений, цен и информации о продавцах для e-commerce или арбитража
- Исследование групп: сохранение постов и комментариев для маркетинговых исследований, OSINT или управления сообществом
- Архивация контента и постов: сохранение публичных постов страниц, реакций, изображений и временных меток
- Агрегация событий: сбор названий событий, дат, локаций и организаторов
Привлекательность GitHub очевидна: код виден, доступ бесплатный, сообщество якобы поддерживает проект, и есть полный контроль над полями и пайплайном.
Проблема в том, что звёзды и форки не означают «сейчас работает». Среди 10 лучших репозиториев по точной фразе, ранжированных по звёздам, все 10 к апрелю 2026 года не обновлялись больше 12 месяцев. Это не случайность — это норма.
Один пользователь Reddit в треде ноября 2025 года после шести месяцев попыток прямо написал, что это было «невозможно без либо платного внешнего сервиса для сбора данных, либо Python плюс JS-rendering плюс серьёзные вычислительные ресурсы». Другой, в обсуждении апреля 2026 года, подытожил так: «Facebook — один из самых сложных для скрейпинга, потому что они агрессивно блокируют автоматизацию», а браузерная автоматизация «ненадёжна, поскольку Facebook постоянно меняет DOM».
Сценарии использования реальны. Спрос реальный. Разочарование тоже очень реальное. Дальше — о том, как пройти между этими крайностями.
Что вообще такое Facebook Scraper-репозиторий на GitHub?
Facebook scraper на GitHub — это open-source скрипт, обычно на Python, который программно извлекает публичные данные со страниц, постов, групп, Marketplace или профилей Facebook. Не все такие решения работают одинаково. Обычно доминируют три архитектуры:
Скрейперы на браузерной автоматизации, API-обёртки и прямой HTTP-скрейпинг
| Подход | Типичный стек | Сильная сторона | Слабая сторона |
|---|---|---|---|
| Браузерная автоматизация | Selenium, Playwright, Puppeteer | Может проходить login wall, имитирует поведение реального пользователя | Медленно, прожорливо по ресурсам, легко палится по fingerprint, если настроено неаккуратно |
| Официальная API-обёртка | Meta Graph API / Pages API | Стабильно, документировано, соответствует правилам при одобрении | Сильно ограничено — большинство публичных данных постов и групп уже недоступно |
| Прямой HTTP-скрейпер | requests, HTML parsing, undocumented endpoints | Быстро и легко, когда работает | Ломается при любом изменении структуры страницы Facebook или антибот-защиты |
kevinzg/facebook-scraper — классический пример прямого HTTP-подхода: он парсит публичные страницы «без API key» через прямые запросы и разбор HTML. apurvmishra99/facebook-scraper-selenium — пример браузерной автоматизации. minimaxir/facebook-page-post-scraper — представитель старой эпохи Graph API, когда скрипты могли тянуть посты страниц и групп через официальные endpoints, которые сегодня уже практически недоступны.
Обычно эти репозитории собирают текст постов, временные метки, счётчики реакций и комментариев, URL изображений, метаданные страницы (категория, телефон, email, число подписчиков), поля объявлений Marketplace, а также метаданные групп и событий.
В 2026 году реальный выбор — это не язык программирования. Это выбор того, какой тип поломки вы готовы терпеть.
Аудит актуальности Facebook Scraper на GitHub в 2026 году: какие репозитории действительно работают?
Я проверил самые популярные и самые рекомендуемые репозитории Facebook scraper на GitHub на основе реальных данных 2026 года — не описаний в README, а фактических дат коммитов, очередей issue и отчётов сообщества. Это самый важный раздел статьи.
Полная таблица аудита актуальности
| Репозиторий | Звёзды | Последний push | Открытые issues | Язык / runtime | Что ещё скрейпит | Статус |
|---|---|---|---|---|---|---|
| kevinzg/facebook-scraper | 3,157 | 2024-06-22 | 438 | Python ^3.6 | Ограниченные публичные посты страниц, часть комментариев/изображений, метаданные страницы | ⚠️ Частично сломан / устарел |
| moda20/facebook-scraper | 110 | 2024-06-14 | 29 | Python ^3.6 | То же, что kevinzg + вспомогательные методы для Marketplace | ⚠️ Частично сломанный / устаревший форк |
| minimaxir/facebook-page-post-scraper | 2,128 | 2019-05-23 | 53 | Эпоха Python 2/3, зависит от Graph API | Только как исторический ориентир | ❌ Заброшен |
| apurvmishra99/facebook-scraper-selenium | 232 | 2020-06-28 | 7 | Python + Selenium | Браузерная автоматизация для скрейпинга страниц | ❌ Заброшен |
| passivebot/facebook-marketplace-scraper | 375 | 2024-04-29 | 3 | Python 3.x + Playwright 1.40 | Объявления Marketplace через браузерную автоматизацию | ⚠️ Хрупкий / узкоспециализированный |
| Mhmd-Hisham/selenium_facebook_scraper | 37 | 2022-11-29 | 1 | Python + Selenium | Общий Selenium-скрейпинг | ❌ Заброшен |
| anabastos/faceteer | 20 | 2023-07-11 | 5 | JavaScript | Автоматизация с уклоном в workflow | ❌ Рискованно / мало доказательств |
Несколько выводов сразу бросаются в глаза:
- Даже «активный форк» (moda20) не обновлялся с июня 2024 года.
- Очереди issues говорят о реальном состоянии проекта быстрее, чем README.
- И kevinzg, и moda20 до сих пор указывают Python ^3.6 в своих pyproject.toml — это сигнал, что базовый стек зависимостей давно не обновлялся.
kevinzg/facebook-scraper
Самый известный Python Facebook scraper на GitHub. В его README описаны скрейпинг страниц, скрейпинг групп, вход через учётные данные или cookies, а также поля поста вроде comments, image, images, likes, post_id, post_text, text и time.
Но operational signal слабый:
- Последний push: 22 июня 2024
- Открытые issues: 438 — включая такие темы, как «Example Scrape does not return any posts»
- Мейнтейнер не отвечает на недавние issues
Вердикт: Частично сломан. Ещё может быть полезен для небольших экспериментов с публичными страницами и как справочник по названиям полей, но для production-подхода ненадёжен.
moda20/facebook-scraper (community fork)
Самый заметный форк kevinzg, с дополнительными опциями и helper-функциями для Marketplace, например extract_listing (описано в его README).
Очередь issues очень прямо показывает масштаб проблемы:
- «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. Его README до сих пор объясняет, как использовать 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, но в его очереди issues есть жалобы вроде «login to view the content», «CSS selectors outdated» и «Getting blocked». Это буквально краткий кейс того, что ломается в Marketplace scraping.
- apurvmishra99/facebook-scraper-selenium: в issues есть вопрос «Does it work with new Facebook layout?» ещё с сентября 2020 года. Этим почти всё сказано.
- Mhmd-Hisham/selenium_facebook_scraper и anabastos/faceteer: у них просто нет достаточной текущей активности, чтобы вызывать доверие.
Антискрейпинговые защиты Facebook: с чем сталкивается каждый GitHub-скрейпер
Большинство статей на эту тему ограничиваются расплывчатыми оговорками про «проверьте ToS». Это бесполезно.
У Facebook одна из самых жёстких антискрейпинговых систем среди крупных платформ. Понимание конкретных уровней защиты — это разница между рабочим скрейпером и половиной дня с пустым результатом.
В собственном engineering-посте Meta за февраль 2025 года описывается команда «Anti Scraping», которая применяет статический анализ по всему кодовому базе, чтобы выявлять векторы скрейпинга, отправляет cease-and-desist letters, блокирует аккаунты и использует системы rate limiting. Это не гипотеза — это организационная политика.
Случайные DOM и CSS-классы
Facebook намеренно рандомизирует HTML-идентификаторы, названия классов и структуру страниц. Как написал один комментатор на r/webscraping: «Ни один обычный скрейпер не сможет нормально работать с Facebook. HTML меняется даже между обновлениями страницы».
Что ломается: XPath- и CSS-селекторы, которые работали на прошлой неделе, сегодня возвращают пустоту.
Что делать: по возможности использовать селекторы, завязанные на текст или атрибуты. Лучше всего это переживают AI-подходы, которые читают содержимое страницы, а не полагаются на жёсткие селекторы. Поддержка селекторов — это постоянная статья расходов.
Login wall и управление сессиями
Многие поверхности Facebook — профили, группы, некоторые объявления Marketplace — требуют логина для просмотра. Headless-браузеры либо редиректятся, либо получают урезанный HTML. В issue-трекере Marketplace-скрейпера passivebot эта проблема — одна из самых частых: «login to view the content».
Что ломается: анонимные запросы не видят контент или сразу уходят в редирект.
Что делать: использовать session cookies из настоящей браузерной сессии или браузерные инструменты, работающие внутри вашей авторизованной сессии. Ротация аккаунтов возможна, но рискованна.
Цифровой fingerprinting
В engineering-посте Meta прямо сказано, что неавторизованные скрейперы «обычно маскируются, имитируя способы, которыми пользователи обычно используют продукт». По сути, это означает, что качество браузера и поведение сессии — ключевые сигналы для детекта. Обсуждения сообщества в марте и апреле 2026 продолжают советовать anti-detect браузеры и стабильные fingerprint-профили.
Что ломается: стандартные Selenium- или Puppeteer-настройки легко распознаются.
Что делать: использовать инструменты вроде undetected-chromedriver или anti-detect browser profiles. Реалистичные сессии и стабильный fingerprint важнее, чем простая подмена user-agent.
Rate limiting и блокировки по IP
В engineering-посте Meta rate limiting явно указан как часть защитной стратегии, включая ограничение размеров списков подписчиков, чтобы вынуждать больше запросов, которые затем упираются в rate controls. На практике пользователи сообщают, что их ограничивает по скорости уже после публикации в 10 группах с интервалом 10 секунд.
Что ломается: массовые запросы с одного IP в течение минут начинают тормозиться или блокироваться. Datacenter proxy часто блокируются заранее.
Что делать: ротация residential proxy, а не datacenter-прокси, плюс разумный темп запросов.
Изменения GraphQL-схемы
Некоторые скрейперы опираются на внутренние GraphQL-endpoints Facebook, потому что они возвращают более чистые структурированные данные, чем сырой HTML. Но Meta не публикует гарантий стабильности для внутреннего GraphQL, поэтому такие запросы ломаются молча — данные приходят пустыми, без явной ошибки.
Что ломается: структурированный сбор данных внезапно начинает возвращать пустоту.
Что делать: добавить проверки валидности, мониторить endpoints схемы и фиксировать рабочие запросы. Мейнтенанс неизбежен.
Сводка по антискрейпинговой защите
| Уровень защиты | Как он ломает скрейпер | Практическая мера |
|---|---|---|
| Изменчивый layout / нестабильные селекторы | XPath и CSS-селекторы возвращают пусто или только часть полей | Используйте более устойчивые якоря, сверяйте результат с видимым выводом страницы, закладывайте мейнтенанс |
| Login wall | Запросы без входа теряют контент или редиректятся | Используйте валидные session cookies или инструменты для браузерной сессии |
| Fingerprinting | Обычная автоматизация выглядит неестественно | Используйте реальный браузер, стабильное качество сессии, anti-detect меры |
| Rate limiting | Пустой вывод, блокировки, throttling | Замедляйте темп, уменьшайте batch size, ротация residential proxy |
| Изменения внутренних запросов | Структурированный сбор начинает возвращать пустые данные | Добавляйте проверки валидности, готовьтесь к обновлению запросов |
Когда GitHub-репозиторий не справляется: выбирайте разрешённую альтернативу
Поломка репозитория — не повод искать обходные пути мимо ограничений платформы. Сначала нужно чётко сформулировать бизнес-задачу: вам нужна аналитика уровня страницы, прозрачность рекламных объявлений, публичный каталог контактов или каталог товаров? Многие такие задачи можно закрыть через официальный продукт Meta, API с разрешениями или независимый публичный источник, не принадлежащий Meta.
Например, используйте Graph API только когда приложение и сценарий действительно получили нужные права, используйте исследовательские программы Meta только при наличии допуска, а для рекламной информации — Meta Ad Library. Для лид-исследований, цен и поиска локальных компаний чаще лучше подходят независимые публичные сайты, условия использования и privacy-обязательства которых можно проверить напрямую.
Примеры реального вывода: что вы получите на практике
Все статьи конкурентов показывают фрагменты кода, но почти никогда — реальный результат. Ниже — то, что можно ожидать от каждого подхода.
Пример вывода: kevinzg/facebook-scraper (или активный форк)
Из примера в README публичный пост после скрейпинга возвращает JSON примерно такого вида:
{
"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"
}
Обратите внимание на nullable-поля вроде comments_full. В 2026 году чаще будет возвращаться ещё больше пустых или отсутствующих полей — обычно это сигнал блокировки, а не безобидный сбой. Вывод — это сырой JSON, который ещё нужно дообрабатывать.
Пример вывода: Facebook Graph API
Текущая Pages API от Meta документирует запросы информации о странице, например GET /<PAGE_ID>?fields=id,name,about,fan_count. В reference для Page есть такие поля, как followers_count, fan_count, category, emails, phone и другие публичные метаданные — но только при наличии правильных разрешений, например Page Public Content Access или Page Public Metadata Access.
Это гораздо более узкий набор данных, чем ожидают многие пользователи GitHub-скрейперов. Он завязан на странице, требует разрешений и не заменяет произвольный скрейпинг постов или групп.
Матрица типов данных Facebook × способ доступа
| Тип данных Facebook | Наилучшая отправная точка | Главное ограничение |
|---|---|---|
| Активы, которыми управляет ваша организация | Официальные инструменты управления Meta и одобренные API | Права доступа и доступные поля зависят от случая |
| Наблюдения по рекламе | Meta Ad Library | Используйте только те поля и фильтры, которые она предоставляет |
| Публичные данные о бизнесе для лид-исследований | Разрешённый публичный каталог или сайт издателя, не связанный с Meta | Проверяйте условия использования и privacy-обязательства источника |
| Приватные материалы, закрытые группы, контент за login wall или данные только для аккаунта | Не автоматизируйте сбор | Ищите авторизованный путь |
Пошагово: как настроить Facebook Scraper с GitHub, если это вообще имеет смысл
Если вы прочитали аудит актуальности и всё ещё хотите идти через GitHub, что ж — вот практический путь, но с честными комментариями о том, где всё обычно ломается.
Шаг 1: Выберите правильный репозиторий (используйте аудит актуальности)
Вернитесь к таблице аудита. Возьмите самый свежий из подходящих репозиториев под вашу целевую поверхность. Перед установкой обязательно откройте вкладку Issues — свежие заголовки issues говорят о текущем состоянии лучше, чем README.
Шаг 2: Настройте Python-окружение
python3 -m venv fb-scraper-env
source fb-scraper-env/bin/activate
pip install -r requirements.txt
Типичная проблема: конфликты версий зависимостей, особенно Selenium/Playwright. И kevinzg, и moda20 указывают Python ^3.6 в своих pyproject.toml — это старый baseline, который может конфликтовать с более новыми библиотеками. В Marketplace-скрейпере passivebot зафиксирован playwright==1.40.0, что нормально для эксперимента, но не доказывает долговечность.
Шаг 3: Настройте прокси и антидетект
Если вы делаете что-то большее, чем быстрый тест:
- Настройте ротацию residential proxy (ищите провайдеров с Facebook-specific IP pools)
- Если используете браузерную автоматизацию, поставьте undetected-chromedriver или настройте anti-fingerprinting
- Не пропускайте этот шаг — обычный Selenium или Puppeteer быстро попадают под фильтр
Шаг 4: Запустите маленький тестовый скрейп и проверьте вывод
Начните с одной публичной страницы, а не с большой пачки. Внимательно проверьте результат:
- Пустые поля или пропавшие данные обычно означают, что вас блокируют защиты Facebook
- Сверьте вывод с тем, что вы реально видите на странице в браузере
- Успешный тест на одной странице важнее красивого README
Шаг 5: Обрабатывайте ошибки, rate limits и необходимость поддержки
- Закладывайте retry-логику и обработку ошибок
- Будьте готовы регулярно обновлять селекторы или конфигурации — это постоянный мейнтенанс, а не «настроил и забыл»
- Если вы тратите на поддержку скрейпера больше времени, чем на использование данных, это сигнал пересмотреть no-code-подход
Юридические и этические аспекты Facebook scraping
Условия платформы, privacy-правила, договорные обязательства и законы о защите данных — всё это может применяться одновременно. Публичная доступность не означает автоматическое разрешение на сбор данных. Сведите объём данных к минимуму, документируйте цель и правовое основание, а для коммерческих или масштабных программ получите юридическую консультацию.
Не считайте браузерное расширение, авторизованную сессию или пометку «public» разрешением на автоматический сбор данных из продуктов Meta.
Ключевые выводы: что реально работает для Facebook scraping в 2026 году
Актуальность репозитория, очереди issues и действующие правила платформы важнее числа звёзд и старого README. Когда бизнес-задача касается активов, которыми вы управляете, начинайте с официальных инструментов Meta и одобренных API. Для market research, лид-исследований и вопросов по ценам зачастую проще использовать разрешённый источник, не связанный с Meta, который легче документировать и администрировать.
FAQ
Есть ли в 2026 году рабочий Facebook scraper на GitHub?
Да, но выбор очень ограничен. Самый заметный вариант — форк moda20/facebook-scraper от оригинального репозитория kevinzg — см. таблицу актуальности выше, чтобы понять его текущее состояние. Он может частично скрейпить публичные посты страниц и часть метаданных, но его issues явно показывают поломки вокруг mbasic и пустой вывод. Большинство других репозиториев заброшены или полностью сломаны.
Можно ли скрейпить Facebook без программирования?
Используйте собственный поиск Facebook и его инструменты управления для ручного исследования. Для повторяемой или программной работы оцените официальный API и его permissions либо перестройте процесс вокруг разрешённого источника, не относящегося к Meta. Удобство no-code не отменяет требований платформы, privacy и договорных обязательств.
Законно ли скрейпить Facebook?
Terms of Service Facebook запрещают автоматический сбор данных без разрешения. Meta активно применяет это через блокировки аккаунтов, cease-and-desist письма и судебные иски. Законность зависит от юрисдикции и конкретного сценария. Ограничивайтесь публично доступными бизнес-данными, избегайте персональных профилей и при масштабировании консультируйтесь с юристом.
Какие данные ещё можно получить через Facebook Graph API?
В 2026 году Graph API сильно ограничен. Доступны только ограниченные данные уровня страницы — поля вроде id, name, about, fan_count, emails, phone — при наличии правильных permissions, например Page Public Metadata Access. Большая часть публичных постов, данных групп (и Groups API deprecated), а также user-level данных через API уже недоступна.
Как часто ломаются GitHub-репозитории для Facebook scraper?
Часто. Facebook постоянно меняет структуру DOM, антибот-механизмы и внутренние API — точного публичного графика нет, но отчёты сообщества показывают поломки каждые несколько недель у активных скрейперов. Очередь issues у форка moda20 вокруг исчезновения mbasic — свежий пример. Если вы полагаетесь на GitHub-репозиторий, закладывайте регулярный мейнтенанс и проверку корректности вывода.
Подробнее
