Что делать сразу после запуска нового сайта: рекомендации + интересный кейс

Инструкций, как подготовить сайт к запуску – вагон и маленькая тележка. Они действительно важны и полезны (возможно, я как-нибудь соберусь и напишу свою). Но есть один нюанс.

Вот вы сделали новый сайт. Убедились, что страницы загружаются быстро, расправились с битыми ссылками, подключили системы аналитики… Выполнили еще добрую сотню пунктов из чек-листа. Все, можно вздохнуть с облегчением и пойти выпить отдохнуть недельку?

Увы, нет.

Если проект более-менее сложный, то предусмотреть все без исключения проблемы не получится. Огромное большинство сайтов годами живут с техническими недочетами, а вы хотите до релиза сделать все идеально? Тут должно сильно повезти.

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

Ситуация осложняется тем, что на начальном этапе у нас минимальные возможности для анализа (нет статистики в панелях вебмастеров и системах веб-аналитики).

Что же делать? Очевидно, пользоваться теми данными, которые есть.

Анализ логов сервера на старте проекта – насущная необходимость

По большому счету, логи – единственное, что доступно в первые дни. Для оптимизатора важен в первую очередь access.log. Заодно можно поставить разработчику задачу разгребать лог ошибок и исправлять их – хуже не будет.

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

  • Посещение страниц, которых нет в карте сайта (а не мусорный ли это документ?).
  • Ошибки сервера, в первую очередь 404. На новом нормальном сайте им взяться неоткуда. Стоит проверить и редиректы (301,302).
  • Обращения с малым количеством отданных байт. Опять же подозрение на мусорный контент или некорректную работу скрипта, неполную загрузку.
  • Множество заходов с одного и того же IP (попытка взлома? парсинг контента?).

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

Для автоматизации анализа можно использовать этот бесплатный инструмент. Имейте в виду, что всю работу он за вас не сделает, так как возможных проблем неисчислимое множество. К счастью, на стадии запуска журналы не такие большие (нет реальных посетителей, в основном боты). Лог за день-два можно просматривать и вручную, используя простой поиск в 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, ограничиваться только им нельзя).
  • Разработчик написал скрипт для мониторинга логов и отслеживания заходов с реферером; нашли и обезвредили еще один домен.

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

21 комментарий

  1. С помощью какого плагина\скрипта у вас реализована всплывающее окно с подпиской после скролинга статьи в самый низ? Не могли бы поделиться наработкой?

    • Это штатная возможность в сервисе рассылок mailerlite, настройки формы в интерфейсе, я просто использовал готовый код. У них есть официальный плагин для WP.

      • Форма на JS, так что не индексируется как основной контент. Настройки вполне стандартные. В этом сервисе вообще мне нравится, что все очень просто. Помню, пытался завести рассылку через Mailchimp – так и не завел из-за громоздкого интерфейса. Тут все быстро.

  2. Почему-то дальше отвечать у вас нельзя на сообщения. Я тоже как-то пробовал по совету Mailchimp – через 5 минут понял, что уж слишком все сложно и тоже бросил ;). А рассылка у вас тоже – mailerlite – или там можно поставить поп ап окно, а собирать все в тот же юнисендер?

  3. Это что так легко любой сайт что ли увести получается? Через А запись айпи и все? Долга же быть какая то защита от этого?

    • Конечно не все так просто.
      Тут проблема была именно в том, что создаваемый сайт совсем молодой, а направленный на его IP домен – старый и уже проиндексированный. Как оказалось, на данном IP располагался проект, у которого не продлили регистрацию домена. А сам сайт (контент) остался. И он довольно долго открывался по чужому адресу.

      Долга же быть какая то защита от этого?

      Защита простая, описана в самом конце. Главное, что вы сами решаете что показывать на домене, направленном на ваш сервер. Возможно есть и какое-то универсальное решение, это лучше спросить у администраторов серверов.

  4. Дело в кривых настройках сервера клиента. При обращении к непрописанному домену он должен открывать не один из виртуальных хостов, а заглушку. Или виртуальный хост, который не жалко )).
    Почему-то на мыло сообщение со статьей пришло уже к шапочному разбору ((.

    • При обращении к непрописанному домену он должен открывать не один из виртуальных хостов, а заглушку.

      Вот, я так и думал, что можно что-то в этом роде реализовать (но не знаю как).

      Почему-то на мыло сообщение со статьей пришло уже к шапочному разбору ((.

      Я отключал рассылку, чтобы не посылать пост с итогами – чисто личный, так что не стал забивать ящики тем, кто подписывался на SEO-шемео. Ну а включил когда проснулся только 🙂

      • >Вот, я так и думал, что можно что-то в этом роде реализовать (но не знаю как).

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

        Если NGinx – там немножко иначе, но тоже просто.

    • Алексей, покажите на примере вашего сайта, что и куда надо ввести, и увидеть или сайт или заглушку?. Непонятно до сих пор как проверить свой сервер, правильно ли он настроен

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

  5. Арбайтен говорит, что все это чушь. Если хочешь, чтобы сайт был в топе и приносил прибыль, то нужно ему 7000р заплатить и он сам за тебя сделает сайт, который будет в топ 1 всех ПС.

  6. Приветстую!

    Все слова понял, но общий смысл не очень уловил. Если есть возможность, то поясните:

    1. Старому сайту такой финт тоже может грозить?
    2. Как-то это можно проверить кроме логов? Сервисы, программы?

    И если можно для “тупых” на пальцах:

    1. Допустим, я знаю IP вашего сайта (alexeytrudov.com), что очевидно.
    2. Я создаю копию Вашего сайта на свое домене, что тоже реализовать не так уж и сложно.
    3. Я прописываю в DNS записи своего севера соответствие своего домена и Вашего IP
    4. А вот что происходит дальше для меня темный лес. Почему таким образом можно увести трафик? Совсем не понятно.

    Спасибо.

    • 1. В случае со старым это ничем не будет отличаться от обычного клона сайта.
      2. Возможно и есть варианты, но я не в курсе.
      И
      На пальцах – трафик можно увести как раз потому, что к старому сайту у поиска больше доверия, а потому выше вероятность, что молодой (ваш!) станет его неглавным зеркалом.

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

Оставить ответ