Техническое SEO

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

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

Семь слоёв технической базы

Технику сайта удобно представлять как пирамиду. Каждый следующий слой имеет смысл только тогда, когда предыдущий стоит ровно. Робот сначала должен физически получить страницу, потом решить, брать ли её в индекс, потом понять, не копия ли она соседней, и только затем оценивать скорость, разметку и удобство.

Слой	Что проверить	Чем
1. Доступность	Коды ответа, редиректы, 404, аптайм, время ответа	curl, парсер, мониторинг доступности
2. Индексация	robots.txt, карта сайта, canonical, meta robots, бюджет обхода	Панели вебмастеров, парсер
3. Дубли	Параметры, пагинация, фильтры, товар в разных категориях	Парсер, поиск по индексу, логи
4. Скорость	Ответ сервера, изображения, скрипты, кэш, PHP, хостинг	Замеры скорости, консоль браузера
5. Мобильная версия	Адаптивность, читаемость, кнопки, формы	Реальный телефон, эмулятор устройств
6. Разметка	Заголовки, метатеги, микроразметка, хлебные крошки	Парсер, валидаторы разметки
7. Безопасность	Сертификат, обновления, доступы, бэкапы	Панель хостинга, админка, проверка сертификата

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

Слой первый: коды ответа и страница 404

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

Самый частый и самый разрушительный случай — «мягкая» 404. Пользователь заходит по битому адресу, видит надпись «Страница не найдена», а сервер отдаёт 200 OK. Для робота это означает: страница существует, содержимое валидное, берём в индекс. На магазине с генерацией адресов из фильтров такая ошибка легко даёт десятки тысяч мусорных документов.

Код	Что означает	Когда уместен
200	Страница существует и отдана	Все рабочие страницы
301	Переезд навсегда	Склейка зеркал, смена адресов, https
302	Временный переезд	Почти никогда в SEO-задачах
404	Страницы нет	Удалённые и несуществующие адреса
410	Страница удалена навсегда	Разделы, которые точно не вернутся
500	Ошибка сервера	Никогда, это авария
503	Сайт временно недоступен	Плановые работы, не дольше нескольких часов

Проверять коды проще всего из терминала, по одному адресу и по списку:

curl -sI https://example.ru/ | head -n 1
curl -sI https://example.ru/nesushchestvuyushchaya-stranica-123/ | head -n 1

while read u; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "$u")
  echo "$code $u"
done < urls.txt

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

Сама страница 404 должна отдавать код 404, иметь шапку и меню сайта, поиск по каталогу и пару ссылок на популярные разделы. Это не про SEO напрямую, это про то, чтобы человек не закрыл вкладку.

Один сайт — один адрес: www, https и слеши

У любой страницы теоретически существует до восьми вариантов написания адреса: с www и без, по http и https, со слешем на конце и без, плюс версии с índex-файлом. Задача — сделать так, чтобы семь из восьми отдавали 301 на восьмой, канонический.

• Выберите основное зеркало: с www или без. Разницы для позиций нет, важна только последовательность.
• Все http-адреса должны уходить на https одним редиректом, а не цепочкой из трёх.
• Определитесь со слешем на конце и держите одно правило по всему сайту.
• Проверьте, что внутренние ссылки ведут сразу на конечный вид адреса, а не через редирект.

Цепочки редиректов — отдельная беда. Когда http без www ведёт на http с www, тот на https с www, а он уже на https без www, робот проходит три лишних шага. На больших сайтах это заметно съедает бюджет обхода, а иногда часть переходов просто теряется.

curl -sIL http://example.ru/katalog/ | grep -E "HTTP/|location:"

В идеальном ответе будет ровно две строки со статусом: 301 и затем 200. Три и больше — повод переписать правила в конфигурации сервера.

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

Аптайм и время ответа сервера

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

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

curl -s -o /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.ru/

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

Слой второй: robots.txt и карта сайта

Файл robots.txt — самый короткий файл на сайте и самый частый источник катастроф. Одна лишняя строка закрывает от индексации весь сайт, и обнаруживается это через месяц, когда трафик уже обнулился.

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

Тему разбирал отдельно: «GEO + техническое SEO: как готовить сайт к выдаче нейросетей и классическому поиску».

User-agent: *
Disallow: /admin/
Disallow: /cart/
Disallow: /search/
Disallow: /*?utm_
Allow: /*.css
Allow: /*.js

Sitemap: https://example.ru/sitemap.xml

Строка вида Disallow: / под общим агентом означает запрет на весь сайт. Именно её забывают убрать после переноса с тестового домена — проверяйте robots.txt сразу после любого релиза.

Карта сайта должна содержать только те адреса, которые вы хотите видеть в индексе: код ответа 200, без редиректов, без закрытых в robots, без неканонических версий. Карта, наполовину состоящая из битых ссылок, снижает доверие к ней целиком.

• Не больше 50 000 адресов и 50 МБ в одном файле, иначе разбивайте на несколько и делайте индексный sitemap.
• Дата последнего изменения должна быть настоящей: если она обновляется у всех страниц каждую ночь, ей перестают верить.
• Приоритет и частота обновления практического влияния почти не имеют, спорить о них не стоит.
• Карта должна отдаваться по прямой ссылке без авторизации и с корректным типом содержимого.

Канонические адреса и управление индексацией

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

<link rel="canonical" href="https://example.ru/katalog/nasosy/" />
<meta name="robots" content="noindex, follow" />

Типичные ошибки с canonical: адрес указан относительный вместо абсолютного, указан http вместо https, у всех страниц пагинации стоит canonical на первую страницу, а на страницах фильтров canonical ведёт на страницу, закрытую в robots.txt.

Помогу с продвижением: SEO-продвижение для бизнеса — вывожу сайты в топ Яндекса белыми методами.

Важное правило: если страница закрыта в robots.txt, робот не увидит на ней ни canonical, ни meta robots. Чтобы страница гарантированно выпала из индекса, её нужно оставить открытой для обхода и закрыть именно мета-тегом. Двойное закрытие — самая частая причина того, что мусорные адреса висят в выдаче годами.

Для файлов, у которых нет HTML-кода — PDF, документы, архивы — работает заголовок ответа сервера:

<FilesMatch "\.(pdf|doc|docx|xls)$">
  Header set X-Robots-Tag "noindex, nofollow"
</FilesMatch>

Бюджет обхода и статистика обхода в панели

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

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

• Закройте от обхода технические разделы: корзину, сравнение, поиск по сайту, личный кабинет.
• Уберите из внутренних ссылок адреса, которые всё равно не должны индексироваться.
• Сократите цепочки редиректов — каждая лишняя ступень тратит визит робота.
• Уберите битые ссылки внутри сайта: робот честно ходит и по ним тоже.
• Следите за скоростью ответа — чем быстрее сервер, тем больше страниц робот успевает забрать.

Статистика обхода в панели вебмастера показывает, что именно робот скачивал и какие коды получал. Всплеск ошибок 5xx в графике — прямое указание на проблемы с хостингом; рост числа обойдённых страниц без роста числа страниц в поиске — признак дублей.

Слой третий: дубли страниц

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

Параметры в адресах. Метки рекламных кампаний, идентификаторы сессий, параметры сортировки создают бесконечное количество вариантов одной страницы:

/katalog/nasosy/
/katalog/nasosy/?utm_source=yandex&utm_medium=cpc
/katalog/nasosy/?sort=price&order=asc
/katalog/nasosy/?PAGEN_1=1

Решение — canonical на чистый адрес плюс запрет обхода параметров в robots.txt. Метки от рекламы обычно достаточно закрыть маской, а параметры сортировки лучше не выводить в ссылках вовсе.

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

Фильтры. Здесь нужен осознанный выбор. Страницы фильтров, под которые есть реальный спрос, — «насосы дренажные», «насосы циркуляционные» — делают отдельными посадочными: свой заголовок, свой текст, свой адрес без параметров. Все остальные комбинации фильтров закрывают от индексации, иначе получается комбинаторный взрыв.

Один товар в разных категориях. Если карточка доступна и по адресу с категорией, и по короткому адресу, выберите один вид и настройте canonical на него. Проще всего сделать карточку доступной только по короткому адресу вида /product/nasos-grundfos-25-40/, а принадлежность к категориям показывать хлебными крошками.

Смежный материал по теме — «Как посчитать, окупается ли SEO: формула, которую подрядчики вам не покажут».

Копии главной. Классика: главная доступна по адресу с index.php, по адресу с двойным слешем, по адресу в верхнем регистре. Проверяется вручную за пять минут, чинится одним правилом на сервере.

Слой четвёртый: скорость

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

• Время ответа сервера. Первое, что чинят. Кэширование готовых страниц, оптимизация запросов к базе, переход на тариф с нормальным процессором.
• Изображения. Обычно половина веса страницы. Пережать в webp или avif, задать реальные размеры в атрибутах, включить отложенную загрузку для всего, что ниже первого экрана.
• Скрипты и стили. Объединить, минифицировать, вынести некритичное вниз, повесить атрибут отложенного выполнения. Отдельно проверить сторонние скрипты: чаты, счётчики, виджеты отзывов часто грузятся дольше самого сайта.
• Кэш браузера. Заголовки кэширования для статики — самая дешёвая оптимизация из существующих.
• Версия PHP. Переход с 7.4 на 8.2 нередко даёт полуторакратный прирост скорости генерации без единой строчки кода.
• Хостинг. Если сайт на общем тарифе делит сервер с сотней соседей, никакая оптимизация кода не спасёт.

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
</IfModule>

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

Слой пятый: мобильная версия

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

• Горизонтальная прокрутка отсутствует на всех типах страниц, включая таблицы и карточки товара.
• Основной текст не мельче 16 пикселей, межстрочный интервал не меньше 1,5.
• Кнопки и ссылки не меньше 44 пикселей по высоте и не липнут друг к другу.
• Формы: правильные типы полей, чтобы для телефона открывалась цифровая клавиатура, а для почты — с собакой.
• Всплывающие окна не занимают весь экран и закрываются с первого нажатия.
• Телефон и адрес — кликабельные ссылки, а не картинка и не текст.

Что проверять именно на живом устройстве: скорость на мобильном интернете, а не по вай-фаю; удобство заполнения формы одним пальцем; читаемость на солнце; не перекрывает ли виджет чата кнопку заказа. Эмулятор всего этого не показывает.

Слой шестой: разметка и микроразметка

Когда доступность, индексация, дубли и скорость в порядке, наступает очередь разметки. Она редко даёт взрывной рост, но собирает мелкие проценты по всей структуре.

• Заголовки. Один H1 на страницу, дальше H2 и H3 по смыслу, без пропусков уровней и без использования заголовков ради размера шрифта.
• Title. Уникальный на каждой странице, главный запрос ближе к началу, длина, при которой он не обрезается в выдаче.
• Description. Не влияет на позиции, влияет на кликабельность. Пустые и одинаковые описания — упущенные переходы.
• Атрибут alt у изображений. Осмысленное описание того, что на картинке, без перечисления ключевых слов.

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Название компании",
  "url": "https://example.ru/",
  "telephone": "+7 900 000-00-00",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Москва",
    "streetAddress": "улица Примерная, 1"
  }
}
</script>

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

Слой седьмой: безопасность

Технический аудит без проверки безопасности неполон: взломанный сайт теряет позиции за считанные дни, а восстановление занимает недели.

• Сертификат. Действующий, выданный на нужный домен, с автоматическим продлением. Истёкший сертификат вешает предупреждение браузера и обнуляет трафик за сутки.
• Обновления движка и расширений. Большинство взломов идёт через известные уязвимости в старых версиях плагинов, а не через подбор пароля.
• Доступы. Уникальные пароли, двухфакторная авторизация в панели хостинга, удаление учётных записей уволившихся подрядчиков, отдельный доступ для каждого исполнителя.
• Бэкапы. Ежедневные, хранящиеся отдельно от сервера, с проверенным разворачиванием. Резервная копия, которую ни разу не разворачивали, копией не считается.

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

Чем проверять

Если нужна помощь по теме — тексты для сайта.

Инструментов много, но набор для регулярной работы небольшой. Важно понимать, что каждый показывает и чего он принципиально не видит.

Инструмент	Что показывает	Чего не покажет
Панели вебмастеров	Индексация, ошибки обхода, запросы, санкции	Скорость по каждой странице, детали вёрстки
Парсер сайта	Коды ответа, дубли title, битые ссылки, цепочки редиректов	Как реально ведёт себя робот
Логи сервера	Куда ходит робот, что получает, сколько тратит	Причину проблем, только симптомы
Консоль браузера	Ошибки скриптов, смешанный контент, блокировки	Проблемы серверной части
Замеры скорости	Вес ресурсов, отрисовка, узкие места загрузки	Реальную скорость на телефоне пользователя
curl из терминала	Заголовки, коды, время ответа без кэша браузера	Всё, что зависит от исполнения скриптов

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

grep -i "YandexBot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

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

Как отличить критичное от косметики

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

Если нужны детали, смотрите «Прямой трафик вырос в 20 раз — и это катастрофа, а не радость».

Рабочий фильтр простой. Задайте по каждому пункту три вопроса: мешает ли это роботу получить страницу, мешает ли попасть в индекс, мешает ли пользователю совершить целевое действие. Если ни на один нет ответа «да» — это косметика.

Критично	Косметика
Сайт закрыт в robots.txt целиком	В robots.txt нет комментариев и красивого форматирования
Ошибки 500 на части страниц	Один редирект 302 на служебной странице
«Мягкие» 404 с кодом 200	Дизайн страницы 404 без иллюстрации
Дубли главной по нескольким адресам	Разная длина title у двух страниц блога
Пустые или одинаковые title у категорий	Отсутствие description у архивных страниц
Мобильная версия с горизонтальной прокруткой	Сдвиг кнопки на три пикселя в старом браузере
Истёкший сертификат	Отсутствие микроразметки у страницы «О компании»
Время ответа сервера больше двух секунд	Оценка в тестере скорости 84 вместо 92

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

Порядок исправлений

Правки различаются не только по важности, но и по скорости отдачи. Часть даёт эффект в течение недели, часть — только через квартал, и это нужно закладывать в ожидания.

Даёт результат сразу, в пределах одной-двух недель:

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

Работает вдолгую, эффект копится месяцами:

• Чистка дублей на большом каталоге — поисковая система пересматривает выбор постепенно.
• Перераспределение бюджета обхода в пользу коммерческих страниц.
• Оптимизация скорости — влияет через поведение, а не напрямую.
• Внедрение микроразметки и хлебных крошек.
• Наведение порядка в заголовках и метатегах по всему сайту.

Практический порядок работ: сначала всё, что мешает роботу получить страницу; затем всё, что мешает попасть в индекс; затем дубли; затем скорость и мобильная версия; и только потом разметка. Не пытайтесь делать всё параллельно — если после недели правок трафик изменился, вы не поймёте, что именно сработало.

После правок: дата, переобход, IndexNow

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

1. Обновите дату изменения. Если правки вносились напрямую в базу, дата модификации могла остаться прежней — тогда ни карта сайта, ни автоматические уведомления страницу не подхватят.
2. Отправьте на переобход. В панелях вебмастеров есть инструмент повторного обхода с суточным лимитом адресов. Приоритет — самые важные коммерческие страницы.
3. Проверьте IndexNow. Если он подключён, уведомления уходят автоматически при публикации и изменении. Загляните в лог отправок и убедитесь, что правленые адреса там есть.
4. Обновите карту сайта. Даты последнего изменения должны отражать реальные правки.
5. Проконтролируйте через неделю. Откройте сохранённую копию страницы в поиске и посмотрите, видит ли робот новую версию.

curl -s "https://yandex.com/indexnow?url=https://example.ru/katalog/nasosy/&key=VASH_KLYUCH"

Контрольная точка через неделю обязательна. Именно на ней всплывают правки, которые не доехали: кэш не сброшен, изменения откатились при обновлении шаблона, редирект настроен только для одной из версий адреса.

Регламент проверок

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

Что проверять	Как часто	Сколько занимает
robots.txt и карта сайта	Ежемесячно	5 минут
Коды ответа по списку ключевых страниц	Ежемесячно	10 минут
Число страниц в индексе против реального	Ежемесячно	10 минут
Ошибки обхода в панели вебмастера	Ежемесячно	15 минут
Скорость главной, категории и карточки	Ежемесячно	15 минут
Срок действия сертификата и домена	Ежемесячно	2 минуты
Полный обход парсером	Раз в квартал	1-2 часа
Анализ логов по роботу	Раз в квартал	1 час

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

• robots.txt не превратился в запрет всего сайта.
• Мета-тег запрета индексации не остался с тестового окружения.
• Главная и ключевые разделы отдают 200, битый адрес отдаёт 404.
• Все адреса ведут на канонический вид без новых цепочек редиректов.
• Консоль браузера чиста: нет смешанного контента и ошибок скриптов.
• Форма заявки отправляется и письмо доходит.
• Счётчики аналитики на месте и фиксируют цели.

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

Частые вопросы

Можно ли обойтись бесплатным роботом-аудитом вместо ручной проверки?
Как первичный сбор данных — да, он быстро найдёт битые ссылки, дубли title и цепочки редиректов. Но приоритеты он расставить не может: контекста сайта у него нет, и осознанное решение он не отличит от ошибки. Список от сервиса — сырьё, а не план работ.

Через сколько после технических правок будет виден результат?
Зависит от типа правки. Снятие запрета индексации отзывается за одну-две недели, чистка дублей на крупном каталоге — за два-три месяца, скорость и разметка проявляются ещё медленнее и заметны только на длинной дистанции.

Обязательно ли закрывать страницы фильтров от индексации?
Не все. Комбинации, под которые есть реальный спрос, выгоднее оформить как отдельные посадочные страницы с человеческим адресом и текстом. Всё остальное закрывают, иначе робот утонет в комбинаторике и не дойдёт до карточек товара.

Что делать, если сайт быстро работает по замерам, а пользователи жалуются на тормоза?
Проверьте на реальном телефоне через мобильный интернет и посмотрите сторонние скрипты. Чаты, виджеты отзывов и рекламные пиксели часто грузятся уже после того, как тестер отчитался об успехе, и именно они блокируют интерфейс.

Насколько критична версия PHP для SEO?
Напрямую — никак, поисковая система её не видит. Косвенно — сильно: старая версия медленнее генерирует страницы, а значит растёт время ответа сервера и падает число страниц, которые робот успевает обойти. Плюс необновляемые версии не получают патчей безопасности.

Разбор живого сайта: что именно мешает ему продвигаться:

2:29

Коротко

• Проверяйте технику по слоям снизу вверх: доступность, индексация, дубли, скорость, мобильная версия, разметка, безопасность.
• Самые дорогие ошибки — «мягкие» 404 с кодом 200, случайный запрет в robots.txt и дубли главной по нескольким адресам.
• Страницу, которую нужно убрать из индекса, закрывают мета-тегом при открытом обходе, а не двойным запретом в robots.txt.
• Список из сотни пунктов от робота-аудита фильтруйте тремя вопросами: мешает получить страницу, мешает индексации, мешает пользователю.
• После правок обновите дату изменения, отправьте на переобход и вернитесь к проверке через неделю — часть исправлений не доезжает.

Провести технический разбор вашего сайта помогу на SEO-консультации.