Уроки SEO з виправлення власного сайту
Кілька днів ми читали власний сайт так, як його читає пошукова система, і знайшли шість речей, які варто виправити. Кожна сторінка оголошувала два блоки FAQ, Google використовував як мініатюру декоративне фонове сяйво, низка шаблонних сторінок ранжувалася за пошуками, на які вони не відповідали, а новий розділ сайту на тестовому середовищі блокувався нашим власним краєм. Нічого драматичного, але все це непомітно коштувало нам видимості.
Сайт в одному абзаці
mythex.ai це односторінковий застосунок, який ми попередньо рендеримо під час збирання. Скрипт обходить кожен маршрут, записує для нього статичний HTML-файл і вбудовує назву сторінки, опис та структуровані дані (блок JSON-LD, який повідомляє пошуковим системам, що саме це за сторінка; див. що таке структуровані дані). Більшість того, що йде далі, стосується кроку попереднього рендерингу, бо саме цей HTML читає краулер.
1. Кожна сторінка претендувала на роль сторінки FAQ
Симптом. Наш HTML-шаблон містив загальносайтовий блок FAQPage у структурованих даних, з URL, що вказував на /faq. Попередній рендеринг потім додавав власний FAQPage кожної сторінки поверх. Тож кожна сторінка на сайті містила два блоки, а наша політика конфіденційності повідомляла Google, що вона є сторінкою FAQ.
Чому це важливо. Google очікує не більше одного FAQPage на сторінку. Другий, що вказує на інше місце, є тим, через що розмітка сторінки знецінюється, а не просто ігнорується.
Виправлення. Загальносайтовий блок прибрано. Розмітка FAQ кожної сторінки тепер формується в одному місці, включно зі самою сторінкою /faq, яка будує її з повного списку питань. Сторінки без FAQ тепер не оголошують жодного, і це чесна відповідь. Крім того, попередній рендеринг завершується помилкою, якщо будь-яка сторінка знову матиме більше одного FAQPage. Правило, яке існує лише в чиїйсь пам'яті, порушується; правило, яке забезпечує збірка, ні.
2. Google використовував не ту картинку
Симптом. У результатах пошуку мініатюрою Mythex було м'яке пульсуюче сяйво за головним героєм домашньої сторінки, тобто декоративне фонове зображення, а не наша картка для публікації в соцмережах.
Чому так сталося. Ми ніколи не казали Google, яке зображення представляє сторінку, тож він вибрав те, яке знайшов.
Виправлення. Дві сторони однієї проблеми:
- Вкажіть, яке зображення належить сторінці. Домашня сторінка тепер має вузол
WebPageзprimaryImageOfPage, що вказує на картку для публікації, а структуровані дані кожної попередньо відрендереної сторінки містять власне зображення (картку цієї сторінки або типове). - Приховайте оформлення. Фонові зображення тепер заборонені в
robots.txtі віддаються із заголовкомnoindex, noimageindex, тож вони не потрапляють до пошуку зображень і мініатюр.
3. Пошукові системи знали лише наш логотип
Розмітка Organization мала назву, логотип і деякі посилання на соцмережі, тобто лише брендинг. Пошукові системи будують панель знань компанії з реєстрових фактів, тож ми додали ті, що є в нашій торговельній ліцензії: юридичну назву, дату заснування, засновника та юридичну адресу. Номер телефону ми свідомо не вказали.
4. Шаблонні сторінки відповідали на інше питання
Симптом. Search Console показувала, що три шаблонні сторінки отримують покази, але не кліки. Одна ранжувалася за запитом «content strategist portfolio» та його варіантами, інша за «best italian restaurant website design», ще одна за групу навколо «agile board». Половина цих пошуків містила слово «free». Позиції були від середини двадцятих до п'ятдесятих.
Чому. Кожна сторінка відповідала на питання, відмінне від поставленого. Той, хто хотів побачити, як виглядає хороший дизайн італійського ресторану, потрапляв на сторінку, що продавала конструктор.
Виправлення. Кожна з трьох сторінок тепер має розділ, написаний для пошукового запиту, а не для продукту, заголовок і опис словами, якими люди насправді шукають, а також FAQ, вартий тієї розмітки, яку вони вже виводили.
Той самий коміт виправив тиху проблему. Блок «пов'язані шаблони» брав перші чотири шаблони в категорії, тож кожен шаблон портфоліо вказував на ті самі чотири портфоліо, а решта категорії взагалі не мала внутрішніх посилань. Ми замінили його кільцем, впорядкованим за підкатегорією: тепер кожна сторінка шаблону має рівно чотири вхідних і чотири вихідних посилання. Попередньо відрендерений HTML тепер також виводить ці посилання. Раніше вони існували лише після виконання JavaScript, що краулер може ніколи не зробити.
5. Повідомляти Bing про нові сторінки одразу після розгортання
Google ігнорує IndexNow, протокол, що пінгує пошукові системи, коли URL змінюється. Bing, Yandex і Seznam його використовують, а індекс Bing це те, що читає пошук ChatGPT. Застосунок-конструктор на основі ШІ, який AI-асистенти не можуть знайти, це особливий вид невдачі.
Очевидний підхід, надсилати всю карту сайту під час кожного розгортання, призводить до обмеження частоти запитів для ключа, а більшість розгортань не змінюють нічого, що цікавить пошукову систему. Тож скрипт порівнює карту сайту, яку сайт віддає зараз, з щойно зібраною, і надсилає лише різницю.
Два деталі зробили це працездатним:
- Знімок перед розгортанням. Базову версію треба зафіксувати до того, як нова збірка стане доступною. Після цього «жива» карта сайту вже нова, і кожна різниця виходить порожньою.
- Поки що лише нові сторінки. Наша карта сайту не має дат
lastmod, тож скрипт повідомляє про нові сторінки, але не про перезаписи. Якщо проставити кожній URL дату збірки, весь сайт позначався б як змінений під час кожного розгортання, а саме цього спаму ми й намагалися уникнути.
Скрипт працює лише для розгортань у продакшені й ніколи не валить збірку: на момент його запуску сайт уже живий, а пінг пошуковій системі не вартий червоного розгортання.
6. Наш власний край казав «не знайдено»
Коли ми запустили сторінки /ai (докладніше про них у посадковій сторінці для кожного виду бізнесу), тестове середовище показувало «Not found» для всіх них, тоді як статичний хостинг віддавав їх нормально.
Сервіс перед нашими маркетинговими хостами пропускає лише перелічені в дозволеному списку шляхи, а все інше отримує жорстку 404. Шляху /ai у списку не було, бо він був новим. Ми додали /ai і /ai/* та тест, що перевіряє їх проходження. Це дрібна помилка, але саме такого роду, через яку новий розділ сайту стає невидимим для краулерів, і ніхто цього не помічає.
Що ми з цього взяли
- Читайте HTML, який читає краулер. Більшість цих проблем було невидно в браузері й очевидно у попередньо відрендереному файлі.
- Перетворюйте правила SEO на перевірки збірки. «Один FAQPage на сторінку» тепер забезпечується, а не згадується.
- Кажіть пошуковим системам, що саме ви маєте на увазі. Якщо ви не вказуєте, які зображення або факти вас представляють, вони здогадуються самі.
- Search Console показує, яке питання ставили люди. Покази без кліків зазвичай означають, що сторінка відповідає на інше питання.
- Надсилайте різниці, а не все. Пінг лише змінених сторінок тримає вас у межах обмежень частоти запитів.
Якщо ви робите те саме для сайту, який побудували самі, посібники про SEO для сайтів, створених з AI і налаштування Google Search Console охоплюють основи.