developer api

API метаданих веб-сторінок для перевірки публічних сторінок

ScraperFly допомагає командам захоплювати контекст публічної сторінки перед зберіганням, індексацією, підсумовуванням, контролем якості або моніторингом URL: фінальний URL, статус, тип контенту, метадані сторінки, заголовки, посилання, читабельний контент, Markdown та візуальне підтвердження, коли це необхідно.

Спочатку контекст сторінки

Перевірте метадані перед тим, як URL потрапить у ваш конвеєр

ScraperFly допомагає командам захоплювати практичний контекст навколо публічної сторінки перед тим, як цей URL стане частиною пошуку, моніторингу, споживання AI, контролю якості, збагачення або звітності. Замість того, щоб розглядати кожну сторінку як завдання для обходу, почніть з одного реального відгуку та перевірте, що насправді повертає ціль.

Відповідь може включати фінальний URL, статус, тип контенту, розмір відповіді, метадані, заголовки, посилання, читабельний текст, Markdown та візуальне підтвердження, коли це необхідно. Це дає розробникам достатньо доказів, щоб вирішити, чи готова сторінка до подальшої обробки, чи покращить рендеринг, заголовки, сесії, цільове націлювання або більш потужна доставка результат.

метаданізаголовкипосиланняJSON контекст

Розробники переглядають метадані веб-сторінки, заголовки, посилання та контекст відповіді з публічної сторінки

Що таке API метаданих веб-сторінок?

API метаданих веб-сторінок отримує публічний URL і повертає контекст сторінки, який допомагає додатку зрозуміти, що повернулося. Цей контекст може включати заголовок сторінки, метаопис, канонічний URL, директиви для роботів, теги Open Graph, теги карток Twitter, заголовки, посилання, фінальний URL, HTTP статус, тип контенту, розмір відповіді, чистий текст, Markdown, скріншоти або PDF в залежності від профілю запиту.

Це відрізняється від повного обходчика або завершеного набору SEO-аудиту. API метаданих надає вашій системі надійні докази з запитуваної сторінки. Ваш продукт може потім вирішити, що зберігати, індексувати, порівнювати, класифікувати, підсумовувати, збагачувати або передавати в інший робочий процес. Ця межа важлива, оскільки вона зберігає сторінку корисною, не обіцяючи аналітики графа посилань, моніторингу зламаних посилань, відстеження ранжування або вилучення полів, специфічних для цілей, які належать до окремого шару.

Практичний висновок: використовуйте захоплення метаданих веб-сторінок, коли вашому продукту потрібен надійний контекст сторінки перед тим, як він прийме рішення про зберігання, парсинг, моніторинг або AI.

Які метадані повинні захоплювати команди з публічної сторінки?

Правильні метадані залежать від робочого процесу. Пошуковий індекс може цікавитися заголовком, описом, заголовками, канонічним URL та читабельним контекстом тіла. Робочий процес контролю якості може потребувати фінального URL, статусу, розміру відповіді, скріншоту та підтвердження PDF. AI-потік може потребувати чистого тексту або Markdown з достатньою метаданою джерела, щоб пояснити, звідки прийшла відповідь. Інвентаризація контенту може потребувати посилань, заголовків, мови, сигналів публікації та відносин сторінок.

ScraperFly є найсильнішим, коли команди використовують метадані як шар прийняття рішень. Захоплюйте відповідь сторінки, перевіряйте важливі поля та зберігайте запит легким, якщо ціль не доведе, що їй потрібна додаткова допомога. Якщо вихідний HTML вже містить заголовок сторінки, заголовки, метадані та корисні посилання, простий запит зазвичай достатній. Якщо фронтенд JavaScript змінює корисний контекст, рендеринг може бути доданий для цього типу сторінки.

Область метаданих	Приклади	Найкраще підходить для	Рішення запиту
Контекст відповіді	Фінальний URL, статус, тип контенту, розмір відповіді	Логування, контроль якості, налагодження, рішення про зберігання	Захоплюйте на кожному репрезентативному зразку.
Метадані HTML заголовка	Заголовок, метаопис, роботи, канонічний	Пошукова індексація, інвентаризація контенту, контроль якості сторінок	Почніть з вихідного HTML, а потім порівняйте рендеринг, коли поля відсутні.
Метадані соціального попереднього перегляду	Поля Open Graph та карток Twitter	Контроль якості попереднього перегляду, огляд контенту, збагачення	Перевірте репрезентативні шаблони перед масштабуванням.
Структура сторінки	Заголовки H1-H3, секції, читабельний текст, Markdown	Споживання AI, перевірки якості контенту, підсумовування	Виберіть Markdown або текст, коли деталі DOM не потрібні.
Посилання на сторінку	Канонічний, внутрішні посилання, зовнішні посилання, hreflang	Контекст односторінкової, підказки для відкриття, перевірки локалізації	Використовуйте як доказ сторінки, а не як повний граф обходу сам по собі.
Візуальне підтвердження	Скріншот або захоплення PDF	Архів, огляд, відповідність, контроль якості людиною	Додавайте лише тоді, коли візуальний запис змінює результат робочого процесу.

Коли захоплення метаданих потребує рендерингу?

Захоплення метаданих потребує рендерингу, коли вихідна відповідь не містить контексту сторінки, який потрібен вашому робочому процесу. Деякі публічні сторінки надсилають повний HTML заголовок і значущі заголовки відразу. Інші надсилають тонку оболонку програми і дозволяють JavaScript на стороні браузера оновлювати теги заголовків, маршрутизувати контент, динамічні заголовки, посилання, модулі продуктів або читабельні секції тіла після завантаження сторінки.

Практичний крок - це порівняння, а не припущення. Спочатку отримайте вихідний HTML. Якщо метадані, заголовки та корисні посилання присутні, зберігайте запит легким. Якщо сторінка виглядає порожньою, загальною або неповною, порівняйте рендерену відповідь. Додавайте затримки лише тоді, коли контент, що завантажується пізніше, змінює вихід. Використовуйте сесії, заголовки, цільове націлювання або більш потужну маршрутизацію лише тоді, коли ці контролі змінюють докази відповіді.

Для сторінок, де JavaScript є вирішальним фактором, поєднайте цей робочий процес з API рендерингу JavaScript. Для сторінок, де вилучення посилань є основним завданням, використовуйте вужчий API парсера посилань веб-сторінок. Захоплення метаданих знаходиться між цими потребами: воно надає достатньо контексту сторінки, щоб розумно вибрати наступний крок.

Чим це відрізняється від парсингу контенту?

Парсинг контенту зосереджується на сутності, яку споживатимуть користувачі або системи нижнього рівня: чистий текст, Markdown, основний контент, тіло статті, підсумки або структурований вихід. Захоплення метаданих зосереджується на навколишніх доказах, які говорять системі, що таке сторінка, що сталося під час доставки, як сторінка ідентифікує себе і чи є відповідь достатньо надійною для подальшої обробки.

Обидва є корисними, але вони відповідають на різні запитання. Парсер контенту запитує: "Що ми повинні прочитати або вилучити з цієї сторінки?" Робочий процес метаданих запитує: "Що повернув цей URL, як ми повинні це інтерпретувати і чи варто це відправляти на наступний етап?" ScraperFly може підтримувати обидва формати відповіді, тому команди можуть почати з контексту сторінки, а потім перейти до тексту, Markdown, JSON метаданих, скріншотів, PDF або специфічного парсингу, коли це потрібно в робочому процесі.

Потреба	Використовуйте метадані, коли	Використовуйте парсинг контенту, коли
Підготовка до пошукового індексу	Вам потрібні заголовок, канонічний, заголовки, статус і контекст джерела.	Вам потрібен чистий текст або документ Markdown для індексації.
Споживання AI	Вам потрібні походження, фінальний URL, тип контенту та структура сторінки.	Вам потрібен читабельний контент для вбудовування, підсумків або відповідей.
Моніторинг	Вам потрібні статус, розмір відповіді, поведінка перенаправлення та видимі докази.	Вам потрібно порівняти конкретні поля сторінки з часом.
Відкриття	Вам потрібні посилання та відносини сторінки з однієї відповіді.	Вам потрібні вилучені сутності з самої сторінки.
Огляд людиною	Вам потрібен достатній контекст, щоб вирішити, чи є відповідь дійсною.	Вам потрібна очищена стаття, запис продукту або підсумок сторінки.

Як команди можуть зберегти робочі процеси метаданих практичними?

Почніть з репрезентативних URL і визначте важливі поля перед масштабуванням. Робочий процес метаданих стає шумним, коли збираються всі можливі поля без подальшої причини. Він стає крихким, коли команди вважають, що вихідний HTML, рендерений DOM, скріншот і Markdown є взаємозамінними. Кожен формат виходу має свою задачу: метадані відповіді пояснюють доставку, HTML зберігає структуру, Markdown допомагає читанню та споживанню AI, JSON зберігає оперативний контекст для перевірки, а візуальні файли підтверджують, як виглядала сторінка.

Шлях контролю витрат простий. Залишайте прості сторінки на вихідному HTML. Увімкніть рендеринг лише тоді, коли JavaScript змінює метадані або читабельний контент. Використовуйте скріншоти або PDF, коли візуальне підтвердження важливе. Використовуйте цільове націлювання, сесії, заголовки та преміум маршрутизацію, коли вони вирішують продемонстровану проблему відповіді. Потім скопіюйте перевірений профіль запиту з API Builder у додаток замість того, щоб відновлювати логіку запиту з нуля.

Практичний висновок: захоплення метаданих є найбільш корисним, коли воно допомагає вашому продукту приймати краще наступне рішення, а не коли воно збирає поля лише тому, що вони існують.

Де ScraperFly вписується в метадані?

ScraperFly знаходиться на рівні запиту та відповіді. Він отримує публічну сторінку, застосовує контролі, які потрібні вашій цілі, і повертає форму відповіді, яку може використовувати ваш робочий процес. Метадані можуть зберігати контекст відповіді, передавати чистий текст або Markdown системам AI, записувати скріншоти для контролю якості, порівнювати структуру сторінки або передавати вибрані посилання в окремий робочий процес відкриття.

Це зберігає чіткість власності. ScraperFly допомагає з захопленням, рендерингом, маршрутизацією, форматами відповіді, файлами та доказами запиту. Ваша програма володіє стратегією обходу, оцінюванням, дедуплікацією, правилами збагачення, сповіщеннями та бізнес-рішеннями. Це розділення робить систему легшою для налагодження, оскільки кожен етап має чітку задачу.

Потік метаданих

Створіть запит на перевірку сторінки перед тим, як URL потрапить у виробництво

Виберіть форму відповіді, яка надає вашій команді реальний контекст сторінки: вихідний HTML, коли метадані вже присутні, рендерений вихід, коли JavaScript його змінює, JSON контекст для логування та візуальні файли, коли важливе підтвердження.

КОНТЕКСТ СТОРІНКИ

Метадані, заголовки та посилання

Перевірте заголовки, описи, канонічні сигнали, заголовки та посилання на сторінку з запитуваної публічної відповіді перед зберіганням або індексацією.

ДОКАЗИ ВІДПОВІДІ

Статус, фінальний URL та тип контенту

Зберігайте контекст доставки видимим, щоб ваша програма знала, чи є відповідь дійсною, перенаправленою, порожньою, надмірною або вартою рендереного порівняння.

ВИКОРИСТОВУВАНИЙ ВИХІД

HTML, Markdown, JSON, скріншот або PDF

Поверніть робочий процес метаданих у форматі, на який ваш продукт може реагувати, від легкого JSON контексту до візуальних доказів для огляду та архівних робочих процесів.

Параметри запиту метаданих

url

Публічна сторінка, яку ScraperFly має перевірити.

format

Виберіть HTML, текст, Markdown, JSON контекст, скріншот або PDF на основі робочого процесу.

render

Використовуйте виконання в браузері, коли вихідний HTML не містить корисних метаданих або заголовків.

country

Маршрутизуйте через регіональне місцезнаходження, коли метадані або вміст змінюються в залежності від ринку.

keep_headers

Зберігайте дозволений контекст запиту, такий як мова або прийнятий тип вмісту.

download

Поверніть скріншоти або PDF файли, коли потрібен візуальний запис.

приклад cURL

Генеруйте Markdown з тією ж формою запиту, яку ви можете перенести в продукцію

curl "https://scraperfly.com/api/v1?url=https%3A%2F%2Fexample.com&format=markdown" \
  -H "apikey: YOUR_API_KEY"

Вимоги до метаданих

Складіть карту сигналів сторінки, які мають значення, перед збором всього

Потік метаданих є найсильнішим, коли кожне поле має подальшу задачу. Визначте, чи потрібна продукту діагностика відповіді, метадані заголовка, заголовки, посилання, читабельний вміст, Markdown або візуальне підтвердження перед масштабуванням обсягу запитів.

Сирова HTML-відповідь, відображена на видимих даних сторінки

Доступність сирого HTML

Перевірте, чи поля, які вам потрібні, вже присутні в першій HTML-відповіді.

Найкращий перший тест для простих сторінок, статей, документів, списків та деталей продуктів.

Порівняння до і після рендерингу JavaScript

Залежність від JavaScript

Порівняйте сирий HTML з відрендереним DOM або скріншотом перед увімкненням рендерингу браузера.

Використовуйте рендеринг, коли сирий HTML є лише оболонкою, а скрипти створюють корисний контент.

Куки, згода, контекст сесії та доступу для скрапінгу

Стан і контекст доступу

Визначте, чи впливають куки, згода, межі входу, пагінація або той самий стан відвідувача на відповідь.

Використовуйте сесії та заголовки, коли безперервність змінює дані, які ви отримуєте.

Регіональні варіації контенту в різних країнах і маршрутах

Гео/варіація контенту

Перевірте, чи змінюють країна, мова, валюта, інвентар, SERP, реклама або репутація маршруту результат.

Використовуйте гео- або преміум-маршрути лише тоді, коли ціль підтверджує, що відповідь змінюється залежно від маршруту.

Питання, на які потрібно відповісти перед масштабуванням

Де знаходиться цільове поле?

Знайдіть, чи існує поле в сирому HTML, відрендереному DOM, виклику API, структурованих даних, файлі або пізнішому стані взаємодії.

Що змінює відповідь?

Виберіть кілька URL-адрес і порівняйте статус, фінальну URL-адресу, довжину вмісту, перенаправлення, порожні стани та видимі відмінності результатів.

Який контекст потрібен?

Позначте будь-яку залежність від згоди, локалі, куків, заголовків, межі аутентифікації, пагінації, фільтрів або попередніх запитів.

Як виглядає невдача?

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

Визначте контракт на метадані

Режим отримання

Доступність сирого HTML визначає, чи може перший запит залишатися простим або потребує рендерингу, очікувань, скріншотів або витягування.

Контекст запиту

Вимоги до стану визначають, чи потрібно додавати заголовки, куки, сесії, обробку згоди або стабільний профіль відвідувача.

Вибір маршруту

Гео та репутаційні дані визначають, чи достатньо стандартного маршруту або виправданий маршрут країни/преміум.

Правила валідації

Відомі стани невдачі стають перевірками для повторних спроб, ескалації, перевірки якості та визначення, коли легший профіль все ще є повним.

Практичне порівняння

Виберіть захоплення метаданих, яке підтверджує сторінку перед важчими інструментами

Багато інструментів розмивають метадані сторінки, краулінг, рендеринг і моніторинг в одну велику обіцянку. ScraperFly легше зрозуміти: перевірте відповідь запитуваної сторінки, зберігайте просте захоплення метаданих легким і додавайте важчі контролі лише тоді, коли ціль доводить, що вони покращують докази.

Почніть з легкості

Захопіть контекст сторінки перед впровадженням інфраструктури

Перевірте реальну URL-адресу, перевірте відповідь і підтвердіть метадані, які потрібні вашій системі, перш ніж створювати краулери, черги, інформаційні панелі або логіку збагачення навколо цього.

Залишайтеся точними

Тримайте метадані окремо від обіцянок повного сканування

Використовуйте повернені посилання та заголовки як докази сторінки, а потім дайте вашому продукту вирішити, чи планувати сканування, оцінювання, сповіщення або аналіз на рівні домену.

Масштабуйте розумно

Оновлюйте лише ті контролі запиту, які змінюють результат

Візуалізація, затримки, сесії, маршрутизація по країнах та візуальні файли залишаються необов'язковими, тому прості сторінки залишаються доступними, в той час як складні цілі все ще мають чистий шлях вперед.

Де ScraperFly виграє проти типових альтернатив

Суть не в тому, щоб стверджувати, що всі конкуренти погані. Суть у відповідності: ScraperFly є кращим вибором, коли ви хочете робочий процес, орієнтований на API, видимі контролі запитів, гнучкі кредити та формати відповідей, які допомагають вам доставляти, а не піклуватися про інфраструктуру.

Точка прийняття рішенняПеревага ScraperFlyТиповий компроміс конкурентів

Перевірка однієї сторінкиОтримайте запитувану публічну URL-адресу та перевірте метадані відповіді, заголовки, посилання та форму виходу перед тим, як вирішити наступний крок.Деякі платформи швидко переходять від метаданих до обіцянок краулінгу, моніторингу або збагачення, не уточнюючи межі відповіді.

Рішення про рендерингПорівняйте вихідні та рендерені відповіді, а потім увімкніть виконання в браузері лише тоді, коли JavaScript змінює корисні метадані або контент.Виконання в браузері може бути представлене як стандартний шлях, навіть коли вихідний HTML вже містить контекст сторінки.

Вибір виходуВикористовуйте HTML, текст, Markdown, JSON-контекст, скріншот або PDF в залежності від того, на що може діяти подальший робочий процес.Формати списків є поширеними, але логіка прийняття рішень для їх вибору часто є поверхневою.

Контроль витратЗберігайте захоплення метаданих легким і залишайте важчі профілі запитів для цілей, які доводять, що вони їх потребують.Об'єднані припущення про краулери або моніторинг можуть зробити ранню валідацію дорожчою, ніж потрібно.

Контроль витрат

Тримайте захоплення метаданих узгодженим з реальною відповіддю

Робочі процеси з метаданими не повинні бути дорогими за замовчуванням. Почніть з вихідного HTML, перевірте, чи присутні поля, і додавайте рендеринг, скріншоти, PDF, маршрутизацію, сесії або затримки лише тоді, коли вони змінюють результат.

Джерело метаданих у першій відповіді

Коли заголовок, канонічна URL-адреса, заголовки, посилання та корисний контент вже присутні, тримайте запит простим і швидким.

Візуалізація для контексту, створеного на JavaScript

Використовуйте виконання браузера, коли метадані або читабельний контент з'являються лише після виконання коду на стороні клієнта.

Скриншоти та PDF для людського перегляду

Генеруйте файли, коли QA, затвердження, відповідність або архівні робочі процеси потребують видимого запису сторінки.

Заголовки, країна, сесії та більш надійна доставка

Додавайте контекст запиту лише тоді, коли він змінює метадані, вміст, перенаправлення або поведінку доступу для цільової сторінки.

Що робить запит важчим

Більше роботи з інфраструктурою

Рендеринг браузера, вибір маршрутизації та довші очікування означають, що платформа повинна виконувати більше, ніж просто повертати просту відповідь.

Більша невизначеність цілі

Редиректи, порожні стани, обмеження швидкості та сторінки викликів часто вимагають більш потужних варіантів доставки або повторних спроб.

Більше стану для збереження

Cookies, сесії, згода та багатосторінкові потоки додають рухомі частини, яких немає у простому безстатевому запиті.

Більше доказів для повернення

Скріншоти, PDF, рендерений вихід та багатші артефакти відповіді корисні, але вони важчі за простий HTML.

Як зберегти вагу запиту передбачуваною

Вибірка перед масштабуванням

Спочатку протестуйте невелику вибірку URL та групуйте цілі за найменшим профілем, який повертає повні дані.

Не рендерити за замовчуванням

Перевірте сирий HTML перед увімкненням рендерингу. Багато публічних сторінок вже містять необхідні вам дані.

Ескалація за доказами

Підвищуйте лише тоді, коли відповідь показує відсутній контент, залежність стану, гео варіацію або проблеми з маршрутизацією.

Вимірюйте корисні результати

Оптимізуйте навколо дійсних записів, що доставляються, а не сирого обсягу запитів. Легший профіль найкращий лише тоді, коли він залишається повним.

Запитання про метадані

Загальні питання про захоплення метаданих веб-сторінки

Практичні відповіді для команд, які вирішують, який контекст сторінки збирати, коли візуалізувати, як метадані відрізняються від парсингу вмісту та як уникнути перетворення перевірки сторінки на важку роботу з краулінгом.

Часті запитання про метадані

SCOPE

Контекст сторінки, а не краулер

Захоплення метаданих починається з відповіді на запитувану публічну сторінку.

Чи обходить це кожне посилання на веб-сайті?

Ні. Він захоплює докази з запитуваної публічної сторінки. Повернені посилання можуть живити краулер або чергу, але планування краулінгу та аналіз графа посилань належать до подальших етапів.

Чи може це підтримувати SEO QA?

Так. Він може захоплювати заголовок, опис, канонічну URL-адресу, заголовки, підказки для роботів, посилання, фінальну URL-адресу, статус та візуальне підтвердження для робочих процесів контролю якості на рівні сторінки.

FIELDS

Що збирати

Виберіть метадані на основі завдання, яке ваш продукт має виконати далі.

Які поля метаданих є найважливішими?

Звичайні поля включають заголовок, метаопис, канонічну URL-адресу, підказки для роботів, теги Open Graph, заголовки, посилання, фінальну URL-адресу, статус, тип контенту та розмір відповіді.

Чи є метадані тим самим, що й витягування контенту?

Ні. Метадані пояснюють відповідь сторінки та її контекст. Витягування контенту зосереджується на читабельному основному контенті, сутностях, полях або записах для подальшого використання.

RENDERING

Коли вихідний HTML неповний

Візуалізація браузера корисна лише тоді, коли вона змінює захоплені докази.

Коли слід використовувати візуалізацію для захоплення метаданих?

Використовуйте візуалізацію, коли вихідний HTML пропускає корисні метадані, заголовки, посилання або читабельний контент, який з'являється після виконання JavaScript на фронтенді.

Чи повинна кожен запит метаданих візуалізувати сторінку?

Ні. Почніть з вихідного HTML і порівняйте візуалізований вихід лише тоді, коли відповідь виглядає неповною або відомо, що ціль покладається на JavaScript.

OUTPUT

Вибір використовуваних форматів відповіді

Найкращий вихід - це той, який наступна система може використовувати безпосередньо.

Коли мені слід використовувати скріншоти або PDF?

Використовуйте візуальні файли, коли контроль якості, відповідність, архів, затвердження або людський перегляд потребують доказів того, як сторінка виглядала в момент захоплення.

Як можна зберегти доступність захоплення метаданих?

Залишайте вихідний HTML за замовчуванням, додавайте рендеринг або візуальний вихід лише за необхідності, і залишайте контролі маршрутизації для цілей, де вони змінюють відповідь.