Как собрать данные с сайта в Markdown: Практическое руководство
TL;DR
Конвертация сайта в Markdown — это процесс извлечения, а не операция по удалению тегов: определите канонические страницы, получите правильное представление, изолируйте основной контент, конвертируйте структуру и проверьте выходные данные.
Начните с ограниченного списка URL или карты сайта, соблюдайте правила доступа и избегайте того, чтобы рассматривать навигацию, баннеры cookie и рекомендации как текст статьи.
Сохраните заголовки, ссылки, блоки кода, таблицы, канонический URL и время наблюдения; они часто более ценны для системы поиска, чем декоративный HTML.
Небольшая Python-пайплайн может обрабатывать статические страницы с помощью httpx, Beautiful Soup и markdownify. Отрисовывайте JavaScript только тогда, когда целевой контент отсутствует в начальном ответе.
Измеряйте достоверность контента на выборочных страницах перед индексацией всего сайта; хорошо выглядящий Markdown может все еще упускать важные факты или включать неправильную страницу.
Что значит «скрепировать» сайт в Markdown?
Скрепировать сайт в Markdown означает собрать авторизованные страницы и преобразовать их значимый контент в текстовый формат, который сохраняет структуру документа. Результат должен по-прежнему показывать иерархию заголовков, абзацы, ссылки, списки, код и таблицы. Файл, заполненный уплощенным текстом, проще производить, но сложнее цитировать, разбивать на части или рецензировать.
Работа состоит из двух отдельных частей. Обнаружение определяет, какие URL попадают в область охвата. Извлечение определяет, какая часть каждой извлеченной страницы является настоящим контентом. Библиотека конвертации может обрабатывать синтаксис HTML в Markdown, но она не может знать, является ли модальное окно рассылки частью статьи или выбрана ли правильная вариация продукта. Руководство по обнаружению URL веб-сайтов охватывает первую проблему; этот учебник сосредоточен на второй.
Для крупных или сайтов с тяжелым JavaScript Nstdata Crawl является вариантом получения, который следует оценить на представительных публичных страницах. Независимо от того, используете ли вы управляемый сервис или локальный Python, выходные данные все равно нуждаются в контроле охвата, происхождении и человеческом обзоре.
Попробуйте Nstproxy Crawl - Начните Бесплатно Уже Сегодня
Шаг 1: Определите источник и контракт выходных данных
Начните с явного списка URL, которые вы можете обрабатывать. Карта сайта является удобной отправной точкой, но отфильтруйте ее по имени хоста и префиксу пути. Исключите URL для входа, корзины, поиска и дублирующие параметризованные URL, если они не являются частью задачи. Обзор карт сайта Google описывает карты сайта как подсказки для обнаружения, а не гарантии того, что перечисленные страницы являются действительными или полными.
Определите желаемую запись Markdown перед кодированием. Полезный минимум включает source_url, final_url, title, fetched_at, content_hash и markdown. Если страница может варьироваться в зависимости от локали, аккаунта или варианта продукта, также захватите этот контекст. Не создавайте имя файла только из необработанного URL; длинные пути, строка запроса и коллизии делают это ненадежным. Используйте стабильный слог и хэш или ключ базы данных.
Установите целевой уровень качества: например, Markdown должен сохранять каждый H2, основные примеры кода и внешние ссылки, исключая меню и навигацию в подвале. Эта цель может быть проверена на образце. Высокое количество символов не является метрикой качества, если большинство символов — это стандартный текст.
Шаг 2: Извлеките страницу с ограниченными запросами
Следующий пример использует Python 3, httpx, Beautiful Soup и markdownify. Установите их с помощью python -m pip install httpx beautifulsoup4 markdownify. Код запрашивает один публичный URL, устанавливает тайм-аут, проверяет тип контента и конвертирует элемент main страницы, если он доступен. Резервный вариант для article или body намеренно консервативен только для демонстрации; проверьте разметку целевого сайта перед выполнением в больших масштабах.
from datetime import datetime, timezone
from hashlib import sha256
from urllib.parse import urlparse
import httpx
from bs4 import BeautifulSoup
from markdownify import markdownify as to_markdown
defpage_to_markdown(url:str)->dict[str,str]: parsed = urlparse(url)if parsed.scheme notin{"http","https"}:raise ValueError("Only HTTP(S) URLs are allowed")with httpx.Client( timeout=15.0, follow_redirects=True, headers={"User-Agent":"ContentResearchExample/1.0"},)as client: response = client.get(url) response.raise_for_status() content_type = response.headers.get("content-type","").lower()if"text/html"notin content_type:raise ValueError(f"Expected HTML, got {content_type}") soup = BeautifulSoup(response.text,"html.parser")for node in soup.select("script, style, nav, footer, aside, form"): node.decompose() main = soup.select_one("main")or soup.select_one("article")or soup.body
if main isNone:raise ValueError("No content container found") title = soup.title.get_text(" ", strip=True)if soup.title else"Untitled"markdown = to_markdown(str(main), heading_style="ATX").strip()iflen(markdown)<40:raise ValueError("Извлеченное содержимое неожиданно короткое")return{"source_url": url,"final_url":str(response.url),"title": title,"fetched_at": datetime.now(timezone.utc).isoformat(),"content_hash": sha256(markdown.encode()).hexdigest(),"markdown": markdown,}if __name__ =="__main__": record = page_to_markdown("https://example.com/")print(record["title"])print(record["markdown"][:300])
Этот пример намеренно не рекурсивен и не обходит средства контроля доступа. Защита len ловит явно пустой результат, а не результат с неправильным содержимым. Тестируйте страницы с таблицами, кодовыми блоками и встроенными ссылками, прежде чем доверять конвертеру. Определение main элемента из спецификации HTML является полезной семантической отправной точкой, но многие сайты не используют его последовательно.
Шаг 3: Улучшение выбора основного содержимого
Широкий селектор в примере является лишь базовым уровнем. Экстрактор в производственной среде должен использовать правило, специфичное для источника, когда сайт имеет стабильную обертку статьи, и возвращаться к экстрактору в стиле удобочитаемости, когда макет варьируется. Сравните исходную страницу и Markdown бок о бок. Ищите отсутствующие введения, дублирующиеся заголовки, встроенные сноски, карточки связанных постов и контент, который встраивается ниже статьи.
Не удаляйте каждый aside без разбора, когда редакторский aside содержит предупреждение или определение. Аналогично, удаление всех таблиц или изображений может убрать единственное представление спецификации. Заменяйте значимые изображения на текст alt или ссылку, когда ваше последующее использование нуждается в них. Для образцов кода убедитесь, что отступы и ограждения сохраняются после конверсии. Для ссылок предпочтительнее использовать абсолютные URL и сохранять текст ссылок описательным; в противном случае цитаты в ответах на извлечение могут не привести никуда.
Методы извлечения HTML сравнивают подходы к парсингу. Для корпуса извлечения сохранение структуры обычно важнее, чем максимизация сжатия простого текста. Делите только после того, как вы осмотрели верный документ, и сохраняйте путь заголовка с каждым фрагментом.
Шаг 4: Умышленно обрабатывать страницы с рендерингом на JavaScript
Если начальный HTTP-ответ содержит только оболочку приложения, приведенный пример на Python не может извлечь статью, потому что текст приходит позже через клиентские запросы. Подтвердите это, просмотрев тело ответа и отрисованный DOM браузера. Затем выберите авторизованный API источника, рендерер браузера или управляемую рендеринговую службу. Не рендерьте каждую страницу по умолчанию: это добавляет задержку, затраты и точки сбоя, не помогая статическим страницам.
Руководство по обработке страниц на Python с рендерингом на JavaScript объясняет эту диагностику более подробно. При использовании рендерера ожидайте контентно-специфического сигнала, а не фиксированного времени ожидания. Страница может быть визуально завершенной, в то время как таблица или список цитат все еще загружаются. Записывайте, поступил ли результат из исходного HTML или отрисованного DOM, потому что один и тот же URL может производить разный контент в каждом пути.
Если доступ требует аутентификации, используйте только учетные записи и контент, которые вам явно разрешено обрабатывать. Не превращайте сессию браузера в неявную лицензию на сбор частных страниц. Для публичных страниц проверьте robots.txt и условия сайта; RFC 9309 определяет протокол для роботов, а не полный набор юридических прав на повторное использование контента.
Шаг 5: Проверка и хранение Markdown
Создайте тестовый образец, который включает самые сложные типы страниц сайта: короткие страницы, длинные статьи, таблицы, код, вложенные списки и страницы с множеством рекомендаций. Для каждого образца сравните основные заголовки, первый и последний абзацы, известный факт, ссылки и любой критически важный кодовый блок. Отметьте страницу как неудавшуюся, если важный контент отсутствует, даже если Markdown синтаксически валиден.
Убирайте дубликаты по каноническому URL и контентному хешу, но сохраняйте историю наблюдений. Изменение хеша может означать значительное редактирование или просто вращающуюся рекомендацию. Сравните разницу основного содержимого перед повторной индексацией. Храните необработанный или отрендеренный источник в соответствии с политикой хранения, чтобы можно было исследовать ошибки извлечения. Если контент содержит персональные данные, сохраняйте только то, что необходимо для использования, и распространяйте удаление на копии и индексы.
Для рабочего процесса извлечения храните метаданные рядом с каждым файлом Markdown или фрагментом: URL, заголовок, путь заголовка, время извлечения, версия источника и права доступа. Руководство по веб-скрапингу и RAG LlamaIndex предлагает более широкий контекст для восприятия. Не маркируйте извлеченный ответ как «живой» только потому, что файл Markdown был создан с помощью веб-скрапера один раз.
Общие ошибки и как их диагностировать
Если каждый файл начинается с одного и того же текст навигации, выбор контента слишком широк. Если файлы почти пусты, проверьте, рендерится ли страница с помощью JavaScript, заблокирована, перенаправлена или просто не является статьей. Если ссылки становятся относительными, разрешите их относительно окончательного загруженного URL перед преобразованием. Если таблица сжимается в один абзац, выберите конвертер или этап постобработки, который сохраняет семантику таблицы, и проверьте результат вручную.
Если появляются дубликаты страниц, нормализуйте только на самом деле несущественные параметры; не объединяйте вариации продуктов или языки. Если заголовки отсутствуют, проверьте, были ли они отрендерены как стилизованные элементы div, а не семантические заголовки. Надежный конвейер должен сообщать об этом как о исключениях типа страницы, а не тихо выдавать плохой Markdown.
Заключение
Хорошая извлечение сайта в Markdown - это контролируемая трансформация с четким набором источников, верным выбором основного контента, структурным преобразованием и выборочной проверкой. Начните с нескольких представительных публичных страниц, сравните исходный и выходной материалы, затем расширьте область URL. Сохраняйте происхождение, чтобы каждый отрывок в системе поиска или RAG можно было проследить до страницы и времени наблюдения.
Протестируйте рабочий процесс преобразования страницы в Markdown
Если локальный парсинг не охватывает ваши авторизованные типы страниц, оцените Nstdata Crawl на небольшом наборе с известными ожидаемыми заголовками и ссылками. Сохраняйте тот же контракт валидации и метаданных, независимо от инструмента приобретения.
В: Могу ли я конвертировать целый сайт в Markdown одним запросом?
Нет. Один запрос конвертирует один ответ. Рабочий процесс для всего сайта также требует ограниченного обнаружения URL, загрузки по страницам, дедупликации, планирования и валидации.
В: Должен ли Markdown включать изображения?
Markdown должен сохранять значимые изображения в качестве ссылок или альтернативного текста, когда они передают информацию, необходимую в дальнейшем. Декоративные изображения обычно можно опустить, но диаграммы и графики могут потребовать отдельного извлечения или описания.
В: Лучше ли Markdown, чем HTML для RAG?
Markdown часто проще проверять и разбивать на части, но точность важнее, чем формат. Если преобразование теряет таблицы, цитаты или код, оригинальный HTML или более богатое представление могут быть лучше.
В: Как мне узнать, нуждается ли страница в рендеринге JavaScript?
Сравните начальный HTTP-ответ с отрендеренной страницей. Если требуемый контент отсутствует в ответе, но присутствует после выполнения на клиентской стороне, используйте авторизованный путь рендеринга или API и проверьте на наличие специфического контента.
Lena Zhou
Oct. 13th 2026
Сканируйте целые сайты одним API-запросом
Успешность 99,8% с рендерингом JavaScript
Получайте чистые данные для LLM в разных форматах
Преобразуйте любой сайт в Markdown, HTML, JSON, ссылки, PDF и другие форматы без управления инфраструктурой сканирования.
