Японський SEO-спам — це різновид злому WordPress, за якого на сайті створюються сторінки з ієрогліфами, підозрілими заголовками, посиланнями на сторонні товари або рекламні ресурси. Власник може не бачити їх у меню та адмінпанелі, але пошукові роботи знаходять такі URL через sitemap, внутрішні посилання, змінені шаблони або спеціальні правила перенаправлення.
Проблема не обмежується неякісними сторінками в індексі. Зловмисники могли отримати доступ до файлів, бази даних, облікових записів або налаштувань сервера. Тому просте видалення кількох URL не гарантує, що сайт очищений і атака не повториться. Якщо потрібне комплексне ремонт сайту після SEO-спаму, спочатку варто зафіксувати симптоми та зберегти копії для аналізу.
Як розпізнати японський SEO-спам
Найчастіше зараження виявляють за такими ознаками:
- у Google з’явилися сторінки японською мовою, хоча сайт працює українською або іншою мовою;
- у результатах пошуку видно незнайомі URL з назвами товарів, брендів, казино, фармацевтики чи рекламних пропозицій;
- сторінки відкриваються лише для пошукових роботів або користувачів із певними реферерами;
- у Google Search Console зростає кількість проіндексованих сторінок, яких немає в адмінпанелі WordPress;
- на сайті з’являються невідомі користувачі, плагіни, віджети, записи або зміни в меню;
- сервер працює повільніше, зростає навантаження на процесор або надходять повідомлення про шкідливий код;
- у вихідному коді, футері, заголовках або файлах шаблону з’являються приховані посилання та незрозумілий JavaScript.
Перевірку можна почати з пошуку в Google за запитом site:ваш-домен.ua і перегляду звітів Search Console. Окремо перевірте файли robots.txt та XML-карти сайту. Водночас відсутність підозрілих сторінок у Google не означає, що зараження немає: частина контенту може приховуватися від звичайних відвідувачів.
Не варто одразу видаляти підозрілі файли чи таблиці. Спочатку зробіть повну резервну копію файлів і бази даних, бажано зберігши її окремо від хостингу. Якщо копія містить шкідливий код, це не робить її безпечною для відновлення, але вона може знадобитися для порівняння та розслідування.
Де шукати приховані сторінки та правила
Джерело спаму може бути в базі даних, файловій системі або налаштуваннях вебсервера. Перевірка має бути послідовною, щоб не пропустити механізм, який генерує сторінки повторно.
- База даних. Перегляньте таблиці записів, сторінок, метаданих, опцій і користувачів. У стандартній структурі WordPress особливу увагу звертають на
wpposts,wppostmeta,wp_optionsта таблиці, пов’язані з плагінами. Проте префікс таблиць може бути іншим. - Адмінпанель. Перевірте всі типи записів, чернетки, кошик, меню, віджети, користувачів і встановлені плагіни. Невідомий адміністратор або плагін із незрозумілим призначенням є серйозною ознакою компрометації.
- Файли WordPress. Порівняйте ядро, теми та плагіни з офіційними дистрибутивами відповідних версій. Підозрілими можуть бути нові PHP-файли в каталогах завантажень, кешу або тимчасових папках.
- Правила перенаправлення. Перевірте
.htaccess, конфігурацію вебсервера, налаштування CDN і редиректи в плагінах. Шкідливі правила можуть показувати різний вміст пошуковим роботам та відвідувачам. - Планувальник. Перегляньте WP-Cron, системний cron хостингу та завдання, які можуть повторно створювати сторінки після очищення.
Пошук лише за ієрогліфами часто не дає результату. Спам може бути закодований, розбитий на фрагменти або збережений у серіалізованих даних. Масове редагування бази даних без розуміння структури здатне пошкодити серіалізовані значення, меню, налаштування плагінів і зв’язки між записами.
Очищення файлів бази й sitemap
Перед очищенням зафіксуйте список заражених URL, підозрілих файлів, користувачів і змінених налаштувань. Це допоможе зрозуміти масштаб проблеми та перевірити результат. Якщо сайт важливий для бізнесу, бажано спочатку створити його копію на окремому середовищі або обмежити публічний доступ на час робіт.
У базі даних потрібно видаляти не тільки самі спам-сторінки, а й пов’язані метадані, таксономії, коментарі та записи, які могли використовуватися для генерації контенту. Операції виконують після перевірки резервної копії та з урахуванням префікса таблиць. Якщо немає чіткого розуміння, які записи належать зловмисникам, безпечніше не проводити масове SQL-видалення вручну.
Пошкоджені або змінені файли ядра WordPress можна замінити чистими файлами тієї самої версії, але не слід бездумно перезаписувати каталог wp-content. Саме там знаходяться завантаження, теми та плагіни. Кожен плагін і тему потрібно перевірити окремо, а невикористовувані компоненти — видалити. Перевстановлення з офіційного джерела часто безпечніше за ручне редагування підозрілого PHP-коду, але спочатку необхідно з’ясувати, чи не залишився бекдор в іншому місці.
Після очищення оновіть XML sitemap через плагін SEO або інший механізм, який її формує. Переконайтеся, що карта містить лише актуальні URL, не включає сторінки зі спамом і доступна за правильною адресою. Також перевірте, чи не створюються дублікати sitemap, фальшиві RSS-стрічки або URL через параметри.
Якщо невідомо, як саме відбувся злам, очищення не можна вважати завершеним після видалення сторінок. Потрібно перевірити журнали доступу, версії компонентів, права на файли, облікові записи FTP, панель хостингу та поштові скриньки адміністраторів.
Як повідомити Google про виправлення
Після технічного очищення перевірте сайт у Google Search Console. У розділі безпеки та ручних заходів можуть відображатися попередження про злам або спам. Якщо Google застосував ручний захід, після усунення причин можна подати запит на повторну перевірку. У ньому варто коротко описати, що було виявлено, які компоненти перевірено, що видалено та які заходи безпеки впроваджено.
Інструмент видалення URL у Search Console може тимчасово приховати сторінки з результатів пошуку, але не прибирає їх із сайту та не усуває причину зараження. Тому його використовують як допоміжний крок після блокування або видалення шкідливого контенту. Для окремих URL можна перевірити доступність через інструмент перевірки URL і, якщо сторінка вже виправлена або видалена, попросити Google оновити дані.
Переіндексація не відбувається миттєво й залежить від частоти обходу домену та стану сайту. Не варто створювати десятки повторних запитів або відкривати Google доступ до сторінок, які ще генерують спам. Спочатку переконайтеся, що сервер повертає коректні коди відповіді, sitemap оновлена, а підозрілі URL більше не відтворюються.
Як захистити сайт від повторної атаки
Після очищення змініть усі пов’язані облікові дані: паролі WordPress, хостингу, FTP або SFTP, бази даних, пошти та CDN. Не використовуйте один пароль у кількох сервісах. Для адміністраторів увімкніть двофакторну автентифікацію та видаліть невідомі або зайві облікові записи.
- оновіть ядро WordPress, теми та плагіни до підтримуваних версій;
- видаліть невикористовувані компоненти, особливо завантажені не з офіційних джерел;
- налаштуйте регулярні резервні копії файлів і бази даних та перевіряйте можливість їх відновлення;
- обмежте права доступу до файлів і не дозволяйте виконання PHP у каталогах завантажень, якщо це сумісно з конфігурацією сайту;
- увімкніть моніторинг змін файлів, сповіщення про нових адміністраторів і контроль безпеки;
- перевіряйте журнали сервера, невдалі входи, незвичні запити та раптове зростання навантаження;
- захистіть панель адміністрування, XML-RPC та інші точки доступу відповідно до реальних потреб сайту.
Якщо приховані сторінки з’являються знову, у файлах знаходиться незрозумілий обфускований код, змінюються правила сервера або сайт втрачає доступність, краще припинити експерименти з видаленням. Подальші дії без резервної копії та діагностики можуть призвести до втрати даних або знищення доказів злому. У такій ситуації потрібна перевірка всього середовища WordPress, сервера та бази даних, а не лише очищення видимих наслідків SEO-спаму.