Техническая SEO - Анализ серверных логов

1. Чего хотят палочки?
2. Наш любимый посетитель - Googlebot
3. Как работают журналы сервера?
4. Где журналы?
5. апаш
6. Nginx
7. Microsoft IIS
8. Обработка журнала сервера
9. 1. Электронная таблица
10. 2. Корпоративные приложения
11. 3. Эластичный стек
12. Технические SEO Практические примеры
13. Обнаружение поисковых роботов
14. коды ошибок
15. переадресовывает
16. Сканирование бюджетных отходов
17. Множественный доступ
18. Приоритет сканирования

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

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

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

Чтобы Google предпочел страницу, рекомендуется превратить ее в область искателя для роботов. Журнал веб-сервера является единственным источником данных, который показывает 100% точность того, как боты проходят страницу (или как они пытаются). Очень хорошая основа для поисковой оптимизации страницы - позволить Google отобразить страницу просто и быстро.

Чего хотят палочки?

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

У меня все еще есть ошибочное мнение, что эти веб-боты генерируют только незначительный трафик на сайте, поэтому они оказывают минимальное влияние на нагрузку веб-сервера. Это было несколько лет назад, но это было Инкапсула 2016 Отчет большая часть интернет-трафика уже генерируется сотрудниками. Другими словами, роботы теряют больше, чем люди. Это соотношение, безусловно, будет расти без остановки для роботов в ближайшие годы.

Наш любимый посетитель - Googlebot

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

Поскольку ресурсы Googlebot не безграничны, он не будет бесконечно пытаться столкнуть препятствия на своем пути. Примеры этого включают в себя различные ловушки, которые приводят наших гостей в бесконечный цикл, или чрезмерное время отклика и коды ошибок HTTP. Мы также можем помочь вам работать с автоматизированной системой сканирования Google, гарантируя, что исходный код страницы соответствует минимальным требованиям качества, которые вы ожидаете сегодня. Хороший и эффективный код может быть обработан ботами быстрее. Хотя нет прямых доказательств того, что страницы с более простым в обработке кодом подвергаются позитивной дискриминации, каждый может выиграть, только если мы позаботимся об этом.

Иногда, Googlebot выпускают торговые автоматы, которые на самом деле не хотят, просто хотят проскользнуть через некоторые из более простых показов. Робот Googlebot использует несколько IP-адресов, которые постоянно меняются, поэтому не стоит работать с фиксированными списками IP-адресов. Если вы хотите определить, действительно ли IP-адрес является одним из адресов, используемых роботом Google, это легко обратный поиск DNS utánajárhatunk.

Как работают журналы сервера?

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

К счастью, большинство веб-серверов используют один и тот же стандарт для ведения журналов с 1990-х годов с небольшими или большими исключениями или модификациями. Это позволяет нам обрабатывать файл журнала Apache аналогично файлу журнала, созданному Nginx. Согласно стандарту мы записываем каждое попадание , что обычно означает запрос файла с веб-сервера. Соответственно, загрузка страницы не будет единственным хитом , поскольку мы загружаем изображения, внешние файлы JavaScript и CSS или что-либо еще, что появляется на странице. Все они появляются как отдельные верования . Журналы содержат их.

Давайте рассмотрим Общий формат журнала стандартная интерпретация. В большинстве случаев веб-серверы используют эту или расширенную версию, которая предоставляет чуть более подробную информацию (например, формат журнала Apache или расширенный формат файла журнала Microsoft IIS ).

127.0.0.1 идентификатор пользователя franc [10 / Oct / 2000: 13: 55: 36 -0700] «GET /apache_pb.gif HTTP / 1.0» 200 2326

• 127.0.0.1 - IP-адрес клиента, отправившего запрос на веб-сервер.
• идентификатор пользователя - используется для идентификации конкретного соединения TCP.
• Фрэнк - Идентификация запрашивающего пользователя. Обычно здесь используется уникальный идентификатор вошедших (или иным образом идентифицированных) пользователей.
• [10 / Oct / 2000: 13: 55: 36 -0700] - Дата и время запроса вместе с часовым поясом.
• «GET /apache_pb.gif HTTP / 1.0» - HTTP-сообщение, которое клиент отправил на сервер.
• 200 - код состояния HTTP, передаваемый клиенту в ответ. В этом примере 200, так что все прошло успешно.
• 2326 - Размер объекта, отправляемого сервером в байтах.

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

Где журналы?

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

апаш

В различных версиях Apache местоположение регистрации по умолчанию находится в другом месте.

Файл журнала Apache RHEL / Red Hat / CentOS / Fedora Linux:
/ Вар / Журнал / HTTPD / access_log

Файл журнала Apache Debian / Ubuntu Linux:
/var/log/apache2/access.log

Файл журнала FreeBSD Apache:
/var/log/httpd-access.log

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

grep CustomLog /etc/apache2/apache2.conf

Nginx

Для второго по популярности веб-сервера путь по умолчанию для файлов журнала доступен здесь:
вар / Журнал / Nginx /

Здесь error.log и access.log предоставляют полезную информацию.

Microsoft IIS

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

Обработка журнала сервера

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

• Разработка и контроль качества
• Устранение неполадок в сети
• Обнаружение атак
• Сервисная служба предоставляет более подробную информацию о проблеме
• SEO техники

Конечно, на этот раз мы разберемся с последним более подробно. Анализ журналов обычно не является обычной задачей. Это происходит, когда есть проблема, и мы хотим найти решение таким образом. Большая часть линии - область технического SEO, так как иногда стоит выполнить простую проверку, чтобы увидеть, все ли хорошо на заднем плане.

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

1. Электронная таблица

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

2. Корпоративные приложения

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

3. Эластичный стек

Отдельная категория заслуживает абсолютно бесплатного программного обеспечения с открытым исходным кодом, Elastic Stack. Конечно, если вы хотите работать на сервере (например, Amazon Web Services), вы должны платить за услугу в зависимости от использования, поэтому само программное обеспечение является бесплатным. Пакет предоставляет комплексное решение для отображения, обработки, анализа и архивирования необработанных данных журнала. В большинстве случаев этот пакет является правильным выбором для технического SEO.

Технические SEO Практические примеры

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

Обнаружение поисковых роботов

Хотя до сих пор упоминался только робот Google, у каждой поисковой системы есть свои роботы, которые сканируют Интернет (так как их сервис основан на нем). Конечно, все они работают по уникальному (и постоянно развивающемуся) алгоритму, но работают они совершенно одинаково, и большинство может интерпретировать информацию, предназначенную для роботов (например, robots.txt, noindex и т. Д.). Если поисковые системы, используемые нашей целевой аудиторией, не могут правильно сканировать страницу, мы можем потерять ценных посетителей. Поэтому в первом раунде стоит изучить, сколько поисковых систем сканирует сайт, что он делает и как работает. Хотя Google лидирует по количеству поисковых запросов в Венгрии, есть много стран, где это не так (например, Россия, Чехия, Китай). Если вы хотите нацелиться на такие страны, вы должны следить за другими роботами. Если вы не можете или не хотите правильно сканировать страницу, рекомендуется как можно скорее обратиться к источнику проблемы (обычно с дополнительным анализом журнала).

Опять же, важно подчеркнуть, что не каждая палка, которую вы отпускаете. В поле user-agent всегда хранятся только те веб-серверы, которые устанавливают сами клиенты. В случае подозрительной или необычной активности стоит посмотреть соответствующие IP-адреса.

коды ошибок

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

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

Если путь к контенту изменяется, мы перенаправляем его. Однако не имеет значения, какое перенаправление мы используем. Могут быть определены не только статические пары перенаправления, но также могут быть определены правила, которые соответствуют регулярным выражениям. Если вы случайно сопоставите такую ​​фразу с заголовком, который не следует делать, пользователь будет перенаправлен на страницу, которая не имеет к ним отношения, и мы не узнаем об ошибке, поскольку только одно стандартное перенаправление было выполнено без кода ошибки. Многие (SEO и логично) неправильно используют перенаправления 301 (окончательный) и 302 (временный), поэтому их обязательно нужно учитывать. Такие и подобные случаи могут быть выявлены в случае перенаправления.

Сканирование бюджетных отходов

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

Бюджет сканирования представляет собой смесь двух только что описанных явлений. В объяснении Google бюджет сканирования - это количество URL-адресов, которые робот Googlebot может и хочет сканировать в течение заданного времени.

Хотя, по словам Гари Иллиеса, большинству сайтов вообще не нужно беспокоиться о бюджете сканирования, бывают случаи, когда мы «тратим» эту платформу на сканирование бесполезного или нерелевантного контента за счет других важных сайтов. Таким образом, дневной лимит может быть перенесен на менее важные части и покинуть сайт до того, как робот Google достигнет точки.

Важно правильно использовать файлы robots.txt и meta robot, чтобы минимизировать ваши ежедневные потери. Однако, если ежедневных отходов слишком много, стоит посмотреть на причину этого явления.

Множественный доступ

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

К счастью, вы можете подробно настроить способ интерпретации определенными параметрами URL в консоли поиска Google. Эта проблема тесно связана с предыдущим пунктом, поскольку мы также тратим здесь впустую бюджет, рискуя тем, что никакие другие важные страницы не имеют рамки.

Приоритет сканирования

Иногда Google не посещает определенные страницы (или целые отделы) достаточно регулярно, поэтому не обрабатывает их с правильным приоритетом. Если мы обнаружим, что что-то привлекает слишком много или слишком мало внимания со стороны поисковой системы, рекомендуется предпринять шаги для изменения фокуса. Прежде всего, вам следует пересмотреть и (при необходимости) изменить стратегию внутренних ссылок, потому что у Google есть хорошие шансы не иметь чего-то важного, потому что мы показываем это на основе структуры ссылок. Если этого недостаточно, вы можете установить приоритет сканирования в файле Sitemap XML. Таким образом, мы можем заставить вас не иметь дело со слишком многими частями, которые были просканированы на благо важных, но забытых страниц.

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

slide_template: по умолчанию essb_pc_facebook: 3 essb_pc_twitter: 1

Похожие

Комментарии