Как провести техническую SEO-проверку перед запуском

Зачем эта проверка нужна

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

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

Доходит ли краулер до страниц вообще

Запросите ключевые страницы так, как это сделала бы машина: простым HTTP-клиентом, без браузера и без JavaScript, — и прочитайте, что пришло. Если тело приходит пустым, а содержимое собирается на клиенте; если перед текстом стоит стена согласия; если антибот-слой устраивает проверку всему с незнакомым user-agent — вы нашли проблему, не написав ни слова контента. Сделайте это отдельно для главной, страницы продукта, страницы документации и страницы цен: их часто отдают разные части стека.

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

Две строки, способные убрать весь сайт

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

Затем поищите noindex по шаблонам. Ему место в тестовом окружении, на страницах внутреннего поиска, на пустых страницах тегов и на комбинациях фильтров; в боевом шаблоне ему места нет, а попадает он туда через скопированный шаблон чаще, чем принято думать. Отметьте и то, что эти два механизма воюют друг с другом: закрытая в robots.txt страница никогда не забирается, значит, noindex на ней никогда не читается, и страница может остаться в индексе на одних входящих ссылках. Хотите что-то убрать — оставьте это доступным для обхода и повесьте директиву.

Одна страница — один адрес

Выберите одну каноническую форму адресов и заставьте всё остальное на неё редиректить: http на https, www на голый домен или наоборот, одно правило про слеш на конце, пути в нижнем регистре. Затем убедитесь, что каждая страница несёт самоссылающийся каноникал и что каноникал не указывает на главную, на редирект или на адрес с noindex. Ошибка шаблона, канонизирующая весь сайт на один адрес, — маленькое изменение с очень большим радиусом поражения.

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

Файлы, которые обязаны не спорить

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

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

Коды ответа и что перепроверять потом

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

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