Ручные меры Google: как проверить санкции и подготовить запрос на пересмотр
Ручные меры Google подтверждаются уведомлением в Search Console, а не формой графика посещаемости. Если мера действительно назначена, начните с её точного названия и области действия, устраните нарушение во всех затронутых местах и только затем готовьте запрос на пересмотр. Письмо с обещаниями заменить исправление не может.
Эта инструкция помогает организовать работу владельца сайта, разработчика и редактора: собрать доказательства, проверить общий шаблон и честно описать результат. Учебный пример ниже полностью вымышленный; он не является историей реального клиента или обещанием снятия меры.
1. Подтвердите уведомление в правильном ресурсе
Откройте раздел «Меры, принятые вручную» в Search Console для нужного сайта. В английском интерфейсе это Manual actions. По справке Google, такая мера возникает после проверки человеком; уведомление отображается в отчёте и центре сообщений.
Сохраните название меры, дату сообщения, описание и показанную область. Проверьте выбранный ресурс: старый домен, тестовый поддомен и рабочий сайт нельзя считать взаимозаменяемыми. Если доступ остался только у прежнего подрядчика, сначала восстановите рабочий доступ команды, а не делайте вывод по пересланному фрагменту письма.
Проверьте, сколько мер перечислено. Исправление одной категории не закрывает другую. Например, устранённый скрытый текст не подтверждает исправление отдельной проблемы со ссылками. Для каждой записи нужен собственный результат, связанный с её формулировкой.
Если отчёт сообщает об отсутствии мер, это не доказывает идеальное состояние сайта. Но утверждение «сайт под санкциями Google» в смысле подтверждённой ручной меры пока не обосновано. Назовите наблюдаемую проблему точнее: снизились показы, исчезла группа URL или возникли ошибки доступа.
2. Отделите меру от других причин потери видимости
В руководстве по падению поискового трафика Google рассматривает разные причины: изменения алгоритмов, технические ошибки, безопасность и изменение спроса. Одинаковая просадка на графике может требовать совершенно разных действий.
| Наблюдение | Что проверять | Рабочее направление |
|---|---|---|
| Есть запись Manual actions | Тип меры и указанный охват | Устранение нарушения и пересмотр |
| Нет записи, снизились показы | Группы запросов, даты, спрос, изменения сайта | Диагностика причины снижения |
| URL не индексируются из-за технической ошибки | Ответы, доступность, правила и состояние страниц | Исправление технического препятствия |
| Есть Security issues | Указанные угрозы и следы компрометации | Работа с безопасностью и её проверкой |
Отчёт Security issues относится, в частности, к взлому, вредоносному содержимому и действиям, опасным для посетителей. Его нельзя заменить заявкой из Manual actions. Если проблемы присутствуют в обоих отчётах, ведите оба направления и соответствующие проверки.
Не начинайте массовую переработку сайта только потому, что кто-то назвал падение «фильтром». Сначала определите, какое свидетельство подтверждает диагноз. Это позволяет сохранить полезное содержимое и направить время команды на реальную причину.
3. Переведите область меры в проверяемый реестр
Google показывает область действия через описания и шаблоны адресов. Они могут относиться ко всему сайту или его части; не каждая страница, подходящая под шаблон, обязательно затронута. Не превращайте показанные примеры в исчерпывающий список работ.
Создайте реестр с URL, типом страницы, используемым шаблоном, обнаруженным признаком, источником данных и результатом исправления. Для каталога это могут быть карточки, категории, посадочные фильтров и отдельные версии оформления. Для издателя — статьи, рубрики и пользовательские материалы.
Свяжите нарушение с механизмом появления. Один блок в общем шаблоне способен затронуть сотни адресов; одна вручную вставленная строка — только конкретный материал. Редактировать страницы поштучно без поиска источника опасно: следующий выпуск может вернуть удалённый фрагмент.
Зафиксируйте границы известного охвата и неизвестные участки. Формулировка «проверены опубликованные карточки из выгрузки CMS, архивные маршруты ещё сверяются с журналами» полезнее преждевременного «проверено всё». Перед отправкой пересмотра эти пробелы нужно закрыть либо обоснованно определить их отношение к уведомлению.
Распределите ответственность заранее. Владелец сайта утверждает перечень работ, разработчик отвечает за общий механизм публикации, редактор — за содержание, а отдельный проверяющий сверяет результат с реестром. Один человек может выполнять несколько ролей, но итоговая проверка не должна сводиться к сообщению исполнителя «готово». Полезно назначить ответственного за сводный документ: иначе исправление шаблона, редакторская правка и повторная публикация останутся несвязанными задачами, по которым никто не сможет подтвердить общий результат.
4. Исправляйте указанное нарушение по действующим правилам
Изучите ссылку на пояснение конкретной меры. В Spam policies Google скрытый текст или ссылки рассматриваются как нарушение, когда их размещают ради манипуляции поиском, делая недоступными обычному посетителю. Отдельно описано неестественное заполнение страницы ключевыми словами.
При этом вкладки, раскрывающиеся блоки и текст для экранных дикторов сами по себе не являются нарушением. Не удаляйте полезные элементы доступности только потому, что они не постоянно видны на экране. Оцените назначение, содержимое и способ показа блока.
Если проблема — бессмысленный перечень ключевых фраз, простое изменение цвета текста не делает его полезным. Уберите сам манипулятивный материал или переработайте содержимое под реальную задачу посетителя. Если скрыта нормальная инструкция, решение может состоять в корректном показе и удобном доступе к ней.
Не подменяйте исправление отдельной «чистой» версией для поискового робота. Google относит к клоакингу намеренную выдачу разного содержимого ради манипуляции поиском. Проверка должна подтверждать устранение причины в рабочем сайте, а не успешное распознавание посетителя, которому решили показать другой вариант.
5. Учебный пример: найдите охват общего шаблона
Предположим, магазин https://example.com получил уведомление «Скрытый текст и/или перенасыщение ключевыми словами». Команда обнаружила в модуле каталога скрытый блок повторяющихся запросов. В реестре опубликованных адресов есть 600 уникальных URL:
| Группа | Опубликованные URL | URL с найденным блоком |
|---|---|---|
| Карточки товаров | 400 | 400 |
| Категории | 120 | 120 |
| Полезные статьи | 80 | 0 |
| Всего | 600 | 520 |
Здесь 520 — результат собственного аудита конкретного признака, а не число страниц, официально указанное Google. Оставшиеся 80 статей используют другой шаблон и служат контрольной группой. Это различие нужно сохранять и во внутреннем отчёте, и в запросе на пересмотр.
Команда сверяет список из CMS с опубликованными маршрутами и известными старыми адресами. Затем проверяет, не вставляется ли аналогичный блок через ручное поле страницы, мобильный шаблон или отдельную посадочную. Наличие общего источника объясняет большую часть находок, но ещё не исключает независимые копии.
В карточке задачи фиксируются причина, место изменения и перечень затронутых шаблонов. Исполнителю должно быть ясно, почему исправление двух показанных примеров недостаточно: тот же механизм продолжит создавать нарушение на остальных адресах.
6. Удалите причину и проверьте опубликованный результат
В учебном случае разработчик убирает модуль со скрытыми ключевыми словами из двух шаблонов, а редактор проверяет поля, куда этот блок могли вставить вручную. Изменение проходит обычную проверку и выпускается на рабочий сайт. Одновременно обновляются предусмотренные кешированные версии.
Проверьте фактический ответ страницы после выпуска. Исправленный файл в репозитории не доказывает, что обновилась выдаваемая посетителю версия. Старый HTML может сохраняться в кеше, предварительно сформированных страницах или отдельной конфигурации одного из серверов.
Проверка должна охватывать источник текста и его отображение. Если материал добавляется JavaScript, одного поиска в исходном HTML мало. Если он присутствует в ответе, но скрывается стилями, один скриншот тоже не объясняет механизм. Сопоставляйте содержимое, DOM и поведение компонента.
Не закрывайте публичные исправленные страницы от Google ради сокрытия остатка нарушения. Для страниц, которые остаются опубликованными и предназначены для поиска, проверьте отсутствие случайного запрета или требования входа. Это не означает открытия административных разделов: их назначение и защита остаются отдельным вопросом.
Согласуйте изменения с теми, кто продолжает наполнять сайт. Если редактор импортирует старую выгрузку после выпуска исправления, удалённый блок способен появиться снова независимо от кода. Обозначьте исправленную версию шаблона и правила обработки старых материалов. Перед итоговой проверкой убедитесь, что очередная публикация не вернула прежний компонент. Это рабочая мера контроля изменений, а не отдельное формальное требование Google к обращению.
7. Проверьте весь охват и честно обозначьте выборку
Продолжим учебный пример. Автоматическая проверка проходит 600 URL в двух вариантах отображения — для компьютера и смартфона. Получается 1 200 проверок, а не 1 200 страниц. Она ищет известный блок и связанные признаки, сохраняя результат для каждого адреса и варианта.
Дополнительно команда вручную просматривает 24 карточки, 12 категорий и 8 статей: всего 44 разных URL. Выборка включает длинные и короткие страницы, разные состояния товара и исключения шаблонов. Такой просмотр помогает заметить смысловые и визуальные проблемы, которые не выражаются одним техническим признаком.
В результате по всем 1 200 автоматическим проверкам совпадений известного блока не найдено. Это подтверждает результат конкретной проверки; оно не означает, что алгоритм доказал отсутствие любых возможных нарушений. Полноту обеспечивают вместе разбор причины, проверка её использования и содержательная оценка.
URL Inspection помогает посмотреть доступность и результат обработки страницы, но не проверяет отсутствие ручных мер. Успешный live-тест не равен снятию санкции. Для нескольких важных адресов он дополняет проверку опубликованной версии, а статус меры читают в соответствующем отчёте.
Отдельно учитывайте проверки, которые не состоялись: таймаут, отказ доступа или пустой ответ нельзя записывать как «нарушение отсутствует». У каждой строки реестра должен быть понятный итог: проверено без находки, нарушение осталось либо результат не получен. Сначала разберите неопределённые результаты, затем повторите соответствующие проверки. В отчёте сохраняйте итоговый охват и дату повторной проверки, чтобы красивый нулевой счётчик не скрывал недоступные страницы или ошибку самого инструмента.
8. Соберите доказательства, которые можно перепроверить
Сохраните дату и версию исправления, перечень изменённых компонентов, реестр проверенных URL и несколько понятных примеров до и после. Документы должны объяснять проделанную работу, а не создавать видимость объёма. Сотня скриншотов без адресов и дат менее полезна, чем короткий связный отчёт.
Для каждого примера укажите, что именно исчезло или изменилось и откуда это известно. Если удалён модуль, приложите описание изменения и результат проверки страницы. Если исправлены материалы редакторами, покажите, какие положения переработаны и как они теперь помогают посетителю.
Разделяйте автоматические проверки и ручной просмотр. Не называйте выборку из 44 страниц ручной проверкой всех 600. Не выдавайте отсутствие одной строки за общий аудит качества. Точность формулировок позволяет рецензенту понять границы доказательств и делает последующее обсуждение предметным.
Если используете дополнительные документы по ссылке, убедитесь, что они доступны предполагаемому читателю без передачи паролей. Не добавляйте персональные данные клиентов, секреты инфраструктуры или полные внутренние журналы, не относящиеся к исправлению. Достаточно сведений, которые подтверждают заявленные действия.
Начните документ с короткого описания причины и завершённых изменений, затем приложите подробный реестр. Для каждого URL полезны время проверки, вариант отображения, проверявшийся признак и результат. Исходный список сохраните отдельно от текущей выгрузки: страницы могут добавляться и удаляться во время работы. Тогда другой сотрудник сможет понять, почему в проверке участвовали именно эти адреса, воспроизвести её на том же наборе и отдельно оценить новые публикации.
9. Для ссылочных мер выбирайте отдельное исправление
Пример со скрытым блоком нельзя механически переносить на неестественные входящие или исходящие ссылки. Различайте, где находится проблема и что команда действительно контролирует. Удаление всех ссылок с сайта не является универсальной процедурой пересмотра.
Для платных исходящих размещений Google описывает атрибут sponsored; nofollow также остаётся допустимым способом обозначения. Но сама смена атрибута не исправляет любые проблемы содержания или назначения страницы. Решение должно соответствовать фактическому нарушению и рекомендациям по нему.
Согласно условиям применения disavow, инструмент нужен лишь при значительном числе искусственных или спамных входящих ссылок и наличии либо вероятности соответствующей ручной меры. Google советует сначала попытаться удалить проблемные ссылки; большинству сайтов инструмент не требуется, неправильное применение может навредить.
Поэтому не загружайте туда весь ссылочный отчёт «на всякий случай». Сначала установите основания, сохраните подтверждённые действия и отделите подозрительные размещения от нормальных упоминаний. В запросе описывайте реально выполненные попытки, а не выдуманную переписку или обещанное будущее удаление.
10. Подготовьте честный запрос на пересмотр
Запрос на пересмотр Google должен связывать проблему, исправление и проверенный результат. Подавайте его после устранения всех перечисленных в отчёте нарушений в соответствующем охвате. Короткая структура помогает не потерять главное:
- Как называется мера и какое нарушение обнаружено.
- Как возникла проблема и какие страницы проверены.
- Что изменено в содержимом, шаблонах или процессах.
- Какими проверками подтверждён опубликованный результат.
- Что предотвращает повторное появление причины.
Ниже — учебный фрагмент обращения для описанного магазина. Его нельзя копировать как утверждение о проделанной работе на другом сайте.
«В модуле каталога обнаружили скрытый блок повторяющихся ключевых фраз. Он использовался в шаблонах карточек и категорий. Удалили модуль, проверили ручные поля и выпустили исправление на рабочий сайт. По реестру проверены 600 уникальных URL в двух вариантах отображения; в 1 200 проверках известный блок отсутствует. Дополнительно вручную просмотрены 44 URL из трёх групп. Описание изменения, список проверок и примеры приложены. Возврат модуля исключён из процедуры публикации; назначена проверка шаблонов перед выпуском. Просим пересмотреть указанную меру».
В реальном обращении добавьте проверяемые даты и ссылки на ваши материалы. Не обещайте результат, которого ещё нет, и не называйте предположение установленной причиной. Если происхождение блока неизвестно, так и напишите, отдельно описав найденное нарушение и его устранение.
11. Отправьте обращение и дождитесь решения
Используйте Request Review в отчёте Manual actions. Google сообщает о ходе рассмотрения и просит не отправлять повторный запрос до решения по текущему. Подтверждение получения означает, что обращение принято к рассмотрению; оно не означает снятия меры.
Не обещайте руководителю определённый день ответа или автоматическое восстановление позиций. Срок рассмотрения не находится под контролем команды. Пока запрос рассматривается, поддерживайте исправленный сайт и сохраняйте результаты наблюдений; не возвращайте удалённый механизм ради кратковременной проверки трафика.
Если нарушение сохранилось по решению Google, сопоставьте ответ с прежним охватом и доказательствами. Проверьте пропущенные шаблоны, старые публикации и действительную выдачу после кеширования. Новый запрос должен опираться на дополнительные выполненные исправления, а не на тот же текст с более настойчивой просьбой.
Если команда считает вывод ошибочным, опишите конкретное несоответствие и подтверждающие факты. Не придумывайте признание или несуществующие работы ради убедительности. Цель обращения — дать проверяемую картину сайта и основания для пересмотра.
12. Разделите снятие меры и дальнейшие результаты поиска
После решения проверьте статус в отчёте и сохраните сообщение. Даже снятая мера не является обещанием прежнего трафика: спрос, конкуренция, качество материалов и техническое состояние остаются отдельными факторами. Продолжайте анализ по сопоставимым группам страниц и периодам.
Передайте владельцу сайта актуальный реестр, результаты проверок и правило публикации исправленных шаблонов. Для учебного магазина это проверка каталожного модуля, ручных полей и двух вариантов отображения после существенных изменений. У процесса должен быть ответственный, чтобы удалённая проблема не вернулась вместе со старым шаблоном.
Проверяйте не только отсутствие прежнего нарушения, но и сохранность полезных функций. Удаление блока не должно разрушить навигацию, описание товара или доступность интерфейса. Исправление считается устойчивым, когда команда понимает причину, контролирует её источник и может повторить проверку после очередного выпуска.
Подключите SiteGuard для внешнего контроля HTTP-доступности важных страниц. Устранение нарушений и запрос на пересмотр выполняйте отдельно.