Оптимізація сайту давно вийшла за межі HTML

Аналітичне есе для досвідчених SEO-фахівців і технічних маркетологів

Почну з головного. HTML був і залишається фундаментом пошукової оптимізації: саме HTML-сторінка є основною одиницею індексації, ранжування та взаємодії користувача із сайтом. Але сучасний вебсайт давно перестав бути просто набором HTML-сторінок. Сьогодні він складається з десятків типів інформаційних активів: PDF-документів, зображень, відео, Markdown-файлів, JSON-LD, XML-карт сайту, RSS-стрічок та інших форматів.

Кожен із них виконує свою роль. Одні створені насамперед для людей, інші — для пошукових роботів, треті допомагають AI-системам краще розуміти зміст і зв’язки між даними. Є й такі, що взагалі не публікуються безпосередньо, але визначають якість усього контенту, який потрапляє на сайт.

Мені здається, що звичка сприймати вебсайт виключно як сукупність HTML-сторінок стала майже непомітним обмеженням для нашої професії. Запитання «як оптимізувати HTML?» і досі залишається важливим, але вже не є головним. Набагато точніше запитати: як оптимізувати всю інформаційну архітектуру вебсайту?

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

Ця стаття — спроба розібратися, чому саме так.

Чому ми досі мислимо лише HTML-сторінками

Класичне SEO сформувалося навколо HTML — і це було цілком логічно. Двадцять років тому вебсайт справді був набором HTML-сторінок: краулер переходив за посиланнями, аналізував розмітку, витягував текст, а весь арсенал SEO-фахівця — від метатегів до внутрішньої перелінковки — існував у межах одного формату.

Згодом ця модель закріпилася не лише в нашому мисленні, а й в інфраструктурі. Інструменти для технічного аудиту рахують сторінки. Звіти Google Search Console групуються за URL. KPI формулюються через «кількість сторінок в індексі» та «позиції сторінок». Навіть професійна термінологія залишається сторінкоцентричною: ми говоримо «посадкова сторінка», «сторінка послуги», «сторінка блогу». Інструменти формують наше мислення значно сильніше, ніж ми зазвичай готові це визнавати.

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

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

Що насправді являє собою сучасний вебсайт

Якщо подивитися на сучасний вебсайт не очима SEO-фахівця, а, скажімо, архітектора даних, картина виглядатиме зовсім інакше. Типовий корпоративний вебсайт сьогодні складається не лише з HTML-сторінок. Він містить PDF-документи (прайси, інструкції, звіти, white paper), тисячі зображень, відео, JSON-LD-розмітку, XML-карти сайту, robots.txt, RSS- або Atom-стрічки, API-відповіді, а дедалі частіше — ще й Markdown-файли, з яких і генерується HTML.

Я б сформулював це так: вебсайт — це інформаційна екосистема, а не просто сукупність сторінок.

У такій екосистемі кожен елемент виконує власну функцію. HTML створений насамперед для людей і залишається основною «валютою» пошуку. XML Sitemap і robots.txt існують для пошукових роботів та керують виявленням контенту. JSON-LD допомагає машинам правильно інтерпретувати інформацію. Markdown є вихідним шаром, із якого формується HTML. PDF-документи та відео — це окремі інформаційні активи зі своїми особливостями індексації та поширення.

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

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

Які формати справді беруть участь у SEO

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

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

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

Зображення беруть участь не лише в пошуку за зображеннями, а й дедалі більше — у візуальному та мультимодальному пошуку. Для них важливі alt-атрибути, зрозумілі назви файлів, контекст сторінки, формат, швидкість завантаження та наявність у image sitemap. Я б не переоцінював жоден із цих чинників окремо, але разом вони визначають, чи існує зображення для пошукових систем узагалі.

Відео — це окремий пошуковий актив. Воно має власні результати пошуку, спеціальну розмітку (VideoObject) і власні вимоги до виявлення. Транскрипт перетворює відео з «чорної скриньки» на текст, доступний і пошуковим системам, і AI-моделям. На мою думку, це одна з найбільш недооцінених можливостей відеооптимізації.

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

JSON-LD не додає жодного нового слова до контенту, але допомагає машинам правильно інтерпретувати те, що вже опубліковано: де товар, де його ціна, хто автор, яка організація стоїть за сайтом. Розширені сніпети — найпомітніший результат використання структурованих даних. Проте, як на мене, їхня справжня довгострокова цінність полягає в іншому: вони зменшують неоднозначність для будь-яких машинних систем, які працюють із вебконтентом — не лише для пошукових систем, а й для AI.

Чому Markdown майже невидимий для пошукових систем, але водночас надзвичайно важливий

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

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

Із цього випливає важливий практичний висновок: якщо контент створюється в Markdown, то й його оптимізація фактично починається саме там.

Структура H2—H3, повнота метаданих, alt-тексти зображень, внутрішні посилання — усе це визначається у вихідному файлі. Шаблон генератора лише вирішує, як ця інформація буде перетворена на HTML. Помилка в шаблоні може автоматично поширитися на тисячі сторінок, а неправильний frontmatter — зламати метадані цілого розділу вебсайту.

Я б назвав це оптимізацією на рівні джерела. Працювати з вихідними файлами значно ефективніше, ніж виправляти вже згенерований HTML.

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

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

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

Чому PDF можуть бути самостійними пошуковими активами

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

Насправді ж PDF має цілком конкретний перелік технічних вимог.

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

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

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

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

Є й інша проблема — дублювання контенту.

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

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

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

Які формати майже не беруть участі в пошуку

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

TXT, DOCX, XLSX та PPTX технічно можуть індексуватися — пошукові системи здатні витягувати з них текст. Проте на практиці вони дуже рідко стають повноцінними пошуковими активами, і цьому є кілька системних причин.

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

І найважливіше: у більшості випадків це не контент, спеціально створений для публікації, а робочі документи, які випадково опинилися у відкритому доступі.

Практичний висновок доволі простий.

Такі файли зазвичай варто або перетворити на повноцінний вебконтент — HTML-сторінки чи якісно підготовлені PDF-документи, — або свідомо закрити від індексації. Найгірший варіант — залишити їх на сервері й дозволити пошуковим системам індексувати їх без жодного контролю. Такий підхід створює контент, який існує без стратегії та без відповідального за нього власника.

Водночас важливо зробити одне уточнення.

Те, що формат майже не бере участі в пошуку, зовсім не означає, що він не має цінності.

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

Чому JSON-LD та XML не варто вважати контентом

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

JSON-LD, XML Sitemap, robots.txt і RSS — це не контент. Це опис контенту та інструкції щодо роботи з ним.

JSON-LD повідомляє машині: «це товар», «ось його ціна», «ось виробник». XML Sitemap говорить: «ось URL-адреси, які варто обійти, і ось коли вони востаннє оновлювалися». Robots.txt повідомляє: «цей розділ не потрібно сканувати».

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

Із цього випливають два важливі практичні правила.

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

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

Мені подобається дивитися на вебсайт як на систему з двох взаємопов’язаних шарів.

Перший — контентний шар, який містить інформацію та створює цінність для користувача.

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

Оптимізація — це, зокрема, підтримання узгодженості між цими двома шарами. Коли XML Sitemap містить посилання на сторінки, яких уже не існує, або структуровані дані описують товари, що давно відсутні в продажу, інформаційна екосистема починає суперечити сама собі. Саме такі суперечності дедалі краще помічають як пошукові системи, так і AI-моделі.

Як AI змінює наше уявлення про формати

Тут я хочу бути особливо обережним у формулюваннях. Ця сфера ще дуже молода, а спокуса видати власні спостереження за універсальні закономірності — надто велика.

Що можна сказати з достатньою впевненістю? AI-системи — зокрема краулери LLM-провайдерів, пошукові асистенти та RAG-пайплайни — споживають інформацію з різних форматів, а не лише з HTML.

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

Далі починається зона спостережень, а не доведених фактів.

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

Я не став би стверджувати, що AI-системи «віддають перевагу» певним форматам — переконливих доказів цього поки що немає. Значно обережніше буде припустити інше: що легше інформацію витягнути, то вища ймовірність, що вона буде правильно зрозуміла та використана. Принаймні тому, що системі, якій не потрібно самостійно здогадуватися про структуру даних, значно складніше помилитися.

Хороший приклад — транскрипти.

Відео без транскрипту для мовної моделі майже не існує. Варто додати транскрипт — і те саме відео перетворюється на повноцінний текстовий документ, доступний для аналізу. Одна, здавалося б, проста зміна переводить інформаційний актив із категорії «майже невидимий» до категорії «повністю доступний для машин».

Для себе я формулюю цей зсув так:

Класичні пошукові системи насамперед оцінювали сторінки.

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

Якщо це припущення правильне, то витягуваність інформації (extractability) стає важливою характеристикою кожного інформаційного активу, а не лише HTML-сторінок.

Чому оптимізувати потрібно не сторінки, а інформаційні активи

Тепер можна зібрати головну ідею докупи.

Якщо вебсайт — це екосистема інформаційних активів, то основною одиницею оптимізації стає не сторінка, а інформаційний актив.

Незалежно від того, чи йдеться про HTML-сторінку, PDF-документ, відео або зображення, кожен актив має однаковий набір ключових характеристик:

• зміст — яку інформацію він містить;
• метадані — як він описаний для машин;
• витягуваність (extractability) — наскільки легко машина може отримати з нього потрібну інформацію;
• зв’язність — як він пов’язаний з іншими активами;
• керованість — чи знає взагалі хтось у компанії про його існування та чи відповідає за нього.

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

Запитання «на якій позиції знаходиться наша сторінка?» вже недостатньо. До нього додаються інші:

• Чи вся наша інформація існує у форматах, які можна легко обробити?
• Чи не приховані важливі знання у форматах, недоступних ані пошуковим системам, ані AI?
• Чи узгоджені між собою контентний і службовий шари вебсайту?

Я розумію, що це звучить як розширення зони відповідальності SEO-фахівця — і певною мірою так воно і є.

Але, на мою думку, це чесніше, ніж робити вигляд, що все, що знаходиться за межами HTML, «не стосується SEO».

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

І ще одне важливе уточнення.

Усе сказане — це спосіб мислення, а не перелік факторів ранжування.

Жодна з описаних характеристик сама по собі не гарантує високих позицій у пошуку. Проте їх ігнорування майже напевно призводить до появи «сліпих зон» — інформаційних активів, які залишаються поза увагою як пошукових систем, так і людей, відповідальних за розвиток вебсайту.

Як би я побудував сучасний аудит вебсайту

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

Перший етап — інвентаризація.

Не аудит HTML-сторінок, а повна інвентаризація всіх активів. Це означає повний краулінг вебсайту без фільтрації за типами файлів, аналіз логів сервера та перевірку даних про вже проіндексовані ресурси. Мета — побудувати карту інформаційної екосистеми: скільки на вебсайті PDF-документів, зображень, відео, стрічок та інших активів, і які з них уже відомі пошуковим системам.

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

Наступний етап — пошаровий аналіз.

HTML перевіряється за класичними принципами SEO — тут нічого принципово нового немає.

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

Зображення перевіряються на наявність alt-атрибутів, зрозумілих назв файлів, сучасних форматів і включення до image sitemap.

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

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

Службовий шар — XML Sitemap, robots.txt і RSS — аналізується як єдина система: чи не суперечать його елементи один одному та реальному стану вебсайту.

Окремий етап, який я почав додавати порівняно нещодавно, — це аналіз вихідних матеріалів та внутрішньої документації.

Якщо вебсайт будується з Markdown-файлів, аудит вихідного шару — структури, frontmatter і шаблонів генератора — нерідко дає більше цінної інформації, ніж аналіз уже згенерованого HTML.

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

Останній етап — ухвалення рішень щодо кожного класу інформаційних активів.

Які з них варто розвивати як повноцінні пошукові активи?

Які краще перевести в інший формат?

Які потрібно закрити від індексації?

А які взагалі доцільно видалити?

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

Замість висновку

Повернуся до думки, з якої почав.

HTML залишається фундаментом пошукової оптимізації, і навряд чи це зміниться найближчим часом. Але фундамент — це ще не вся конструкція.

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

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

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

Але мені здається, що перевагу отримають не ті, хто вгадає «правильний» формат, а ті, хто наведе лад у всій своїй інформаційній екосистемі. Просто тому, що впорядкованість підвищує витягуваність інформації (extractability), а саме вона, схоже, поступово стає новою валютою цифрової видимості.

Можливо, наступний етап розвитку SEO полягає вже не в оптимізації окремих сторінок, а в усвідомленому управлінні всією інформаційною екосистемою вебсайту.