Как проверить, не заблокирован ли сайт от индексации

Представьте: сайт открывается быстро, дизайн аккуратный, тексты написаны, форма заявки работает. Технически всё в порядке. Но заявок нет, трафика нет, а в поиске сайт как будто не существует. Знакомая ситуация?

В девяти случаях из десяти первая мысль владельца бизнеса — «наверное, у нас плохое SEO» или «конкуренты сильнее». Он идёт заказывать продвижение, тратит бюджет на тексты и ссылки, а через месяц с удивлением обнаруживает, что трафик как был нулевым, так и остался. Причина в том, что все эти деньги были потрачены на продвижение сайта, который поисковики физически не могут увидеть — потому что он от них закрыт.

Это одна из самых частых и при этом самых незаметных технических проблем в SEO. Незаметных — потому что сайт при этом выглядит абсолютно рабочим. Она не проявляется визуально, не ломает вёрстку, не выдаёт ошибок посетителю. Пользователь заходит на сайт, всё работает, всё красиво. А поисковый робот в это же самое время натыкается на невидимую стену и разворачивается, даже не заглянув внутрь.

Такая блокировка индексации может возникнуть по десятку причин, и почти всегда — не специально. Чаще всего это следы разработки сайта: программист поставил временный запрет на индексацию, чтобы поисковики не проиндексировали тестовую версию, а после запуска забыл его снять. Или CMS сама выставила флаг «не индексировать» при первой настройке. Или при переезде на новый хостинг что-то пошло не так с правами доступа. Ни один из этих сценариев не связан с качеством контента, дизайна или структуры сайта — а значит, никакое SEO-продвижение эту проблему не решит, пока техническая блокировка не снята.

Хорошая новость: диагностировать это можно самостоятельно, бесплатно и за 15–20 минут, без специальных знаний программирования. В этой статье — пошаговый порядок проверки, которым мы в G-land studio пользуемся на каждом техническом аудите: пять последовательных шагов, конкретные инструменты и чек-лист, который можно пройти прямо сейчас, попутно открывая свой сайт в соседней вкладке.

Почему сайт может быть технически рабочим, но невидимым для поисковиков

Прежде чем переходить к проверке, важно понять логику происходящего. У поисковой системы есть три последовательных этапа работы с любой страницей:

1. Сканирование (краулинг) — робот поисковика заходит на страницу и считывает её содержимое.
2. Индексация — если робот решил, что страница может быть полезна пользователям, она добавляется в базу данных поисковика.
3. Ранжирование — уже проиндексированная страница участвует в конкурсе за место в выдаче по конкретным запросам.

Блокировка индексации — это сбой на первом или втором этапе. Она возникает, когда сайт сам, явно или случайно, говорит поисковику: «сюда не заходи» или «эту страницу не сохраняй в базу». Технических инструментов для такой команды всего четыре:

• файл robots.txt, который запрещает сканирование конкретных разделов или всего сайта целиком;
• мета-тег noindex на самой странице, который запрещает именно индексацию (при этом сканировать страницу роботу не запрещается — сканирует, но не сохраняет);
• HTTP-заголовок X-Robots-Tag с теми же директивами, только не в HTML, а на уровне сервера — встречается реже, но так же эффективно блокирует индексацию;
• канонический тег, который указывает поисковику, что «главная» версия страницы находится по другому адресу — из-за чего текущая страница индексируется не как самостоятельная, а «в пользу» другой.

Все четыре механизма — легитимные и полезные инструменты SEO. Проблема не в них самих, а в том, что их очень легко случайно оставить включёнными после того, как в них отпала необходимость. Собственно, именно поэтому такую блокировку так трудно заметить: сайт визуально ничем не отличается от полностью открытого. Разница видна только тем, кто умеет смотреть глазами поискового робота — а не глазами посетителя.

Дальше — пять шагов, которые эту разницу выявляют.

Шаг 1: проверка robots.txt вручную

Это первое, что стоит проверить, потому что запрет в robots.txt — самая частая и самая «жёсткая» форма блокировки: она закрывает сайт от сканирования целиком, ещё до того, как робот успевает увидеть хоть один мета-тег.

Как проверить: откройте браузер и введите в адресную строку домен сайта с приставкой /robots.txt. Например: www.вашсайт.ru/robots.txt. Файл robots.txt всегда должен находиться строго в корне домена — не в подпапке, не по другому адресу. Если он существует, браузер покажет его содержимое как обычный текстовый файл — никакого специального ПО не нужно, подойдёт любой браузер на компьютере или телефоне.

Что искать. Внутри файла ищите строки, начинающиеся с User-agent: и Disallow:. Директива User-agent определяет, к какому роботу относится следующий за ней блок правил (* означает «ко всем роботам»), а Disallow — что именно запрещено сканировать.

Самая опасная запись, которую нужно научиться замечать с первого взгляда, выглядит так:

User-agent: *
Disallow: /

Это означает: «всем поисковым роботам запрещено сканировать вообще всё на этом сайте», начиная с самой главной страницы. Косая черта / здесь — это корень сайта, и запрет на неё равносилен полной блокировке. Такая строка чаще всего попадает в продакшн-версию сайта случайно — её специально ставят на тестовых и dev-версиях сайта, чтобы поисковики не индексировали черновик, а потом просто забывают убрать при переносе на боевой домен.

Также обратите внимание на частичные блокировки — они опаснее полных, потому что их легче не заметить:

User-agent: *
Disallow: /catalog/
Disallow: /blog/

Здесь сайт в целом доступен, но целые разделы (в данном случае — каталог товаров и блог) закрыты от роботов. Если именно в этих разделах должен расти трафик, а его нет — вот и причина.

Обратите внимание и на директиву Allow — иногда правила комбинируются, и важно понять, какое из них имеет приоритет для конкретной страницы (более специфичное правило, то есть более длинный путь, обычно побеждает).

Бесплатные инструменты для проверки robots.txt:

• Прямой просмотр по адресу /robots.txt — самый быстрый способ, ничего устанавливать не нужно.
• Отчёт «robots.txt» в Google Search Console (раздел «Индексирование» → «robots.txt») — показывает, какую версию файла видел Googlebot в последний раз, когда он её забирал, и есть ли ошибки при обработке.
• Раздел «Инструменты» → «Анализ robots.txt» в Яндекс.Вебмастере — там же можно вставить любой URL страницы вашего сайта и мгновенно узнать, разрешено ли его сканирование по текущим правилам, для роботов Яндекса отдельно.
• Стороннее онлайн-валидаторы вроде robots.txt Tester на seositecheckup.com или sitechecker.pro — полезны, если нужно быстро проверить синтаксис файла без входа в личные кабинеты вебмастер-панелей.

Если запрещающих директив, влияющих на нужные разделы, не найдено — двигаемся дальше. Если нашли — это уже сильный сигнал, но не спешите чинить: сначала пройдите все пять шагов, чтобы увидеть полную картину и не упустить вторую проблему, наложившуюся на первую.

Шаг 2: проверка мета-тега noindex на самой странице

Если robots.txt чист, а сайт всё равно не индексируется, следующая по частоте причина — мета-тег noindex, прописанный прямо в HTML-коде конкретной страницы. В отличие от robots.txt, эта блокировка не мешает роботу зайти на страницу — но прямо запрещает сохранять её в поисковую базу.

Как посмотреть исходный код страницы. Откройте страницу, которую нужно проверить, в браузере. Затем:

• на компьютере — нажмите правой кнопкой мыши в любом месте страницы и выберите «Просмотреть код страницы» (в Chrome, Edge, Yandex Browser) или воспользуйтесь сочетанием клавиш Ctrl+U (Windows) / Cmd+Option+U (Mac);
• откроется новая вкладка с исходным HTML-кодом страницы — тем самым, который браузер получает от сервера ещё до отрисовки.

Что искать. Внутри секции <head> (это самое начало документа, до основного контента) найдите строку вида:

<meta name="robots" content="noindex, nofollow">

или короче:

<meta name="robots" content="noindex">

Присутствие слова noindex в этом теге — прямая команда поисковику не индексировать страницу. Директива nofollow рядом означает, что робот не должен переходить по ссылкам на странице — это отдельная настройка, но она часто идёт в паре с noindex, особенно если тег остался с тестового периода.

Важный нюанс: чтобы быстро найти нужную строку в длинном HTML-коде, используйте поиск по странице — Ctrl+F (Windows) / Cmd+F (Mac) — и введите слово robots или noindex. Это займёт несколько секунд вместо пролистывания сотен строк кода вручную.

Отдельно стоит проверить не только главную страницу, но и 3–5 других ключевых страниц сайта: карточку товара, страницу услуги, страницу блога. Иногда noindex стоит не глобально по шаблону, а точечно — например, движок сайта или плагин SEO мог автоматически проставить его на страницах, которые ещё недавно были черновиками или дублями.

Бесплатные инструменты, которые ускоряют эту проверку:

• Расширение для браузера SEO Meta in 1 Click (доступно для Chrome) — показывает все мета-теги страницы, включая robots, одним кликом, без необходимости лезть в исходный код вручную.
• Расширение Web Developer — позволяет быстро посмотреть заголовки страницы и мета-информацию.
• Проверка через «Инспектирование URL» в Google Search Console — вставляете адрес страницы, и инструмент прямо показывает, разрешена ли индексация, глазами самого Googlebot (это надёжнее, чем смотреть исходный код руками, потому что Google учитывает и HTTP-заголовки, которые в исходном коде браузера не видны).
• Раздел «Проверка страниц» в Яндекс.Вебмастере — аналогичная функция для Яндекса.

Если на нужных страницах noindex не найден — переходим к следующему шагу, где смотрим на ситуацию уже глазами самой поисковой системы.

Шаг 3: проверка через сам Яндекс/Google — оператор site:

Первые два шага показывают потенциальные причины блокировки. Третий шаг отвечает на прямой вопрос: а проиндексирован ли сайт вообще прямо сейчас, по факту?

Как проверить. Откройте Яндекс или Google и введите в поисковую строку:

site:вашсайт.ru

Без пробела после двоеточия, без https://, без www (хотя с www тоже сработает, если домен настроен именно так). Это специальный поисковый оператор, который просит поисковик показать все страницы конкретного сайта, которые есть у него в индексе.

Что означают результаты:

• Если в выдаче появляется список страниц вашего сайта с заголовками и сниппетами — сайт как минимум частично проиндексирован. Дальше стоит прикинуть, сколько страниц показано, и сравнить с реальным количеством страниц на сайте: если из 200 страниц каталога в индексе всего 12 — это тоже сигнал проблемы, просто не полной, а частичной блокировки (возможно, дублей, возможно, тех же точечных noindex).
• Если поиск не находит ничего и показывает «по вашему запросу ничего не найдено» — это значит, что на данный момент в базе поисковика нет ни одной страницы этого сайта. Это либо полная блокировка (см. шаг 1), либо сайт настолько новый, что робот попросту ещё не успел его обойти, либо ранее сайт был исключён из индекса за нарушения (это отдельная, более редкая история, требующая проверки на санкции).

Важная оговорка: оператор site: — это диагностика по факту, а не по причине. Он говорит «есть страницы в индексе» или «нет», но не объясняет, почему. Поэтому его стоит использовать в связке с шагами 1 и 2, а не вместо них: если site: показывает пустоту, а в robots.txt и мета-тегах блокировки не нашли — это повод присмотреться к возрасту домена, истории санкций или проблемам с доступностью сервера для роботов (об этом — в разделе про частые причины ниже).

Полезный вариант проверки: попробуйте site:вашсайт.ru/раздел/, чтобы посмотреть, проиндексирован ли конкретный раздел, если предполагаете, что заблокирован не весь сайт, а его часть. Также полезно ввести в поиск точный заголовок главной страницы или уникальную фразу с неё в кавычках — если сайт вообще не появляется даже по такому точному запросу, это подтверждает отсутствие индексации.

Этот шаг не требует никаких инструментов, кроме самого поисковика, и занимает буквально 30 секунд — поэтому часто с него начинают, а не заканчивают проверку. Но для полной картины важно дойти и до следующего шага, потому что именно там видна не просто сумма «в индексе / не в индексе», а детальная разбивка по каждой странице и точная причина её статуса.

Шаг 4: проверка через Яндекс.Вебмастер и Google Search Console

Это самый информативный шаг из всех пяти, и если из статьи стоит запомнить один инструмент — то именно этот. Панели Яндекс.Вебмастер и Google Search Console — официальные бесплатные сервисы от самих поисковых систем, которые показывают не предположения, а точные данные о том, что робот видел на сайте и что он с этим сделал.

Если сайт ещё не подключён к этим сервисам, это первое, что нужно сделать — регистрация бесплатна и занимает 10–15 минут (нужно подтвердить владение сайтом одним из способов: через мета-тег, DNS-запись или файл на сервере). Без этого шага дальнейшая диагностика будет неполной, а в будущем без подключённых панелей невозможно будет отслеживать, как сайт индексируется и ранжируется в динамике.

Google Search Console → раздел «Индексирование» → «Страницы». Здесь Google показывает список причин, по которым страницы сайта не попали в индекс, с разбивкой по количеству страниц на каждую причину. Основные статусы, которые встречаются чаще всего:

• «Страница является копией. Канонический вариант не выбран пользователем» или «Google выбрал другой канонический вариант, отличный от указанного пользователем» — про это подробно поговорим в шаге 5, признак проблем с каноническими тегами.
• «Обнаружена, но пока не проиндексирована» — Google знает о существовании страницы (например, увидел ссылку на неё), но ещё не зашёл, чтобы её просканировать. Обычно это вопрос времени и краулингового бюджета, но если таких страниц накопились сотни, а сайт при этом не очень большой, — это может говорить о проблемах со скоростью загрузки или качеством контента, которые Google счёл менее приоритетными для сканирования.
• «Просканирована, но пока не проиндексирована» — более тревожный статус: робот зашёл на страницу, прочитал её, но решил не добавлять в индекс. Чаще всего причина — низкое воспринимаемое качество или дублирование контента с другими страницами.
• «Страница исключена тегом noindex» — прямое подтверждение того, что искали на шаге 2, но уже подтверждённое глазами самого Google, а не через ручной просмотр кода.
• «Заблокировано в файле robots.txt» — аналогичное прямое подтверждение шага 1.
• «Не найдено (404)» — страница, на которую Google переходил, но получил ответ сервера «страница не существует»; часто встречается после переезда сайта или смены структуры URL без настройки редиректов.
• «Страница с переадресацией» — URL просто перенаправляет на другой адрес, поэтому сама по себе страница не индексируется — это нормально для редиректов, но стоит проверить, что перенаправляет именно туда, куда нужно.

Каждый статус в отчёте кликабелен — можно раскрыть список конкретных URL с этим статусом и посмотреть, какие именно страницы попали в проблемную категорию.

Яндекс.Вебмастер → раздел «Индексирование» → «Страницы в поиске» и соседний раздел «Исключённые страницы». Логика похожая: Яндекс отдельно показывает страницы, которые находятся в поиске, и отдельно — исключённые из него, с указанием причины исключения. Частые формулировки: «Запрещено в файле robots.txt», «Установлен запрет в мета-тегах», «Дубль страницы, исключённой по каноническому url», «Страница не найдена (404)», «Изменилось содержимое, документ исключён».

Отдельно в Яндекс.Вебмастере полезен раздел «Диагностика сайта» на главной странице кабинета — он суммирует все критические проблемы одним списком с приоритетом, в том числе может напрямую указать на блокировку в robots.txt как на главную проблему сайта.

Если оба сервиса показывают, что подавляющее большинство страниц имеет здоровый статус «проиндексировано» — блокировки, скорее всего, нет, и низкий трафик связан уже с другими факторами SEO (конкуренция в выдаче, качество текстов, ссылочный профиль). Если же значительная доля страниц находится в исключённых — переходите к шагу 5 и разделу с частыми причинами, чтобы точно определить, что чинить в первую очередь.

Шаг 5: проверка канонических тегов

Последний по порядку, но не по важности шаг — потому что каноническая блокировка (в отличие от robots.txt и noindex) выглядит внешне почти незаметно даже для самого владельца сайта: страница физически существует, открывается, и в её коде нет прямого запрета на индексацию. Проблема в другом — сайт сам говорит поисковику, что эта страница не главная, а «зеркало» другой.

Что такое канонический тег. Это строка в исходном коде страницы вида:

<link rel="canonical" href="https://вашсайт.ru/pravilnyj-adres/">

Она сообщает поисковику: «если ты видишь несколько похожих или одинаковых страниц, считай главной именно вот эту, указанную в href». Это полезный и правильный инструмент, когда на сайте действительно есть дубли (например, одна и та же карточка товара доступна по нескольким URL из-за фильтров или UTM-меток) — тогда канонический тег помогает поисковику не размывать позиции между копиями.

Проблема возникает, когда канонический тег указывает не на саму себя, а на другой, посторонний адрес — и делает это ошибочно. Типичный сценарий: при разработке сайта верстальщик или CMS автоматически проставили всем страницам канонический адрес, ведущий на главную страницу или на тестовый домен, и забыли поправить его для боевой версии. В результате поисковик видит: «страница /uslugi/remont-kryshi/ говорит, что её канонической версией является https://вашсайт.ru/» — и вместо того, чтобы индексировать страницу услуги отдельно, «сливает» её значимость в пользу главной. Формально страница может даже не носить noindex и не блокироваться в robots.txt, но конкурировать в поиске сама по себе она уже не будет.

Как проверить. Два способа:

1. Тем же способом, что и в шаге 2 — откройте исходный код страницы (Ctrl+U), найдите через поиск по странице (Ctrl+F) слово canonical в секции <head>, и посмотрите, куда именно ведёт адрес в атрибуте href. Он должен указывать на саму эту страницу (с точностью до https:// или http://, наличия www и завершающего слэша — расхождения в этих деталях тоже иногда создают путаницу, хотя обычно не критичную).
2. Через «Инспектирование URL» в Google Search Console — инструмент прямо показывает раздел «Индексирование страницы», где написано, какой канонический URL указан пользователем и какой канонический URL выбрал сам Google. Если два значения расходятся — это явный признак проблемы: Google явно проигнорировал указание сайта, потому что счёл его ошибочным или нашёл более подходящую версию.
3. В Яндекс.Вебмастере аналогичную информацию можно увидеть в разделе «Проверка страниц» — там тоже указывается, какой канонический адрес система приняла как основной.

Проверьте таким образом 3–5 ключевых страниц: главную, пару карточек товаров или услуг, страницу блога. Если на всех них канонический тег указывает сам на себя — проблемы нет. Если на нескольких страницах он ведёт на посторонний адрес — вот и найдена причина, по которой эти страницы не растут в поиске при внешне полном порядке.

Частые причины случайной блокировки

Собрав данные всех пяти шагов, полезно понимать общую картину: почти во всех случаях блокировка — не злой умысел и не чья-то небрежность, а побочный эффект нормального процесса разработки сайта. Вот три сценария, которые встречаются чаще всего:

Забытый Disallow: / после разработки. Практически любая нормальная студия или разработчик закрывает тестовую версию сайта от индексации — это правильная практика, чтобы поисковики не проиндексировали черновик с водой вместо текста и заглушками вместо изображений. Проблема возникает на этапе переноса сайта с тестового домена на боевой: если файл robots.txt копируется вместе со всем остальным содержимым сайта «как есть», без проверки, полный запрет на индексацию переезжает вместе с сайтом на продакшн — и там благополучно остаётся незамеченным, потому что визуально ничего не меняется.

Случайно оставленный флаг noindex после тестового запуска. Та же логика, но на уровне отдельных страниц или CMS-настроек. Многие движки сайтов и конструкторы (включая популярные в Рунете платформы) имеют общесайтовую галочку в духе «Скрыть сайт от поисковых систем» или «Режим разработки», которую включают на старте работ и забывают выключить после публикации. В некоторых случаях этот флаг выставляется автоматически при создании нового сайта на хостинге — как защита по умолчанию, о существовании которой владелец сайта может даже не знать.

Проблема с правами доступа для поисковых роботов. Менее очевидная, но тоже встречающаяся причина: сервер или CDN настроены так, что блокируют запросы по User-Agent или IP-адресам, из-за чего краулеры Яндекса или Google физически не могут получить доступ к страницам — сервер отвечает им ошибкой или вовсе не отвечает, хотя обычным посетителям сайт открывается без проблем. Такое случается при неправильной настройке защиты от ботов, файрвола или правил на уровне .htaccess — система защиты, рассчитанная на блокировку вредоносных ботов, по ошибке причисляет к ним и легитимных поисковых роботов.

Знание этих трёх сценариев не заменяет проверку по пяти шагам выше, но помогает понимать, где искать в первую очередь, если время ограничено.

Что делать, если обнаружили блокировку

Хорошая новость в конце: снять техническую блокировку индексации почти всегда быстро и просто, если знать, что именно чинить.

Если проблема в robots.txt — нужно отредактировать файл, убрав строку Disallow: / (или конкретные строки, блокирующие нужные разделы), и загрузить обновлённую версию файла в корень сайта тем же способом, каким изначально размещался сайт (через хостинг-панель, FTP или админку CMS — зависит от платформы). После обновления стоит проверить файл ещё раз тем же способом, что и в шаге 1, чтобы убедиться, что изменения применились.

Если проблема в мета-теге noindex — нужно найти, где именно в коде сайта или в настройках CMS прописывается этот тег (в шаблоне страницы, в SEO-плагине, в общей настройке движка), и убрать директиву noindex, заменив её на index, follow либо удалив тег полностью (по умолчанию отсутствие тега robots равносильно разрешению индексации).

Если проблема в каноническом теге — потребуется поправить логику генерации этого тега так, чтобы каждая страница по умолчанию указывала сама на себя, если только не существует реального дубля, который действительно нужно объединить с другой страницей.

После любого из этих исправлений имеет смысл вручную инициировать повторное сканирование через «Инспектирование URL» → «Запросить индексирование» в Google Search Console и через раздел «Переобход страниц» в Яндекс.Вебмастере — это не гарантирует мгновенного результата, но ускоряет момент, когда робот заново посетит сайт.

Сколько времени занимает восстановление видимости. Здесь нужно реалистично разделить два разных процесса: снятие блокировки — дело нескольких минут, а восстановление видимости в поиске — процесс с иной динамикой. Обычно первые признаки того, что робот заметил изменения (страницы начинают появляться в панелях как проиндексированные), видны в течение нескольких дней — от 3–4 дней до двух недель, в зависимости от того, насколько часто поисковик обычно посещает конкретный сайт. Полное восстановление позиций в выдаче — отдельный вопрос: если сайт был заблокирован долго (месяцы), поисковику нужно время не просто заново проиндексировать страницы, но и заново накопить сигналы доверия и релевантности, из-за которых сайт постепенно поднимается в выдаче, а не появляется сразу на прежних позициях. На практике это может занимать от нескольких недель до пары месяцев — но именно после снятия блокировки этот процесс наконец начинает идти, а не стоит на месте, как это было раньше.

Пошаговый чек-лист проверки индексации

Чтобы не держать всю логику статьи в голове, вот воспроизводимая последовательность действий — можно проходить её прямо сейчас, шаг за шагом, открывая свой сайт в соседней вкладке:

1. Открыть вашсайт.ru/robots.txt напрямую в браузере. Проверить, нет ли строки Disallow: / для User-agent: *, а также убедиться, что не заблокированы нужные разделы. Дополнительно проверить через отчёт «robots.txt» в Google Search Console и «Анализ robots.txt» в Яндекс.Вебмастере.
2. Открыть исходный код главной и 3–5 ключевых страниц (Ctrl+U), найти по Ctrl+F слово noindex в секции <head>. Для ускорения — установить расширение SEO Meta in 1 Click.
3. Ввести site:вашсайт.ru в Яндекс и Google. Сравнить количество найденных страниц с реальным количеством страниц на сайте.
4. Зайти в Google Search Console → «Индексирование» → «Страницы» и в Яндекс.Вебмастер → «Индексирование» → «Исключённые страницы». Изучить статусы и количество страниц по каждой причине.
5. Проверить канонические теги на ключевых страницах — через исходный код (слово canonical) или через «Инспектирование URL» в Search Console, сравнив «канонический URL, указанный пользователем» и «канонический URL, выбранный Google».
6. Если найдена блокировка — исправить соответствующий пункт (robots.txt, meta-тег или canonical), запросить повторное индексирование через панели вебмастеров и наблюдать за статусами в течение 1–2 недель.

Пятнадцать минут по этому списку — и вы точно знаете, есть ли у сайта техническая блокировка индексации, или дело в чём-то другом.

Бесплатная техническая проверка индексации от G-land

Если пройти все пять шагов самостоятельно нет времени, или результаты проверки оказались неоднозначными — свяжитесь с нами в Telegram @gland_studio. Мы бесплатно проверим ваш сайт на блокировку индексации: robots.txt, мета-теги noindex, канонические теги и статусы страниц в Яндекс.Вебмастере и Google Search Console — и пришлём конкретный список того, что мешает сайту быть видимым в поиске, вместе с оценкой, сколько времени займёт восстановление.