Инструкций, как подготовить сайт к запуску — вагон и маленькая тележка. Они действительно важны и полезны (возможно, я как-нибудь соберусь и напишу свою). Но есть один нюанс.
Вот вы сделали новый сайт. Убедились, что страницы загружаются быстро, расправились с битыми ссылками, подключили системы аналитики… Выполнили еще добрую сотню пунктов из чек-листа. Все, можно вздохнуть с облегчением и пойти выпить отдохнуть недельку?
Увы, нет.
Если проект более-менее сложный, то предусмотреть все без исключения проблемы не получится. Огромное большинство сайтов годами живут с техническими недочетами, а вы хотите до релиза сделать все идеально? Тут должно сильно повезти.
В первую пару недель после старта за сайтом нужно следить особенно внимательно и оперативно его дорабатывать. Новорожденный ресурс уязвим (например, для воров контента). Не помешает, если первое впечатление на поисковые системы будет благоприятным.
Ситуация осложняется тем, что на начальном этапе у нас минимальные возможности для анализа (нет статистики в панелях вебмастеров и системах веб-аналитики).
Что же делать? Очевидно, пользоваться теми данными, которые есть.
Анализ логов сервера на старте проекта — насущная необходимость
По большому счету, логи — единственное, что доступно в первые дни. Для оптимизатора важен в первую очередь access.log. Заодно можно поставить разработчику задачу разгребать лог ошибок и исправлять их — хуже не будет.
Лог доступа показывает нам в реальном времени как посетители и роботы взаимодействуют с сайтом. Изучаем его и ищем несоответствия, подозрительные записи. Например:
- Посещение страниц, которых нет в карте сайта (а не мусорный ли это документ?).
- Ошибки сервера, в первую очередь 404. На новом нормальном сайте им взяться неоткуда. Стоит проверить и редиректы (301,302).
- Обращения с малым количеством отданных байт. Опять же подозрение на мусорный контент или некорректную работу скрипта, неполную загрузку.
- Множество заходов с одного и того же IP (попытка взлома? парсинг контента?).
Разумеется, неоценимую помощь логи могут оказать для ускорения индексации больших сайтов.
Для автоматизации анализа можно использовать этот бесплатный инструмент. Имейте в виду, что всю работу он за вас не сделает, так как возможных проблем неисчислимое множество. К счастью, на стадии запуска журналы не такие большие (нет реальных посетителей, в основном боты). Лог за день-два можно просматривать и вручную, используя простой поиск в Notepad.
Приведу любопытный пример, показывающий, какими разными бывают нештатные ситуации, отражающиеся в логах.
История одного запуска, который чуть не провалился
Как-то ко мне обратились за аудитом для только что созданного сайта.
Вообще-то правильно сначала сделать аудит, а потом уже открывать доступ к ресурсу. Но лучше уж так, чем спустя два года после старта.
Я первым делом затребовал логи. Открываю и вижу, что Googlebot довольно активно ползает по страницам, буквально с первого же дня. Как-то подозрительно, непохоже на него.
Смотрю дальше — а Googlebot какой-то странный. Большая часть визитов имела реферер, чего у поисковых роботов обычно нет.
Реферер — это один из HTTP-заголовков, которые отправляются при запросе url с сервера. Содержит адрес источника перехода. Если вы кликните по ссылке выше, которая ведет на статью в Вики об access.log, то в логе Википедии появится запись с реферером http://alexeytrudov.com/biznes/internet/srazu-posle-zapuska.html.
Реферер в виде адреса одной из страниц сайта может появляться у захода поискового робота, если запрашивается файл css или js. Это нормальная ситуация. Ну а в описываемом случае показывался совершенно посторонний сайт.
Оказалось, что на домене из реферера располагается полная копия проекта! Домен имел А-запись с выделенным IP сайта, который я аудировал. То есть из-за настроек зоны DNS и сервера клиента по адресу чужого домена отдавался весь контент сайта. Визиты Googlebot на самом деле совершались на адреса, принадлежащие чужому домену (отсюда и реферер). Более того, десятки страниц с чужого сайта уже попали в индекс!
В перспективе это грозило очень неприятными проблемами с определением главного зеркала. Попросту говоря, у владельца того домена была шикарная возможность увести весь поисковый трафик.
Как решили проблему:
- Оперативно завели на сервере клиента сайт с чужим доменным именем и поставили заглушку с ответом сервера 410. Она стала открываться по всем адресам, в том числе тем, которые уже попали в индекс.
- Добавили canonical там, где он отсутствовал (для Google в принципе этого было бы достаточно, но так как Яндекс не учитывает междоменные canonical, ограничиваться только им нельзя).
- Разработчик написал скрипт для мониторинга логов и отслеживания заходов с реферером; нашли и обезвредили еще один домен.
В общем, все кончилось хорошо. Сайт живет и здравствует. А я с тех пор еще внимательнее отношусь к анализу логов, что и вам советую.
