Уроци за SEO от поправката на собствения ни сайт

Прекарахме няколко дни в четене на собствения си сайт така, както го чете търсачка, и открихме шест неща, които си струва да поправим. Всяка страница обявяваше два FAQ блока, Google използваше декоративното фоново сияние като наша миниатюра, група страници с шаблони се класираха за търсения, на които не отговаряха, а нова секция на сайта беше блокирана от собствения ни edge на staging. Нищо от това не беше драматично. Всичко обаче тихо струваше видимост.

Сайтът в един абзац

mythex.ai е single-page приложение, което предварително рендираме по време на билд: скрипт обхожда всеки маршрут, записва статичен HTML файл за него и вмъква заглавието, описанието и структурираните данни на страницата (JSON-LD блокът, който казва на търсачките какво е страницата — вижте какво са структурираните данни). Повечето от описаното по-долу живее в стъпката на предварителното рендиране, защото това е HTML, който краулърът действително чете.

1. Всяка страница твърдеше, че е FAQ страницата

Симптом. Нашият HTML шаблон съдържаше сайтово-широк FAQPage блок в структурираните данни, с URL, сочещ към /faq. Предварителното рендиране добавяше собствен FAQPage на всяка страница отгоре. Така всяка страница на сайта носеше два — а политиката ни за поверителност казваше на Google, че е FAQ страницата.

Защо има значение. Google очаква най-много един FAQPage на страница. Втори, който сочи другаде, е нещо, което води до отстъпка на маркирането на страницата, а не просто до игнориране.

Поправка. Глобалният блок е премахнат. FAQ маркирането на всяка страница вече идва от едно място, включително самата /faq, която го строи от пълния списък с въпроси. Страниците без FAQ сега не обявяват нищо, което е честният отговор. А предварителното рендиране проваля билда, ако някоя страница отново носи повече от един FAQPage. Правило, което живее само в нечия памет, рано или късно се нарушава; правило, което билдът налага, не се нарушава.

2. Google ползваше грешната снимка за нас

Симптом. В резултатите от търсене миниатюрата на Mythex беше мекото пулсиращо сияние зад hero секцията на началната страница — декоративна фонова картинка — вместо нашата карта за споделяне.

Защо се случи. Никога не казахме на Google коя картинка представлява страницата, така че тя избра една, която намери.

Поправка. Две страни на един и същи проблем:

• Кажете коя картинка е на страницата. Началната страница вече има WebPage възел с primaryImageOfPage, сочещ картата за споделяне, а структурираните данни на всяка предварително рендирана страница носят собствено изображение (картата за споделяне на страницата или стандартното).
• Скрийте декорацията. Фоновите изображения сега са забранени в robots.txt и се сервират със заглавка noindex, noimageindex, така че остават извън търсенето по изображения и миниатюрите.

3. Търсачките знаеха само нашето лого

Маркирането ни Organization имаше име, лого и няколко социални връзки — брандинг, нищо друго. Търсачките изграждат информационния панел на компанията от факти като в регистър, затова добавихме тези от търговската ни лицензия: официално име, дата на основаване, основател и адрес по регистрация. Телефонния номер умишлено оставихме извън него.

4. Страниците с шаблони отговаряха на грешен въпрос

Симптом. Search Console показваше три страници с шаблони, които събираха показвания и никакви кликвания. Една се класираше за „content strategist portfolio“ и варианти, друга за „best italian restaurant website design“, трета за клъстер около „agile board“ — половината от тези търсения съдържаха думата „free“. Позициите бяха от средата на 20-те до 50-те.

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

Поправка. Всяка от трите вече има секция, написана за търсенето, а не за продукта, заглавие и описание с думите, които хората въвеждат, и FAQ, които заслужават маркирането, което вече излъчваха.

Същият commit поправи и по-тих проблем. Блокът „свързани шаблони“ взимаше първите четири шаблона в категория, така че всеки шаблон за портфолио сочеше към едни и същи четири портфолиа, а останалата част от категорията нямаше никакви вътрешни връзки. Заменихме го с пръстен, подреден по подкатегория: всяка страница с шаблон получава точно четири връзки навътре и четири навън. Предварително рендираният HTML вече също печата тези връзки — преди те съществуваха само след изпълнение на JavaScript, което краулър може никога да не изпълни.

5. Съобщаване на Bing за новите страници в момента на деплоя

Google игнорира IndexNow, протокол за пингване на търсачки, когато URL се промени. Bing, Yandex и Seznam го използват — а индексът на Bing е това, което чете търсенето на ChatGPT. AI билдър на приложения, който AI асистентите не могат да намерят, е особен вид провал.

Очевидният подход, изпращането на целия sitemap при всеки деплой, е начинът ключът да бъде ограничен, а повечето деплойи не променят нищо, което търсачката да отбелязва. Затова скрипт сравнява sitemap-а, който сайтът сервира в момента, с току-що построения и изпраща само разликата.

Две подробности накараха това да работи:

• Направете снимка преди деплоя. Базовата линия трябва да се заснеме, преди новият билд да е в употреба. След това „живият“ sitemap вече е новият и всяка разлика излиза празна.
• Засега само нови страници. Нашият sitemap няма дати lastmod, затова скриптът обявява нови страници, но не и промени. Слагането на датата на билда към всеки URL би отбелязало целия сайт като променен при всеки деплой — точно спама, който избягвахме.

Скриптът работи само при продукционни деплойи и никога не проваля билда: когато се изпълни, сайтът вече е онлайн, а пингването към търсачка не струва червен деплой.

6. Нашият собствен edge казваше „не е намерено“

Когато пуснахме страниците /ai (повече за тях в целева страница за всеки вид бизнес), staging показваше „Not found“ за всички, докато статичният хост ги сервираше правилно.

Услугата пред маркетинг хостовете ни пропуска само позволен списък пътища; всичко друго получава твърд 404. /ai беше нова и не беше в списъка. Добавихме /ai и /ai/* с тест, който проверява, че минават. Малък бъг, но точно от онези, които правят нова секция невидима за краулърите, без някой да забележи.

Какво взехме от това

• Четете HTML-а, който чете краулърът. Повечето от тези неща бяха невидими в браузър и очевидни в предварително рендирания файл.
• Превръщайте SEO правилата в проверки на билда. „Един FAQPage на страница“ вече се налага, а не се помни.
• Казвайте на търсачките какво имате предвид. Ако не кажете коя картинка или кои факти ви представляват, те ще налучкват.
• Search Console ви казва на какъв въпрос хората търсят отговор. Показвания без кликвания обикновено означават, че страницата е отговаряла на друг въпрос.
• Изпращайте разлики, а не всичко. Пингването само на промененото ви държи в рамките на лимитите.

Ако правите същото за сайт, който сте построили, нашите ръководства за SEO за уебсайтове, построени с AI и настройване на Google Search Console покриват основите.