У меня сайт с тысячами товаров. Менять URL — это же кошмар на несколько месяцев! Оно того стоит?

Стоит. Но подходить нужно как к проекту, а не к разовой задаче. Разбейте работу на этапы: 1. Начните с нового. Для всех новых товаров и категорий сразу настраивайте правильные ЧПУ. 2. Постепенная миграция. Выделите самые трафиковые и важные страницы (категории, топ-товары) и переведите их в первую очередь. Это даст максимальный эффект. 3. Автоматизация. Для массовой смены URL в интернет-магазинах часто можно написать скрипт или использовать специальные модули/плагины. Это не ручная работа. Эффект вы получите значительный: рост трафика, улучшение поведенческих факторов и, как следствие, рост позиций.

Поисковики уже много лет индексируют сайты с динамическими URL. Они научились их понимать. Зачем мне это?

Да, научились. Но это не отменяет преимуществ ЧПУ. Каждое слово в ЧПУ — это дополнительный, пусть и не основной, сигнал для поисковика о содержании страницы. Понятный URL повышает доверие пользователя, увеличивает CTR в выдаче и снижает отказы, что напрямую влияет на поведенческие факторы и ранжирование. URL часто отображается в поисковой выдаче, и красивый URL банально дает больше кликов. ЧПУ — это не про то, без чего нельзя обойтись. Это про то, что дает вам конкурентное преимущество.

А если я хочу изменить URL уже проиндексированной страницы, которая хорошо ранжируется? Не потеряю ли я позиции?

При правильной настройке 301-го редиректа вы не потеряете вес и позиции. Но есть нюансы: позиции могут временно (на 1-4 недели) просесть. Поисковикам нужно время, чтобы переобработать страницу по новому адресу. После стабилизации вы не только вернетесь на старые позиции, но и можете их улучшить за счет более качественного URL. Главное — редирект должен быть настроен КОРРЕКТНО и вести на релевантную страницу.

Нужно ли включать в URL дату публикации для новостей и статей блога?

Нет, в большинстве случаев не нужно. URL с датой (например, /blog/2023/11/15/nazvanie-stati) устаревает. Через год пользователь может не кликнуть на такую статью, посчитав ее неактуальной. Лучше использовать вечный URL: /blog/nazvanie-stati. Актуальность можно показать датой на самой странице. Это обеспечивает долгосрочную релевантность страницы и не создает психологических барьеров для кликов в будущем.

Что лучше: транслитерация или перевод в URL?

Я рекомендую перевод на английский для международных проектов и транслитерацию для локальных. Перевод (например, site.com/best-smartphones) лучше для глобального понимания пользователями по всему миру. Транслитерация (например, site.ru/luchshie-smartfony) хуже для международных систем, но привычнее для русскоязычного пользователя. Для российского рынка допустима и транслитерация, но ключевые слова в ней должны быть понятны и соответствовать популярным поисковым запросам.

Как бороться с дублями страниц с /index.html или index.php в конце?

Эти страницы — классические дубли главной. Настройте 301-й редирект с site.ru/index.html на site.ru/. Проблема решается на уровне сервера (файл .htaccess для Apache) или в настройках CMS. Важно обеспечить каноничность и передачу веса на основную страницу. Это предотвращает распыление SEO-веса и улучшает индексацию сайта.

Какой максимальной длины должен быть URL для SEO?

Идеальная длина URL — до 50-60 символов. URL длиной более 100 символов может быть обрезан в поисковой выдаче, что ухудшает читаемость и CTR. Принцип «чем короче, тем лучше» работает, но не в ущерб информативности. URL должен содержать ключевые слова, но быть лаконичным. Избегайте длинных цепочек слов и стоп-слов, которые не несут смысловой нагрузки.

Можно ли использовать заглавные буквы в URL?

Технически можно, но не рекомендуется. Поисковые системы обычно воспринимают заглавные и строчные буквы в URL как разные адреса, что может создавать дубли контента. Это также нарушает единообразие и может вызывать проблемы при копировании ссылок пользователями. Лучше использовать только строчные буквы латинского алфавита. Это стандартная практика, которая предотвращает множество технических проблем.

Как правильно настроить редирект со старого URL на новый?

Используйте 301 редирект (постоянное перенаправление), который сообщает поисковым системам, что страница переехала навсегда и передает более 90% SEO-веса. Для WordPress используйте плагины Redirection или Rank Math. Для Битрикса настройка через urlrewrite.php или .htaccess. Для серверной настройки используйте директивы в .htaccess для Apache или конфигурацию Nginx. Важно: каждый старый URL должен вести на релевантный новый URL, а не на главную страницу.

Что делать, если CMS автоматически генерирует плохие URL?

Большинство современных CMS позволяют настраивать структуру URL. В WordPress: Настройки → Постоянные ссылки → выбрать «Название записи». В 1С-Битрикс: включить ЧПУ в настройках и настроить шаблоны URL для компонентов. В Tilda возможности ограничены — можно вручную редактировать slug для каждой страницы. Если CMS не предоставляет нужных возможностей, рассмотрите использование плагинов или обращение к разработчику для кастомизации. Иногда проще сменить CMS, чем бороться с ее ограничениями.

Direct Result

Как настройка robots.txt и .htaccess закрывает "мусор" от индексации и убирает дубли без вреда для SEO

Автор: Роман Межевов, практикующий SEO-специалист с многолетним опытом

Давай начистоту. Когда я только начинал, файлы `robots.txt` и `.htaccess` казались мне какой-то магией высшего пилота. Одна ошибка — и сайт вылетит из индекса. Правда в том, что эти файлы — твои лучшие союзники в борьбе с мусором в индексе. А этот мусор (дубли страниц, служебные скрипты, админки) размывает вес и мешает ранжироваться главным страницам.

Содержание статьи

1
Robots.txt и .htaccess: кто за что отвечает?
2
Robots.txt: инструкция для роботов. Закрываем "технический мусор"
3
.htaccess: силовой инструмент сервера. Решаем проблемы дублей
4
Опасные ошибки: что закрывать категорически нельзя
5
Проверка и отладка: как убедиться, что всё работает
6
FAQ и возражения: ответы на частые вопросы

1. Robots.txt и .htaccess: кто за что отвечает?

Представь, что твой сайт — это офис.

`Robots.txt`

Это табличка на двери с инструкциями для почтальонов (поисковых роботов): «Заходите, но в эту комнату (админку) не заглядывайте, эти документы (логи) я сам разберу».

Статус: Просьба (робот может проигнорировать)

Место: Корень сайта: https://вашсайт.ru/robots.txt

`.htaccess`

Это внутренняя система безопасности офиса. Она физически не пускает кого-либо в определённые помещения или автоматически перенаправляет всех из маленькой тёмной комнаты (дубля) в главный светлый зал (каноничную страницу).

Статус: Закон для сервера (выполняется беспрекословно)

Место: Корень сайта: https://вашсайт.ru/.htaccess

Главное отличие: robots.txt — это просьба, которую робот может проигнорировать (и некоторые так и делают). .htaccess — это закон для сервера, который выполняется беспрекословно. Для надежной защиты используем оба файла в связке.

2. Robots.txt: инструкция для роботов. Закрываем "технический мусор"

Файл лежит в корне сайта: https://вашсайт.ru/robots.txt

Вот базовый, но мощный шаблон, который подходит для 95% сайтов на WordPress/битрикс:

 User-agent: *
 Allow: / # Разрешаем индексацию всего, что не запрещено явно
 Disallow: /wp-admin/
 Disallow: /wp-includes/
 Disallow: /wp-login.php
 Disallow: /wp-content/plugins/
 Disallow: /wp-content/themes/ # Часто здесь лежат копии страниц в демо-данных
 Disallow: /search/ # Поиск по сайту — генератор мусора
 Disallow: /?s= # Альтернативный адрес поиска
 Disallow: /author/ # Страницы авторов, если это не корпоративный блог
 Disallow: /xmlrpc.php
 Disallow: /trackback/
 Disallow: /feed/
 Disallow: /cgi-bin/
 Disallow: /?add_to_wishlist= # Параметры из URL, которые создают дубли
 Disallow: /*?replytocom= # Комментарии с параметрами
 
 # Указываем путь к карте сайта (ОБЯЗАТЕЛЬНО поправь на свой!)
 Sitemap: https://direct-result.ru/sitemap.xml 

Почему именно так? Из личного опыта:

/wp-admin/ и /wp-includes/ — попытка проиндексировать файлы админки или ядра CMS — верный способ показать роботу "изнанку" сайта и подхватить в индекс служебные скрипты.
Страницы поиска и авторов — классические генераторы тонн дублей с нулевой ценностью.
Параметры типа ?add_to_wishlist= — одна страница товара может иметь десятки адресов из-за параметров, а робот видит их как разные страницы. Закрываем это здесь, а решаем окончательно в .htaccess.

3. .htaccess: силовой инструмент сервера. Решаем проблемы дублей

Этот файл также находится в корне сайта. Перед правкой сделай бекап! Одна синтаксическая ошибка может "положить" сайт.

Наша главная задача через .htaccess — убить дубли на уровне сервера, прописав 301-редирект на каноничные версии.

Пример 1: Убираем `www`, `http` и слеш в конце.

Один и тот же сайт может быть доступен по 8 разным адресам (http://site.ru, http://www.site.ru, https://site.ru, https://www.site.ru + каждый со слешем и без). Надо выбрать ОДИН каноничный вариант (я всегда выбираю https://site.ru/ без www и без слеша в конце для директорий).

 # Включаем механизм перенаправлений
 RewriteEngine On
 
 # 1. Принудительно включаем HTTPS (если у тебя установлен SSL)
 RewriteCond %{HTTPS} off
 RewriteRule ^(.*)$ https://direct-result.ru/$1 [R=301,L]
 
 # 2. Убираем www (если ты выбрал домен БЕЗ www)
 RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
 RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
 
 # 3. Убираем слеш в конце для всех URL, кроме реальных папок
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteCond %{REQUEST_URI} (.+)/$
 RewriteRule ^ %1 [R=301,L] 

Пример 2: Закрываем параметры сессий и UTM-метки.

Если на сайте есть ?utm_source=... или ?sessionid=..., это создает дубли. Робот должен видеть только чистый URL.

 # Убираем указанные параметры из URL, не создавая редирект (внутренняя переадресация)
 RewriteCond %{QUERY_STRING} ^(.*)&?(utm_source|utm_medium|utm_campaign|utm_term|utm_content|gclid|fbclid|sessionid)=[^&]+(.*)$ [NC]
 RewriteRule ^(.*)$ /$1?%1%3 [R=301,L,NE] 

Пояснение: Это правило "вырезает" перечисленные параметры из запроса и возвращает 301 на чистый URL. Google рекомендует закрывать UTM-метки от индексации.

4. Опасные ошибки: что закрывать категорически нельзя

Здесь я перечислю то, что ломало SEO моим клиентам, пока мы не нашли причину:

Критическая ошибка: `Disallow: /` в robots.txt

Что происходит: Полное закрытие сайта от индексации. Видел даже на больших сайтах.

Решение: Удалить эту строку или заменить на Allow: /.

Закрытие CSS, JS и изображений

Ошибка: Disallow: /css/, Disallow: /js/, Disallow: /images/

Проблема: Робот должен иметь доступ к стилям и скриптам для корректного рендеринга страницы. Без этого ты скрываешь от Google половину сайта.

Решение: Никогда не закрывать ресурсы, необходимые для отображения страницы.

Закрытие реальных разделов сайта по ошибке

Пример: Disallow: /catalog/, когда там лежат товары.

Решение: Всегда проверяй путь перед тем, как добавить его в Disallow.

Редирект через `.htaccess` без кода `301`

Проблема: Если использовать R=302 (временный редирект), вес страницы не передастся.

Решение: Всегда используй R=301 для постоянных переадресаций.

Совет из практики: Самая частая ошибка — случайное закрытие Disallow: /wp-content/uploads/. В этой папке лежат все изображения и файлы сайта. Закрыв ее, ты сделаешь медиафайлы невидимыми для поиска по картинкам.

5. Проверка и отладка: как убедиться, что всё работает

Теория — ничто без проверки. Вот мой обязательный чек-лист после любых правок:

1. Проверяем доступность файлов:

Открой в браузере твойсайт.ru/robots.txt (должен отображаться)
Попробуй открыть твойсайт.ru/.htaccess (второй, скорее всего, выдаст ошибку 403 — это нормально, он закрыт)

2. Используем Google Search Console (GSC):

Во вкладке "Сканирование" → "Проверка robots.txt" загрузи свой файл и проверь блокировки.
Используй "Проверить URL" после правок .htaccess. Введи старый URL (с www или параметром) и посмотри, как его обрабатывает Google. В статусе должно быть "Найден: URL переадресован" с кодом 301.

3. Инструмент для проверки редиректов:

Использую Chrome-плагин "Redirect Path" или сервис Redirect Checker. Позволяет увидеть цепочку редиректов.

4. Взгляд робота:

В GSC есть инструмент "Посмотреть как Googlebot". Запроси им главную страницу после изменений, чтобы убедиться, что робот видит то, что нужно.

Чек-лист проверки за 5 минут:

Robots.txt доступен по прямому URL?

Нет ли строки Disallow: /?

Указан правильный путь к sitemap.xml?

Редиректы работают с кодом 301?

Сайт доступен только по одному зеркалу (с www или без)?

Параметры UTM корректно удаляются?

6. FAQ и возражения: ответы на частые вопросы

О: Индексация дублей — это прошлое. После наших правок новые дубли появляться не будут. Старые же исчезнут из индекса сами со временем (недели, иногда месяцы). Можно ускорить процесс, отправив старые дубли-URL на переобход в GSC или сделав точечный 410-й ответ (удалено) для совсем мусорных страниц.

О: Верно. .htaccess — файл для сервера Apache. На Nginx конфигурация прописывается в основном файле конфигурации сервера (обычно nginx.conf). Логика правил (редиректы с www на без-www, с HTTP на HTTPS) та же, но синтаксис другой. Тебе нужен доступ к конфигурации сервера или помощь администратора.

О: Нет, и вот живой пример. Ты закрыл страницу поиска в robots.txt (Disallow: /search/). Умный робот послушается, но на твой сайт могут вести тысячи ссылок с других сайтов на URL с параметрами (site.ru?q=...). Если эти параметры не обработаны, они проиндексируются. Robots.txt не блокирует сканирование по ссылкам, он лишь говорит, куда не ходить самому. Связка с .htaccess решает проблему наверняка.

О: Страх обоснован. Поэтому алгоритм такой:

Скачай старый файл на компьютер (бекап).
Вноси правки через FTP-клиент или файловый менеджер хостинга.
Сразу же проверь главную страницу сайта в браузере. Если видишь ошибку 500 — быстро верни старый файл.

Все редиректы проверяй потом, главное — чтобы сайт работал.

О: Да, конечно. В robots.txt можно указать конкретные пути. Например, Disallow: /private/ закроет всю папку /private/. Но помни: это только просьба роботу. Для полной защиты нужно также закрыть доступ через настройки сервера или паролем.

О: Не часто. Только когда:

Меняется структура сайта (появляются новые разделы, которые нужно закрыть)
Обнаруживаются новые параметры, создающие дубли
Меняется домен или протокол
Обновляется CMS и появляются новые служебные пути

Раз в полгода — достаточная периодичность для аудита этих файлов.