Індексація PDF у Google починається з перетворення документа на внутрішнє HTML-представлення. Пошуковик витягує доступний текст і посилання, а потім передає їх далі своїм системам. Публічної HTML-сторінки при цьому не створюється: у результатах пошуку користувач може й надалі бачити PDF.
Цей процес Мартін Сплітт і Джон Мюллер пояснили у випуску Search Off the Record від 13 жовтня 2026 року. Розмова описує наявні механізми пошуку й практичні труднощі роботи з документами. Підтримка PDF давно існує, а окремої переваги цього формату для SEO Google не оголосив.
PDF може потрапити до звичайної видачі, AI Overviews і AI Mode. Та якщо ви часто змінюєте ціни, умови послуг або текст статті, HTML зазвичай простіше підтримувати й зручніше читати з телефона.
Що Google бачить усередині PDF
PDF — це контейнер для тексту, зображень, посилань та інших елементів. Візуально дві сторінки можуть виглядати однаково, але бути зовсім різними для обробки: одна містить текст, інша — лише фотографію надрукованого аркуша.
Під час індексації спеціальний конвертер створює HTML-представлення вмісту. Текстові посилання можуть зберігатися в ньому, тож Google здатний їх виявляти й обробляти. Корисно додати на початку документа зрозуміле посилання на ваш сайт або сторінку з актуальною версією файла. Воно допоможе читачеві повернутися до джерела, навіть якщо PDF хтось скопіює.
Із зображеннями все менш однозначно. Вбудована ілюстрація не має окремої вебадреси, яку можна передати звичайному конвеєру Google Images. Сплітт прямо зазначив, що не знає всіх деталей цієї обробки. Тому не варто розраховувати, що кожен малюнок усередині PDF з’явиться в пошуку зображень. Важливі ілюстрації краще також розмістити на доступній HTML-сторінці.
Чи можуть PDF з’являтися в AI Overviews та AI Mode
Так. Представники Google пояснили, що після конвертації початковий формат документа не виключає його з цих пошукових функцій. Але можливість використання PDF як джерела не означає, що Google обов’язково процитує саме ваш файл.
За офіційними вимогами до AI-функцій пошуку, матеріал має бути проіндексований і придатний для показу зі сніпетом у Google Search. Спеціального формату чи окремої розмітки для потрапляння в AI Overviews або AI Mode не потрібно.
Також не слід ототожнювати посилання в AI-відповіді з навчанням моделі. У подкасті Мюллер припускає, що різні AI-системи зацікавлені у PDF як джерелах. Це не підтвердження, що кожен проіндексований документ використовується для навчання Gemini.
Який ліміт розміру PDF для Googlebot
У розмові ведучі не назвали точного порога. Водночас документація Googlebot містить конкретні значення:
| Тип файла | Ліміт завантаження для Google Search |
|---|---|
| Перші 64 МБ | |
| HTML та інші підтримувані типи, крім PDF | Перші 2 МБ |
Ліміт застосовується до нестиснених даних. Після досягнення порога Googlebot припиняє завантаження й передає отриману частину на подальшу обробку. Для інших роботів Google можуть діяти інші обмеження.
Це межа завантаження, а не обіцянка проіндексувати весь текст документа на 64 МБ. З неї також не можна вивести точний ліміт внутрішнього HTML після конвертації. Якщо файл великий, варто прибрати зайві важкі зображення й перевірити, чи справді читачеві потрібен один величезний документ.
Як перевірити текстовий шар і доступність
Найпростіша перевірка займає хвилину:
- Відкрийте PDF у браузері або програмі для читання документів.
- Виділіть кілька абзаців на різних сторінках і скопіюйте їх.
- Вставте текст у звичайний текстовий редактор.
- Перевірте, чи збереглися слова та порядок читання, особливо в таблицях і колонках.
Якщо текст не копіюється, файл може складатися зі сканів або растрових сторінок. Це сигнал перевірити спосіб експорту й наявність текстового шару. Деякі системи застосовують OCR — розпізнавання тексту на зображеннях, але покладатися лише на нього представники Google не радять.
Для сканованого документа варто додати текстовий шар через OCR і перевірити результат вручну. Для нового матеріалу краще експортувати PDF з вихідного документа зі збереженням тексту, а не перетворювати сторінки на картинки.
Копіювання тексту не доводить повної доступності файла. Окремо перевірте структуру заголовків, порядок читання й роботу з програмою екранного читання. Скан без доступного тексту створює труднощі і для пошукової обробки, і для людей, які користуються допоміжними технологіями.
Ще одна перевірка — телефон. Чи можна прочитати документ без постійного масштабування й горизонтального прокручування? Фіксована друкована верстка зручна на папері, але часто погано пристосована до малого екрана. Захищений паролем PDF також не підходить для відкритої індексації: Google не зможе прочитати його вміст.
Що робити, якщо є і PDF, і HTML-версія
Публікувати обидва формати можна. Наприклад, інструкція читається на сайті, а PDF потрібен для завантаження або друку. Проте варто визначити, яку версію ви хочете бачити основною в пошуку, і узгодити посилання та технічні сигнали.
Для PDF canonical передається через HTTP-заголовок Link у відповіді сервера. HTML-тег із <head> усередину PDF вставити не вийде. Якщо PDF суттєво повторює HTML-інструкцію, приклад заголовка для відповіді з PDF може виглядати так:
Link: <https://example.com/instruction/>; rel="canonical"Це умовна адреса. Замість неї потрібно вказати абсолютний URL вашої доступної HTML-версії з відповідним вмістом. Заголовок налаштовується на сервері й має повертатися саме під час запиту PDF. Метод описаний у документації Google про canonical.
Canonical є сигналом вибору основної версії. Він не гарантує рішення Google й не забороняє іншим сайтам копіювати файл. Коли однаковий PDF розміщений на кількох доменах, сам вміст не допомагає відрізнити оригінал від копії. Автор, опис, дата версії та посилання на джерело корисні для розуміння документа, але теж не дають гарантії вибору вашого URL.
Якщо завантажуваний файл узагалі не має з’являтися у видачі, це окрема задача. Для неї можна передати X-Robots-Tag: noindex у HTTP-відповіді з PDF. За правилами Google, робот має мати доступ до файла, щоб прочитати цю директиву. Блокування в robots.txt саме по собі не гарантує зникнення URL із пошуку.
Чому змінений PDF може залишатися старим у пошуку
Мюллер пояснив, що Google зазвичай сприймає PDF як відносно статичний файл і може повторно завантажувати його рідше за HTML-сторінку. Точний графік для конкретного документа він не назвав. Перезаписування файла на сервері не означає негайного оновлення його пошукової версії.
У подкасті прозвучала можливість дати суттєво оновленому документу нове ім’я файла й нову адресу. Тоді Google може виявити його як новий URL. Але це не гарантує швидкої індексації й не означає, що назву потрібно змінювати після кожної правки.
Для каталогу з окремими випусками новий URL може бути доречним: читачеві зрозуміло, де актуальна версія, а де архів. Для постійно змінюваного прайсу зручніше зробити основну інформацію в HTML, а PDF залишити додатковою версією для завантаження.
Після оновлення перевірте дату документа, посилання на нього із сайту та налаштування кешування. Якщо адреса змінилася, оновіть внутрішні посилання й вирішіть, чи потрібна стара версія в архіві. Загальні орієнтири щодо сканування та індексації Google теж слід читати як діапазони, а не як обіцянку конкретного строку.
Обережно й з автоматичною PDF-копією кожної сторінки в CMS. HTML уже може містити нові дані, а PDF у пошуку — ще старі. Особливо це незручно для цін, умов послуг і матеріалів, які змінюються часто.
Коли PDF доречний, а коли зручніший HTML
| Завдання | Практичний вибір |
|---|---|
| Звіт, бланк або документ із фіксованим оформленням для друку | PDF доречний; збережіть доступний текст і зрозумілу версію |
| Стаття, опис послуги, ціни, які регулярно змінюються | HTML простіше оновлювати й пристосувати до телефона |
| Інструкція для читання на сайті й завантаження | HTML та PDF із узгодженим вмістом і визначеною основною версією |
| Меню закладу, для якого поки немає вебсторінки | Доступний PDF краще за відсутність меню; HTML можна додати згодом |
Формат варто обирати під задачу читача. Якщо людині треба швидко перевірити ціну з телефона, адаптивна сторінка зазвичай зручніша. Якщо треба роздрукувати бланк із точним розташуванням полів, PDF має зрозумілу перевагу.
Коротка перевірка PDF перед публікацією
- Текст виділяється, копіюється й читається в правильному порядку.
- Документ відкривається без пароля; файл доступний за прямим URL.
- Є зрозуміла назва, автор або організація, дата версії та посилання на сайт.
- Файл не перевантажений зображеннями й придатний для читання на телефоні.
- Якщо є HTML-дубль, визначена основна версія й перевірено потрібний HTTP-заголовок.
- Після зміни документа оновлено посилання, дату й перевірено актуальність версії.
Для швидкого перегляду документів у видачі можна використати запит site:example.com filetype:pdf, замінивши домен на свій. Докладніше про таку комбінацію — у матеріалі про пошукові оператори для перевірки документів. Водночас відсутність файла за цим запитом не доводить, що його немає в індексі: для діагностики конкретного URL Google рекомендує інструмент перевірки URL у Search Console.
Поширені запитання про індексацію PDF у Google
Чи має PDF перевагу перед HTML у ранжуванні?
Окремого бонусу за PDF Google не заявляє. Документ може ранжуватися, якщо пошуковик отримав і зрозумів його вміст, але сам формат не гарантує позицій.
Чи варто переводити статті в PDF заради AI Overviews?
Ні, для цього немає підтверджених підстав. І PDF, і HTML можуть бути джерелами для AI-пошуку. Для регулярно оновлюваної статті HTML зазвичай практичніший.
Чи достатньо додати canonical, щоб Google обрав мій оригінал?
Це сильний сигнал, але не гарантія. Для PDF використовується HTTP-заголовок, а узгоджені посилання й доступна основна версія допомагають уникнути суперечливих сигналів.
Чи потрібно перейменовувати PDF після кожного оновлення?
Ні. Новий URL може бути доречним для окремої версії документа, але створює додаткову роботу з посиланнями й архівом. Для частих змін краще розглянути HTML-сторінку з актуальними даними.