Як я використовую графи знань на контентних сайтах
Щоб використовувати граф знань для SEO на контентному сайті, потрібні три речі: закритий словник людей, компаній і концепцій, про які ви пишете, тег сутності на кожній сторінці і автоматично зібрана хаб-сторінка під кожну сутність. Разом вони перетворюють пости, що втрачають трафік за лічені дні, на сторінки, які набирають вагу роками. І заодно дають сайту довіру, яку машини можуть перевірити. Я так працюю на власних проєктах: граф SEO-спільноти на SEO Baza, сторінки сутностей тут, на Fajela, ентерпрайз-клієнти. Найгучніший публічний приклад — The New York Times: у них ця система крутиться на 1,8 мільйона статей ще з часів, коли Google не існувало. Далі розповідаю детальніше + покроково, як все зробити правильно і де я помилялась.
Як The New York Times тримає контент на графі сутностей
The New York Times тегує кожен матеріал за контрольованим словником з 1851 року, коли бібліотекарі вели його як паперовий індекс. Сьогодні архів налічує понад 1,8 мільйона статей, з яких понад 1,5 мільйона протеговані вручну термінами із закритого списку рівно пʼяти типів: люди, організації, локації, теми і твори. Конвеєр, описаний NYT для IPTC, ділить роботу так: софт пропонує теги з оцінкою релевантності, редактор підтверджує, а окрема команда таксономістів щодня розглядає запити на нові терміни і пише правила дизамбігуації, щоб композитора John Adams ніколи не переплутали з президентом John Adams.
У своєму аналізі тематичних сторінок NYT SEO-консультант Chris Long нараховує майже 10 000 таких сторінок, і всі вони зібрані з цих тегів. Лише тематична сторінка про Facebook, за його оцінкою, приносить близько 1,1 мільйона візитів на місяць. Це зовнішні оцінки, а не звітність самих NYT, але вони показують, скільки трафіку може тримати хаб, зібраний з тегів: стаття помирає, хаб зберігає трафік. Усе, що нижче, — та сама машина, зменшена до розміру сайту, який можемо запустити ми з вами.
Чому робота з графом знань будує довіру
Відповідь дають дослідження Google. Команда Xin Luna Dong побудувала Knowledge Vault, величезну базу фактів, витягнутих з вебсторінок, кожен зі своєю оцінкою ймовірності, а поверх неї Knowledge-Based Trust, спосіб оцінювати джерело за точністю його фактів, а не за посиланнями. Як це працює, Dong розповідає у стенфордському семінарі: система витягує факти зі сторінок і звіряє їх з рештою бази знань. В експериментах деякі таблоїдні сайти з горою беклінків провалили перевірку фактів, а малі акуратні сайти опинилися серед найточніших. Це дослідження, а не опис чинного алгоритму пошуку.
Як це працює в нашу AI-еру? Пізніша робота Dong уже в Meta, бенчмарк Head-to-Tail, перевірила, скільки фактів мовні моделі насправді памʼятають: ChatGPT правильно відповів на 29,4% питань про відомі (head) сутності, на 21,9% про середньопопулярні і на 9,5% про хвостові (tail). Майже кожен експерт, інструмент чи компанія, про яких пише нішевий сайт, живе саме в цьому хвості, а отже моделі цих фактів не знають і мусять їх звідкись діставати. Сайт із чистим шаром сутностей і стає тим місцем, звідки їх беруть. Українські SEO-спеціалісти з графа, який я веду на SEO Baza, — якраз такі сутності: жодна модель не бачила їх у навчальних даних, тож структуровані профілі стають тим джерелом, з якого AI-пошук бере відповідь.
Доступ до пошуку теж не рятує моделі повністю. Команда Dong далі побудувала CRAG, бенчмарк, де системи відповідають на питання, маючи під рукою імітований веб-пошук і API графів знань. Навіть так прості RAG-рішення дали точні відповіді менш ніж на 44% питань, а найкращі індустріальні системи відповіли без галюцинацій лише приблизно на 63%. Саме тому пошукові движки спираються на графи знань поруч із результатами пошуку, а не обирають щось одне, і саме тому структуровані факти, які публікує сайт, годують обидва канали одночасно.
Висновок для контентного проєкту
Машина може перевірити лише те, що вміє витягти, тож однозначні назви, стабільні синоніми, розмітка і спільні ідентифікатори роблять ваш сайт взагалі придатним до перевірки. Кожен крок нижче або допомагає машинам витягати ваші факти, або захищає ці факти від помилок. Я бачу це у звітності Fajela: відстежую, як часто мої проєкти зʼявляються в AI-відповідях, зіставляючи дані Gemini з запитами в Search Console, і на поверхню виходять саме сторінки з чистими сутностями.
Крок 1: складіть словник, на якому стоятиме граф знань
Починайте словник з найкращого контенту: випишіть кожну сутність, варту окремої сторінки, з типом, канонічною назвою, описом на два речення і синонімами. Контентному сайту вистачає пʼяти-шести типів: людина, організація, інструмент, концепція, подія.
Починайте з малого. Граф знань Fajela обмежений галуззю, про яку я пишу: зараз це 52 експерти з SEO і digital-маркетингу плюс 38 компаній та інструментів, кожен зі своєю сторінкою на fajela.com. А коли хочу швидко випробувати дизайн графа, я розкладаю в граф одну подію: так я зробила з конференцією SEO Vibes 2026, перетворивши її на граф спікерів, доповідей, треків і тем. Однієї події вистачає, щоб ухвалити всі ключові рішення: що вважається сутністю, які типи ребер (SPEAKS_AT, WORKS_AT, COVERS_TOPIC) і що мусить містити запис.
Для сутностей-людей я тримаю фіксований набір полів: імʼя, поточна роль, організація, коротке біо на 80-150 слів, спеціалізації, помітні роботи, посилання sameAs на профілі, а також ідентифікатори Wikidata і Google Knowledge Graph, де вони існують. Вкладіться в синоніми по-справжньому: кожне написання, прізвисько, транслітерація, а українською ще й відмінкові форми, інакше половина згадок залишиться непоміченою.
Крок 2: тегуйте кожну сторінку і стережіть список сутностей
Тегування сутностей працює, лише поки воно жорстко обмежене. Автори обирають зі словника, а додавання нової сутності означає редакційне рішення і оновлення списку. У WordPress це кастомна таксономія, на статичному сайті службове поле на початку файлу, і в обох випадках процес публікації має відхиляти тег, якого немає в словнику.
Ця дисципліна і відрізняє граф знань від звичайних теґів CMS: словник закритий, сутності типізовані й описані, синоніми записані, а хаби живуть як повноцінні сторінки. Без неї теги залишаються теками.
Тут варто розплутати одне: граф знань і графова база даних — це різні речі. Граф і є саме знання: ваші сутності, їхні описи і звʼязки між ними та вашими сторінками. Графова база на кшталт Neo4j — лише одне з можливих сховищ, збудоване під запити до мільйонів вузлів. На контентному сайті сотні сутностей і тисячі сторінок, на такому розмірі той самий граф спокійно живе в таксономії WordPress чи папці структурованих файлів. Пошуковики вашого сховища все одно не бачать. Вони бачать опубліковані сторінки, розмітку і посилання між ними, а ті виглядають однаково незалежно від того, що за ними стоїть. Я тримаю копію графа Fajela в Neo4j для аналізу, рахую спільні появи і шукаю людей, які єднають спільноти, але сам fajela.com працює на звичайному WordPress.
Я точно знаю, що буває без запобіжників, бо в квітні проводила аудит самого fajela.com і знайшла наслідки: той самий SEO-експерт опублікований під двома різними слагами, а мій хаб сутностей посилається на мертву структуру URL, покинуту посеред міграції. Одразу нічого не сталося. У цьому й пастка: шкоди не видно, а тим часом кожен дублікат розполовинює ранжування, внутрішні посилання і блоки повʼязаних матеріалів. NYT запобігає цьому цілим відділом таксономії. Малому сайту той самий захист дають валідаційний скрипт і одне правило іменування, якщо вони спрацьовують на кожній публікації.
Крок 3: публікуйте хаби сутностей, які заробляють своє ранжування
Саме на хаб-сторінках граф починає окуповуватися в пошуку. На сторінках сутностей Fajela кожен профіль має обовʼязкові секції: хто ця людина і її поточна роль, чим відома, помітні роботи, виступи чи відео, і блок перевірених посилань на профілі, зібраний із sameAs. Фіксована структура потрібна, щоб жоден хаб не вийшов тонким списком посилань, бо автозгенерований список посилань для сучасних систем якості виглядає дорвеєм.
Два правила, які пропускає більшість туторіалів:
- Викочуйте хаби поступово. Цього я навчилася дорогою ціною. У квітні 2026 я виклала першу партію з приблизно сорока сторінок сутностей за один вечір, а за два тижні докинула ще тридцять за один раз. Нові сторінки на кілька місяців осіли в Crawled, currently not indexed (просканована, але не проіндексована), а сторінки, які вже ранжувалися, за той самий період просіли. Я свідомо нічого не виправляла, просто спостерігала. І могла собі це дозволити: Fajela — мій полігон, тут я спершу тестую все на собі, навіть те, що майже напевно зашкодить. На робочому сайті клієнта чи на сайті, з якого живе бізнес, таких експериментів робити не можна. Тепер викладаю хаби по кілька за раз, тільки повністю готові, і розділ росте поступово, разом з реальним контентом.
- Наповнюйте хаби значенням і цифрами. Цитують і лінкують ті тексти хабів, які пояснюють, що означає звʼязок (хто де виступав, хто з ким працював), і показують статистику по всьому графу.
У підсумку хаби ранжуються за запитами про сутності (імена, бренди, концепції), які окремі статті ніколи не втримують, і кожен хаб працює як посадкова сторінка, яку не довелося писати з нуля. І ще! Це фактологічно коректно і викликає довіру.
Крок 4: вплетіть граф у внутрішню перелінковку
Внутрішні посилання беруться просто з тегів. Хаби посилаються на кожну протеговану статтю, статті посилаються на свої хаби, а блоки повʼязаних матеріалів зʼєднують тексти зі спільними сутностями. Це архітектура hub-and-spoke: хаб у центрі, статті довкола, і все згенеровано з метаданих. Кожен новий пост автоматично підсилює хаби, яких торкається, а старі пости продовжують отримувати свіжі посилання, поки їхні сутності лишаються в новинах. Анкорний текст виходить сам собою: це канонічна назва сутності.
Крок 5: розмітьте сутності і приєднайтеся до публічного графа знань
Розмітка робить ваш внутрішній граф зрозумілим для систем Google і для LLM. Кожен хаб несе структуровані дані свого типу (Person, Organization, DefinedTerm) з посиланнями sameAs на Wikipedia, Wikidata і справжні профілі сутності. Статті згадують сутності через властивості about і mentions. Один синтаксис на сторінку: на SEO Baza я зупинилася на мікроданих для всього сайту, на Fajela блог працює на JSON-LD. На fajela.com маленький кастомний плагін, який я зробила, тягне дані сутностей просто з Wikidata, тож описи й ідентифікатори тримаються публічного графа.
Зовнішні ідентифікатори важать більше, ніж здається. NYT зрозуміли це ще 2009 року, коли почали викладати свої предметні рубрики як звʼязані відкриті дані, з часом близько 10 000 тегів, з привʼязкою до Freebase, DBpedia і GeoNames. Сьогодні цю роль грає Wikidata, і я відстежую ідентифікатори Google Knowledge Graph (KGMID) для сутностей у своїх графах з тієї самої причини: спільний ідентифікатор дозволяє машині зрозуміти, що ця сторінка, та панель і той запис Wikidata — це одна й та сама річ. Персональний зріз цієї теми я розібрала в матеріалі про SEO авторського профілю.
Крок 6: тримайте факти про світ поза графом
Граф NYT стверджує факти лише одного ґатунку: ми опублікували цю статтю, і вона про цю сутність. Такий факт має ідеальне походження і не застаріває ніколи. Щойно ваш граф починає стверджувати факти про світ, кожне ребро потребує джерела, дати і циклу перегляду, бо світ рухається далі, а збережені записи ні.
Ціну цього правила я знаю з iGaming-проєкту з базою даних: із 45 збережених тверджень про те, які методи оплати підтримують сайти в графі, ручну перевірку пережили лише 27. Інші 18 застаріли, а граф продовжував віддавати їх як факти. Саме за це карає оцінювання за фактами: джерело впевнено віддає твердження, які більше не підтверджуються. Відтоді кожен фактологічний запис у мене несе джерело і дату перевірки, а все неперевірене не потрапляє на опубліковані сторінки. Для контентного сайту дешевше працює структурне правило: ціни, функції і доступність живуть у тексті, де в них є автор і дата, а граф лишається для ребер між контентом і сутностями, які не протухають.
Мінімальна життєздатна версія всього цього: словник розміром з табличку, одна таксономія і кілька завершених хаб-сторінок, викочених поступово. Це тиждень роботи, і працювати на вас вона починає з дня запуску. А якщо хочете таку систему без власних проб і помилок, можемо поспілкуватись.
