Техническое SEO: индексация, Core Web Vitals и дубли страниц

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

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

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

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

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

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

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

Точнее всего — в Search Console, отчёт «Страницы»: сколько адресов в индексе, сколько исключено и по какой причине. Сравните это число с количеством страниц, которые должны быть в поиске: если в каталоге пять тысяч товаров, а в индексе восемьсот, проблема есть. Оператор site: в поиске даёт лишь приблизительную цифру, опираться на неё не стоит. Отдельную страницу проверяет инструмент проверки URL: он показывает, есть ли она в индексе и какую версию Google считает канонической.

Чаще всего причина банальная: страницы закрыты в robots.txt или метатегом noindex, который остался после разработки, либо их нет в карте сайта и на них не ведёт ни одна ссылка. Более сложные случаи — сервер отдаёт ошибку или отвечает слишком долго, содержимое подгружает скрипт, и бот видит пустую страницу, либо десятки копий одной страницы отнимают обход. Новый сайт Google может не замечать неделями, и это ещё не поломка. Какая из причин ваша, видно из данных Search Console и логов сервера, а не из предположений.

Не так прямо, как часто думают. Core Web Vitals — один из сигналов ранжирования: среди равных по содержанию страниц более быстрая имеет преимущество, но более слабую по содержанию страницу скорость наверх не вытянет. Заметнее другое: на большом каталоге медленный ответ сервера означает, что бот за то же время обходит меньше страниц, а человек с телефона чаще закрывает вкладку. Поэтому измеряем не балл в PageSpeed Insights, а ответ сервера и данные реальных посетителей.