Як вивести сайт з-під санкцій Google та як їх уникати | Кейси Оксани Жилки

27 вересня Оксана Жилка, Senior SEO Manager в ЛУН, на вебінарі Коллаборатора розповіла, що робити, якщо «посварилися» з Google і потрапили під санкції пошуковика. Як врятувати свій ресурс, та як уникати таких ситуацій. 

Відео вебінару👇

Працює в SEO із 2012 року, вчилась в Дніпрі на спеціальності «Програмне забезпечення автоматизованих систем», тому за спеціальністю — програміст, і в першу чергу тех. лід. Почала кар’єру з власного проєкту у 2012: вебстудія, яка із іншим керівництвом існує і досі. 

Сьогодні в основному працює з продуктовим SEO, що включає ASO, YouTube SEO та SERM, займається медіа продакшном.

Далі — від імені Оксани👇

Типи санкцій: 

• автоматичні санкції — це санкції пошукових систем, які виникли внаслідок обробки даних сайту алгоритмами пошукових систем. Знімаються вони також автоматично після повторної обробки даних сайту тим самим алгоритмом ПС,
• ручні санкції — санкції, які виникли, бо хтось пожалівся на контент, розміщений у вас на сайті, або діяльність компанії / SEO-відділу. Знімаються  представником Google Legal Help або просто Google Help після розгляду ваших виправдань.

Не всі санкції пошукових систем можна зняти в принципі. Але є варіанти, коли це можливо, особливо у випадку автоматичних санкцій. Вони накладаються автоматично, на якусь сторінку вашого сайту або на якусь функціональність вашого продукту (наприклад, веб-форми, що хостяться на сайті). Це все можна легко пофіксити, та після наступного проходу пошуковими роботами ці санкції будуть також в автоматичному режимі зняті. 

Це можна зробити доволі швидко, якщо вчасно відреагувати. У такому випадку ви отримаєте повідомлення в Google Search Console, що у вас щось не так з сайтом (якщо ви взагалі налаштували Search Console, а це обов’язково треба).

Алгоритм обробки даних ПС — це програмне забезпечення (робот або просто бот), яке має свій User Agent, назва якого не розголошується компанією Google і не може бути об’явлена явно в source code вашого ресурсу. Алгоритм обробки даних не має прямого відношення до Core оновлень ПС Google.

Алгоритми — це не санкції. І це не Core update. Їх не потрібно плутати між собою. До деяких алгоритмів, про які ми зараз поговоримо, ми як SEO-спеціалісти не можемо звертатися явно в коді. Ви знаєте, що є така специфікація як User Agent — її можна використовувати як в robots.txt, так і в макеті вашого сайту, у верстці, і говорити: «Любий бот, не заходь сюди, не роби це й ось це».

Але до деяких алгоритмів ми не можемо «достукатись», тому що назва їх User Agent не розповсюджується навіть зі сторони Google і вони за цим слідкують. Ми до них не можемо звертатися.

Google Panda: про контент 

Google Panda — алгоритм, що проходить ваш сайт постійно і слідкує за якістю вашого контенту. Тобто:

• копірайт, 
• переспам,
• водянистість тексту, 
• on-page SEO.

Це означає, що зі сторінкою сайту або із цілим розділом щось не так і ви можете змінити свій контент.

Google Penguin: про зовнішні посилання 

Penguin — це все про зовнішні посилання. Ви отримуєте в Google Search Console підозру, що ви використовуєте посилання, які отримали неорганічно, і через це на вас накладені санкції.  У такому випадку в першу чергу потрібно зняти ці посилання, додати сайти в Google disavow і написати реквест: «Я все почистив, подивіться, будь ласка, нічого поганого не хотів робити, нічим не маніпулював». 

До речі, така ситуація може вийти не по вашій вині, вас можуть заспамити конкуренти. Я думаю, багато хто стикався з такими ситуаціями. Тому навіть якщо ви не купуєте посилання, ростите органічно — все одно треба через Google Search Console аналізувати ваші зворотні посилання.

Google Hummingbird: про мобільний і голосовий пошук

Колібрі — це один із велетенських апдейтів, за яким я слідкувала наживо. Я це все тестувала, бігала по Києву і з різних локацій говорила в айфон: «Окей, Google». Дуже класне було тестування, дуже багато фічей я зрозуміла по локальному пошуку і по мобайлу. Аби зрозуміти, як усе працює і нащо нам Колібрі, треба обов’язково встановити Google Асистент і працювати із ним. Це оптимізація щодо нього і локального пошуку.

Google Pigeon: про локальний пошук за регіоном та бізнесом

Також може прилетіти Голуб. Він стосується локального пошуку, local businesses, Google My Business і пошуку вашого бізнесу за геолокаційними запитами типу «Веб-хостинг поряд». Юзер може не вказувати геолокацію, але мати її на увазі, і в нього за замовчуванням ввімкнений геолокаційний пошук. 

Це також буде геолокація, і це також має відношення до оптимізації вашого лістингу Google My Business. Там має бути правильна інформація по вашому бізнесу і НЕ має бути якоїсь некоректної адреси чи пошти. Наприклад, якийсь співробітник оформив ваш бізнесовий акаунт на свою особисту пошту. Це вже підозріло і може призвести до санкцій пошукових систем. 

Перед запуском сайту варто перевірити:  

1. Чи не знаходиться корпоративна пошта ресурсу в спам-базах Gmail. Ознака: що б ти не робив з листами, вони все одно потрапляють в спам. Ваша корпоративна пошта має бути на тому домені, який ви розвиваєте. Це так працює і так повинно працювати. Якщо ваш сайт називається “ноунейм.ком”, у вас має бути пошта “ім’я@ноунейм.ком”, і ніяк інакше.
2. Чи не знаходиться IP сайту в спам-базах. Звідти вийти складніше, тут треба звертатись у Google Support і доводити, що ви не розсилаєте ніякий спам, відправляти скріншоти. Рішення: кожен ресурсу має знаходитись на окремому IP і мати лише одного власника GSC.
3. Свої JS скрипти і скрипти аналітики в GTM. Перед тим, як їх перевірить Google.
4. AWS. Якщо використовується AWS S3 Cloud Hosting або навіть Google Cloud рішення, не варто додавати картинки в рутову карту сайту. Тут доречніше використати для них мікророзмітку для картинок schema.org і автоматично оптимізувати зображення.
5. Як прописаний Alt text. Головне правило: писати не для ботів, а для людей. Вас можуть забанити, якщо там буде набір ключових слів, бо ви порушуєте правила доступності. Альтернативний текст повинен бути змістовний, бо постійно розробляються спеціальні програми обробки інформації, які, наприклад, зачитують альти сліпим людям. Якщо ви там нічого не написали, то людина нічого не побачить — вашого сайту в принципі не існує, якщо у вас немає адаптації для людей з disabilities, треба розуміти це. В атрибуті rel також прописуються варіанти того, як цей URL обробити боту та різними девайсами, які зачитують текст, але нічого не відображають.
6. Коректність та правильність роботи з User Agent. Наприклад, ви довго працювали в СНД-сегменті та обмежували трафік в Google, тому що орієнтувалися на популярний російський пошуковик. Потім змінився час, змінилися події, ви вирішили не орієнтуватись на нього і змінили ракурс на Google. Але в User Agent на конкретних сторінках або в robots.txt ви забули поміняти директиви, поміняти якісь речі щодо того, що ви і далі таргетуєтесь на стару пошукову систему, але намагаєтесь просуватись в Гуглі, якому обмежили доступ на сайт до сторінок або до вмісту контенту. 
7. Маніпуляції з User Agent. Файли robots.txt — це не панацея від індексування чи неіндексування. Це файлик який взагалі має мало впливу на ваш ресурс, але по директоріям він може менеджерити бота, особливо купу пошукових ботів. Окрім Google, Yahoo, Bing, DuckDuckGo є ще мільйони інших пошукових ботів, яких ви не враховуєте, але ви там ранжуєтесь і там ви є в видачі.
   Потрібно розуміти, чи хочете ви мереджерити User Agent? Для цього потрібна людина, SEO-спеціаліст або DevOps. Я ніколи не даю рекомендацію, що можна SEO-спеціалісту робити самому файл robots.txt. Я прошу це зробити DevOps, бо він розуміє, як розпакований проєкт, які є директорії. І він може по директоріям скерувати бота.  
   Для кожного бота можна робити окремі запити. Це і для пошуку по картинкам, і для пошуку, наприклад, по Youtube-відео, окремо для Google Ads. Якщо ви не використовуєте рекламу, ви можете, наприклад, забанити доступ цих ботів на ваш сайт, і вони не зможуть аналізувати вас.
   Або ви використовуєте у своєму робочому портфелі набір інструментів для SEO, де є свої User-боти, і якийсь із розкручених маркетингових тулів не використовуєте, ви можете забанити їм доступ, щоб конкуренти не могли аналізувати вас через цих ботів. Але деякі проблеми на рівні DevOps не вирішуються, вони будуть тільки ускладнювати парсинг вашого сайту іншими ботами (самописними або не самописними) і таким чином захищати свій контент.
8. HTTP Headers. HTTP Security Headers — дуже важливо їх правильно налаштувати. Google деякі правила налаштовує, але сам не може імплементувати на своєму боці, тому що дуже велика корпорація з великою інфраструктурою. Деякі Core Update робляться роками. Наприклад, ми всі чекали, коли Google відмовиться від cookies, але він детермінував цю зміну на наступний рік. При цьому готуватися треба вже зараз. 

Трохи детальніше про те, як працювати з HTTP Headers. 

На скріні вище є хедер як «x-frame-options» — треба обов’язково там поставити значення denied або sameorigin:

• denied — ніякий контент не може вбудовуватись в фрейми вашого сайту.
• sameorigin — ви зможете окрім основного домену працювати ще й на піддоменах. 

Це захищає від фішингу, який з'являється в велетенських масштабах.

Хедер Content-Security-Policy — це whitelist і blacklist. Ви можете їх менеджерити на рівні DevOps. Я говорю, що SEO-вці часто не можуть розібратись, як працює файл robots.txt, і не розуміють, що, наприклад, директива disallow має більше ваги, ніж allow. 

Тому я не довіряю цю працю SEO-спеціалістам, в основному DevOps я прошу її зробити або перевірити вже готовий сайт, тому що часто бачу як пишуть allow 2-3 сторінки і б’ються над проблемою, чому інші не індексуються. Думають, що вони під санкціями, пишуть репорти, реквести. А насправді у людей просто неправильно сформований robots.txt, вони не вивчили його примітивні директиви.

Є також Referrer-Policy і Permissions-Policy. Якщо ви не знаєте, як з цими хедерами працювати, якщо у вас немає людини, яка буде менеджерити блек- та вайтлісти, то краще їх не робити, ніж робити. Бо це така річ, на яку можливо (залежно від того, яка велика у вас інфраструктура) вам буде потрібен окремий спеціаліст або група спеціалістів. 

Є певні правила поведінки в інтернеті. WWW — це WorldWide Web. В залежності від їх дотримання SEO поділяють на black, gray та white, і це важливо знати та розуміти. Як на мене, якщо ти не знаєш всі методи SEO, які доступні на ринку, а знаєш тільки «біле і пухнасте», ти в принципі не SEO-шник. Ти маркетолог, скоріш за все, контент-мейкер, контент-райтер, але не технічний seo-спеціаліст.

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

Щоб залишити скаргу або зрозуміти, чому скарга на ваш ресурс спрацювала треба:

• вивчити англійську мову, тому що інтерфейс не має іншої локалізаціїї ніж EN
• перейти за посиланням і розглянути види скарг і усунути проблеми порушення правил і умов надання сервісу Google.
• після усунення проблем безпеки ресурсу видалити і додати заново карту сайта в GSC. 

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

Інфраструктурні задачі — це тяжкі задачі. І спеціалістам, які працюють на позиції «архітектор», або core solution specialist із ними важко працювати. Адже навіть зайвий пробіл або не та буква в robots.txt можуть привести до проблем в майбутньому. І якась незначна помилка може тягнутися багато років.

 Тут важливі кілька моментів. По-перше, визначте: ви порушник чи жертва. Тут треба правильно оформити скаргу в Lumendatabase.org: видаліть контент, що порушує права власності і підтвердіть цю цію через сервіс lumen.org напряму або через Google Legal Help.

Справа може дійти до суда і для вас, і для вашого аб’юзера: 

• якщо справа стосується порушення GDPR. 
• якщо ви дійсно порушуєте закон. 
• якщо справа стосується безпеки дитини в інтернеті. 
• якщо ви надаєте Cloud Base сервіси для юзерів і не маєте власної системи перевірки контенту: фішинг, фейкові форми, що створюються на вашому хостингу, тощо.

Були в нашому житті core updates, які змінювали життя SEO-вців. Core Updates, хоча і стосуються оновлення функціонала алгоритму, не є тим самим, що самі алгоритми.

Якщо ми хочемо дійсно розуміти всю історію, як змінювався інтернет та світ, ми можемо подивитися це в дуже крутій справці на Search Engine Journal — це дійсно архів того, як це все було.

Якщо вам незручно це робити через читання, через роботу з архівом, ви можете скористатися дуже класними продуктами від Barracuda, які можуть синхронізуватися з Google Analytics, показувати основні Core Updates та що взагалі відбувається в світі SEO. Тому що, якщо ви працюєте над сайтом, над великою інфраструктурою, у вас замилений погляд і ви не можете вийти за рамки цієї інфраструктури. Ви нічого окрім сайту не бачите, ви не розумієте, які Core Updates взагалі відбуваються, коли, наскільки швидко. 

Наведемо основні Google Gore Updates, які змінювали наше життя:

• Florida
• Big Daddy
• Jagger
• Vince
• Caffeine
• Panda
• Freshness Algorithm
• Page Layout Algorithm
• Venice Update
• Penguin
• EMD (Exact Match Domain)
• Payday
• Hummingbird
• Pigeon
• Mobilegeddon
• Quality Updates
• RankBrain
• Fred

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

Якщо немає повідомлення в Search Console, то це можуть бути penalties, які вам наклали вручну. Ви йдете і дивитесь в Lumen, чи ви не порушуєте права по копірайту. Ви можете навіть того не хотіти, але використати десь відео чи картинку — і на вас поскаржилися. Це legal-санкції, в ручному режимі робиться і розглядається. Вам треба туди піти, пройтись по кожному пункту, пройтись по кожному пункту моєї презентації — чи то якийсь продукт (Youtube, пошук, окремо пошук по картинкам). Якщо ви десь порушуєте права по копірайту, то санкції є. 

По посиланнях в основному приходить в Console підозра і починаються премовини з legal-департаментом, що це вас конкуренти наспамили, що ви не самі собі такі анкори поставили. І ви починаєте, як Шерлок, сипати скріни і показувати докази.

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

Може бути, що у вас на сайті все добре, але в Google My Business застаріла інформація і вона вам шкодить. Або, дуже частий кейс, технічна помилка: у вас сайт існує 10 років. Ви в мікророзмітку організації вбили не ті соціальні мережі, старі. І у вас досі вони підтягуються в Google Пошуку чи в інших пошуках із неправильними посиланнями. Або ви розмітили контент на сторінці і вказали неправильні посилання технічні. У мене таке було, коли був getparameter зайвий. І це призвело до санкцій. Це не санкції, а більше технічна помилка. Без якогось повідомлення із індексу ти вилетиш, бо в мікророзмітці вказано не те посилання, не туди через getparameter із канонічного URL когось переправляєш. Це нелогічно з точки зору того, як має рухатись безпечно юзер по сайту. Перевіряйте логіку, чи сек’юрно юзер рухається по сайту, чи контент відповідає якості, чи немає злоякісних технічних посилань, і чи немає технічних помилок.

Це означає, що санкції в тебе є тільки в пошуковій системі Google. Немає судових процесів, у всіх інших системах ти є, але з Google проблеми.

Я не знаю, що писали кілька років тому. Підклейка там може бути, це маніпулювання редиректами. Річ у тому, що був такий навіть кейс, людина отримала запрошення працювати в Google і грошову премію за те, що до такого додумалась. Програміст php-спеціаліст, який із цією інформацією не заробив собі мільйони, або зробив щось офігенне. Він написав: «Hello Google, I’m smarter than you». Повідомив про важливість для накрутки трафіку. Він зробив редірект прямо в карті сайту зі своїх Url на класні топові ресурси і вийшло, що на його Url йшли поведінкові фактори Spotify, в нього відразу трафік був на мільйони. І він зарепортив це в Google, цю штуку пофіксили ще році у 2012. 

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

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

Це нормальне явище в маркетингу і нормальне явище в інтернеті. Десь це маніпуляція із редиректами, а десь явище бізнесове, коли одна компанія поглинає іншу, і це нормально. Тому тут може бути техніка gray-seo, яка точно не заборонена, але суперечить логіці. 

Інколи, щоб врятувати проєкт, потрібно змінити домен і зробити ребрендинг. Інколи домен міняти вже не можна, коли компанія існує років 10-20. І тоді починається «лікування» місяців на 5. Це дорого і довго. Але якщо прям на весь домен, то місяців на 5, якщо це буде із посиланнями пов’язано, або з великою кількістю краденого контенту. Якщо це технічна помилка на стороні DevOps, то ти її просто швидко фіксиш і все. 

Це коли частина adult-анкору, частина мого url і частина url на якийсь фільм про Гаррі Поттера. Був в мене такий анкор. І я думаю, що той, хто зробив аж таку композицію, хотів мене просто вбити цим анкором😄. Щоб і сіра ніша, і крадений контент. 

Ми дякуємо Оксані за піднавальну та корисну доповідь! І чекаємо читачів на наших наступних заходах👈