Просто сотрите строчки, которые вы вставили «на всякий случай». Да, те самые, с «Disallow: /cgi-bin/» и прочим мусором из нулевых. Ничего, что раньше это работало. Сейчас – мешает. Проверено на одном проекте: 200+ строк, из которых реально работали… две. Остальное – музей SEO-иллюзий.
И знаете что? Мы удалили всё, кроме нужных двух. Результат – страница «Поиск» наконец исчезла из выдачи (где ей не место), а скорость индексации выросла в два раза. Просто потому что стало понятно, что мы хотим.
Не доверяйте старым гайдам. Они врут.
Серьёзно, вы когда последний раз открывали старую статью на Stack Overflow про конфиг для поисковиков? Там половина примеров – просто вред. Особенно вот это: «User-agent: * Disallow: /» – звучит круто, но убивает всё живое.
В одном проекте так «запретили» целиком раздел с новостями, который должен был качать трафик. Всё потому, что кто-то скопировал конфиг из блога пятилетней давности. Не повторяйте.
Хотите по-умному? – Начните с чистого листа
Оставьте только то, что реально нужно спрятать. Например:
- /admin/ – ну очевидно.
- /cart/ – никто не должен индексировать корзину.
- /search?q= – пагинация и дубли, до свидания.
Всё. Остальное – только по факту. Не надо писать директивы ради директив. Это не вуду.
А что с новыми правилами? Ну, там есть нюанс…
Если раньше можно было расслабиться и просто задать пару правил – сейчас это стало похоже на настройку сложного маршрута в навигаторе, где каждая запятая может отправить вас в Саранск вместо Парижа. Ну, вы поняли.
С новыми требованиями проверяющие стали… дотошнее, что ли. Один лишний пробел – и всё летит к чертям. У нас был случай – разработчик вставил таб вместо пробела. Ничего не работало. Три дня искали, в чём косяк. И да, это был таб. Спасибо, конечно.
Короткий чеклист от уставшего практика:
- Забудьте про директивы, которые вы не понимаете.
- Пишите вручную. Не копируйте из форумов.
- Проверяйте руками – хотя бы curl или Live Test в консоли.
- Не доверяйте «генераторам конфигов». Это не Excel.
Самое важное – не бояться вычеркнуть лишнее. Мы не в школе, здесь за минимализм ставят пятёрку. А за попытку казаться умным – бан в индексе.
А если вы не уверены – просто спросите у кого-то, кто уже обжигался
…вроде нас. Мы в dvmagic.eu как-то случайно сделали так, что поисковик видел только логотип. Да-да, один логотип, и всё. Зато какой CTR! Ну, по крайней мере, один день.
Какие директивы больше не работают – не трать на них время
Не используйте больше noindex – вообще. Просто забудьте.
Серьёзно. Больше не работает. Раньше это было как волшебная палочка: прописал в файле, и страница исчезала из выдачи. А теперь? Пиши, не пиши – результат один. Как если бы ты орал в пустоту: «не показывай это!», а в ответ только эхо. Так что если хочешь убрать что-то из индекса – делай это через мета-тег в самом HTML или настрой правила на сервере. Всё. Файл больше не помогает тут.
Честно говоря, crawl-delay – как сигнальная лента без охраны
Ты, может, и поставил ограничение: «Эй, не спеши, давай ползай помедленнее». Но знаешь, что? Никто уже не слушает. Этот параметр просто проигнорирован. Если раньше роботы хоть как-то старались держаться в рамках, то теперь – как подростки на скейтах в торговом центре: их не остановить. Хотите управлять скоростью обхода? Используйте специальные инструменты в консоли. А не эту якобы директиву, которая теперь больше похожа на постер с надписью «Не сорить».
И ещё один ушёл в архив: noarchive
Помнишь это чувство, когда хотелось спрятать кеш? Типа: «не надо сохранять копию моей страницы, она у меня как freshly baked pizza – ешь сразу или не ешь вообще». Ну вот, теперь такой подход не сработает. Если хочешь отключить отображение кешированной версии – делай это в заголовках ответа или мета-информации. Прописать это в конфигурации больше не помогает.
Мифы про nofollow в файле – всё, завязываем
Это была странная история с самого начала. Указывать, что ссылки не должны передавать вес – в конфиге сайта, а не в самой ссылке? 🤷 Да, раньше это как-то учитывалось. Сейчас – нет. Вообще. Хотите контролировать передачу веса – пользуйтесь rel="nofollow" в самих ссылках. Конфигурация тут уже бессильна. Просто не трать на это ни времени, ни байтов.
Сказ о disallow: * в никуда
О, этот момент, когда ты хочешь вообще всё закрыть. Типа: «не трогай, уходи, я не готов». И раньше это работало. Но теперь – если ты так сделаешь, скорее всего, просто накосячишь. Потому что робот всё равно полезет за фавиконкой, манифестом, иконками, стилями. Закрыть всё – больше не значит закрыть всё. И это важно. Надо быть конкретным. Указать явно, что именно скрываешь. Либо проставить ограничения на уровне сервера. Маска типа «всё запрещено» теперь как выключатель в пустой комнате.
Реальный кейс – да, с болью
Один клиент – у него сайт на самописной CMS, старый как GameBoy, но с миллионом страниц. Он в 2024-м включил в конфиг crawl-delay: 10, noindex: /blog/ и прочие «антистресс-фичи». Что в итоге? Страницы индексируются. Сервер страдает от перегрузки. А он в недоумении: «Вроде всё правильно прописал…» Ну, да, прописал. Только в пустоту. Потратил неделю – всё пришлось переделывать с нуля, уже по-новому.
Так что делай проще
- Хочешь скрыть от поиска – убирай через мета-теги и заголовки.
- Нужно ограничить нагрузку – используй консоль, не конфиг.
- Не полагайся на старые приёмы – они теперь как floppy-диски.
Мир поменялся. И вот этот файл – он теперь не командный центр. Он больше как записка на холодильнике. Можно написать «не ешь моё», но кто-то всё равно съест. Так что перестрой подход. И да, не забудь проверить, что там вообще у тебя внутри этого файла – потому что некоторые команды уже работают как кнопки на пульте без батареек.
Как изменился порядок обработки новых User-agent и их приоритет
Сначала – просто вычеркни всё, что знал раньше
Серьёзно. Забудь старую логику: сначала Chrome, потом ЯндексБот, потом что-то непонятное с буквой “B” в названии. Сейчас не так. Появилась новая фишка – приоритет теперь не по алфавиту и не по “больше всего совпадений”, а по… короче, сейчас расскажу.
Теперь всё крутится вокруг специфики
Если раньше какой-нибудь “*” собирал всё, что не вписалось в конкретику, то теперь приоритет отдали самым специфичным правилам. То есть, если у тебя есть User-agent: MegaScraperBot/2.0 и ты там его заблокировал, а внизу у тебя User-agent: * с разрешениями, то он больше не увильнёт – получит по заслугам. Его жёстко режет его личный блок, и ему не помогут общие поблажки. Всё, как с родителями: если мама сказала “нельзя”, папа уже не спасёт, даже если разрешил раньше.
Пример из жизни: реальный сайт на WP
У клиента был плагин для AMP-страниц, и его сканировал кастомный бот от какого-то агрегатора. Так вот, раньше настройки прокатывали – его блокировали через *. Теперь пришлось вручную прописывать его агента, иначе лез как к себе домой. По итогу: одна строка кода сработала лучше, чем полдня танцев с htaccess.
Иерархия теперь не плоская
Я, честно, сначала подумал – ошибка. Как это: если у тебя есть User-agent: Googlebot-News и User-agent: Googlebot, то первый будет рулить, даже если во втором больше инструкций? Но да – теперь каждая ветка обрабатывается обособленно, и победит та, которая точнее описывает бота. Сравни: точный адрес выигрывает у просто “улицы”.
- Было: “А, подходит под общую группу – запускай”.
- Стало: “Нет, у него свой профиль – смотри в глаза и решай строго по нему”.
Что это значит для тебя
Хочешь – игнорь. Но если в журнале увидишь, что какой-то левый агент скачал 20 гигов картинок – не ной. Просто ты его не блокнул лично, а надеялся на “звёздочку”. Так вот, забудь про звёздочки. Это не RPG, здесь не прокачиваешь общие правила. Здесь побеждает конкретика.
Совет по хардкору
Делай список агентов, которые реально лазают по сайту. Не по слухам, а по логам. Потом проверяй их по одному: нужен – оставляй, вреден – прописывай индивидуальный блок. Только не пиши общие правила в надежде, что “и так сработает”. Уже не сработает. Всё – эпоха халявы закончилась.
Немного боли напоследок
Я однажды дал волю – оставил User-agent: * открытым, потому что устал прописывать всё по одному. Через неделю клиент прислал письмо: “Почему наш PDF-каталог с новыми ценами проиндексирован каким-то PriceCrawler?” И знаете что? Его бот был явно прописан в отдельной строке – просто я поленился. Теперь не ленюсь. Лучше потратить 10 минут, чем потом объяснять, почему партнёры ушли к конкуренту.
Что случилось с правилами обработки JavaScript – и почему всем теперь не по себе
Сразу к сути: нельзя просто так взять и скрыть JS-директорию
Если коротко: запрет на `Disallow: /js/` – это теперь не защита, а подножка себе же. Серьёзно. Всё, что грузит интерфейс, события, логику – если это в JavaScript и закрыто, считай, ты прячешь от поисковика половину сайта. А иногда и больше.
Помнишь старые приколы, типа: «закроем папку /scripts/ – будет чище, быстрее, безопаснее»? Забудь. Теперь это как выключить свет и удивляться, почему никто не замечает, какой у тебя ремонт крутой. А ведь ты потратился. Трекинг, динамика, фильтры, подгрузка карточек – если они дергаются скриптами, а ты не дал роботу туда пройти, он увидит ровно… ничего.
Я сломал один SPA и чуть не потерял весь трафик
У нас был проект. Одностраничник, сделанный на Vue, вроде всё красиво. Плавные переходы, фильтры по категориям, сортировка по цене – конфетка. Но вот беда: прятали `src/` и `assets/js/` – типа, зачем это кому-то видеть, там же куча служебного. Ну и что ты думаешь? Боты видели только заглушку, причём даже без контента. Ни ссылок, ни структуры, просто заголовок и один `
Нам тогда повезло: быстро поняли, что не так, дали доступ к ключевым путям, включая API-эндпоинты и сборку скриптов. Индексация пошла как по маслу. Ну, почти. Пришлось подождать, но оно того стоило.
Проверь, не душишь ли себя сам
- Открой Search Console и проверь рендеринг страниц – видит ли он то же, что и ты?
- Не закрывай папки типа `/build/`, `/dist/`, `/static/js/`, если в них реально живут твои шаблоны и логика
- Проверь, не попадает ли `*.js` под маску `Disallow: /*.js$` – такое тоже бывает, особенно у параноиков из безопасности
- Да, и не забывай про прелоадинг: иногда сами скрипты грузятся через отложенную логику – а роботу-то ждать некогда
А если хочется что-то спрятать?
Ну вот прям кровь из носу не хочешь пускать сканер в `/admin.js` или `/analytics.js`? Ладно, можно. Только не через блокировку всех скриптов. Лучше выноси «секретное» в отдельный namespace и блокируй его точечно. Или хотя бы используй `` в самом HTML, если реально надо ограничить что-то локально. Грубая блокировка папки – это как вырубить интернет, чтобы никто не читал твои твиты. Работает, но тебе же хуже.
Пример? Вот тебе: eCommerce-каталог без доступа к /vue-runtime.js
Реальный кейс. У клиента – SPA на Nuxt. Грузит всё через client-side. Пользователь кликает – страница оживает. Робот? Робот не кликает. Он смотрит в пустоту. Сканирует страницу, а там – чисто белый экран. `vue-runtime.js` был под запретом. Ну ты понял. После правки – рост видимости на 160% за два апдейта карты. Магия? Нет, просто дали ему то, что он просил с самого начала.
Честно, у меня нет для тебя идеального рецепта. У всех проекты разные. Но вот что я скажу: если ты используешь динамику, а поисковик не может дотянуться до файлов, которые её оживляют – это всё равно, что шептать в вакууме. Он тебя не услышит. А значит, и никто другой тоже. Всё. Думай.
Как адаптировать правила индексации под запросы Googlebot Smartphone
Сначала – запрети всё ненужное. Без сожалений
Вот прям без сантиментов. Мобильный бот не будет церемониться. Если у тебя в структуре сайта остались какие-то архивы времён динозавров – старые JS-библиотеки, стилевые эксперименты из 2012 года, папки /temp/ или /beta/, – вычеркивай. Жёстко:
User-agent: Googlebot
Disallow: /temp/
Disallow: /old-styles/
Disallow: /private-sandbox/И не забудь: он теперь не просто смотрит, он *видит*, как твой сайт выглядит на телефоне. Если покажешь кашу из устаревших файлов – получишь крошку рейтинга. Это как пытаться пустить в Инсту сторис с фронтальной камеры Nokia 3310.
CSS и JS теперь как хлеб и масло. Запретишь – будешь голодать
Да, раньше можно было схитрить: «А вот этот кусочек стиля я спрячу от глаз бота, пусть люди видят». Сейчас это не прокатит. Мобильный сканер требует открытого доступа ко всем визуальным элементам. Прям как тот человек, который «хочет понимать, как всё работает изнутри».
User-agent: Googlebot
Allow: /css/
Allow: /js/Не открываешь – не жалуйся потом, что превью страниц в поиске выглядят как мем из «Ты это видел?». Ну, ты понял.
Не усложняй – короткие пути рулют
Если путь до важного контента как квест в трёх измерениях, Googlebot Smartphone просто скажет: «До свидания». Он не будет карабкаться по вложенным папкам, как Индиана Джонс в поисках смысла.
- Структура URL – максимально плоская;
- Файлы – на видных местах;
- Мобильный CSS не должен лежать в подвале архива.
Я реально видел, как сайт слетал из выдачи просто потому, что ключевой файл лежал в /assets/mob/ver2/css/v3/. Никаких v3. Ты что, API делаешь?
А теперь немного безумия: что, если всё наоборот?
Вот кейс. Клиент оставил открытым /dev/, думая, что там ничего важного. А там – старая версия лендинга, оптимизированная под мобилки, которую бот и съел с радостью. В итоге она и попала в индекс. Вместо нового главного. Да, ты понял. Googlebot бывает наивен. Или просто любит олдскул.
Поэтому нет, не надейся, что он сам разберётся, что главнее. Укажи явно:
Disallow: /dev/
Disallow: /backup/
Disallow: /drafts/Ах да, про подсказки
Я однажды столкнулся с тем, что клиент не мог нормально описать, чего он вообще хочет от поведения индексации. Он говорил: «Пусть гугл сам решит». Ну, удачи. Сначала подумай сам. А потом уже – вот тебе штука, которая поможет сформулировать запросы внятно. Да-да, там про промпты, но работает и здесь. Не веришь – попробуй.
Если кратко, но без морали
Мобильный сканер сейчас как придирчивый UX-дизайнер: не просто смотрит, а комментирует каждый косяк. И не скрыться, не отбиться от него. Лучше подружись: покажи нужное, спрячь мусор и не усложняй. Прямо как на первом свидании. Только тут вместо поцелуя – место в топе.
