7 Анализ лог-файлов SEO-проверки с использованием стека ELK - (с использованием бесплатного программного обеспечения с открытым исходным кодом) - Mike Gracia

1. Как я использую Kibana для анализа файла журнала SEO
2. Какие визуализации вы можете использовать в Kibana для снимков SEO в лог-файле?
3. 2 - Отчет об активности ботов
4. 3 - Коды ответа сервера
5. 4 - Temp Redirects
6. 5 - размер изображения
7. 6 - Проблемы с обходом бюджета (быстрый обзор только для панели инструментов)
8. 7 - Проблемы безопасности
9. Попытки входа в WordPress
10. Попытки Внедрения SQL
11. Резюме - & Я впечатлен Intel NUC

Этот пост является частью 2 «Анализ лог-файлов малого масштаба SEO». Часть первая сосредоточена на установка стека ELK на Intel NUC В этом посте рассказывается, что делать после установки стека ELK.

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

Если вы являетесь экспертом в анализе стека ELK или файла журнала, этот пост (и часть 1) может быть для вас немного базовым. Это НЕ «окончательное руководство по анализу файлов журналов», это далеко не все! (это огромный предмет). Это те виды визуализаций, которые у меня есть на панели обзора / снимка, чтобы дать обзор информации из файлов журнала.

Надеюсь, вам понравятся пост и некоторые из «быстрых побед».

Пожалуйста, не стесняйтесь комментировать свои собственные быстрые победы в файле журнала, советы по анализу или комментарии к ELK Stack.

Как я использую Kibana для анализа файла журнала SEO

Сначала краткий обзор того, как работает Kibana (во всяком случае, как я его использую!).

Обнаружение: раздел «Обнаружение» позволяет выполнять поиск для детализации конкретной информации, используя синтаксис запроса lucene (это очень легко использовать, не волнуйтесь!). Я использую это двумя способами:

1. Создайте «Сохраненный поиск», который я настрою один раз, а затем создайте визуализацию, которая будет сохранена на панели инструментов.
2. Для детализации, когда я ищу что-то конкретное - обычно, когда я обнаружил что-то в визуализации на приборной панели, которая вызывает у меня интерес… Это может быть проблема SEO или потенциальная проблема безопасности - особенно когда сайт использует CMS WordPress.

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

Панель инструментов: панель инструментов показывает различные визуализации. Мне нравится создавать информационные панели, имеющие тему, например «SEO Dash» или «Security Dash». Здесь иногда происходит пересечение, когда данные появляются в двух местах ... Но я не против этого.

Какие визуализации вы можете использовать в Kibana для снимков SEO в лог-файле?

1 - Лучшие страны

Понимание того, откуда приходят ваши посетители, довольно просто, однако я хотел бы включить карту страны в свою панель инструментов Kibana SEO вместе с парой диаграмм, чтобы было легче увидеть цифры самых популярных стран:

Карта дает отличное представление о том, откуда пришли посетители, но мне также нравится видеть таблицы из лучших стран.

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

2 - Отчет об активности ботов

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

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

Как вы можете видеть, большинство ботов не видны в этой таблице из-за огромной активности «Uptime Monitoring Bot», а также из-за резкого увеличения активности «Яндекса».

Я считаю действительно полезным, что в Кибане легко:

• Изменить цвета ботов
• Перетащите и отпустите, чтобы увеличить момент времени
• Фильтр включения / выключения определенных ботов

На самом деле, давайте сделаем это сейчас! Мы отфильтруем работоспособного бота и яндекса , чтобы мы могли увидеть других ботов.

Чтобы получить необработанные цифры по ботам, что, возможно, более полезно, чем выше (но хе-хе - я включил вышесказанное по ОЧЕНЬ важной, сверх-технической причине… что мне нравятся красивые цвета !):

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

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

3 - Коды ответа сервера

Еще один полезный моментальный снимок панели инструментов - это коды ответов сервера. В приведенных ниже таблицах у нас сначала есть все коды ответов (включая 200), а затем все коды, кроме 200. (Хотя я бы назначил Kibana для обозначения ВСЕХ полей, он отказался пометить их все! Хотя вы просматриваете это в браузере это нормально, так как на пончике И есть ярлыки).

95,22% из 200 кодов - это далеко не самое худшее, что я видел, но я все же хотел бы взглянуть на остальные (почти) 5%. 2-й график выше помогает в этом.

Я хотел бы проверить 404-е, а также статус 500 (ошибка сервера… аааа. Какие URL-адреса дали этот ответ?). Для 403-х (запрещено) я бы посмотрел, какие URL вызывали этот ответ, но это не всегда вызывает озабоченность.

Я также хочу посмотреть, как ошибки прогрессируют с течением времени, поэтому я создал визуальное отображение любых кодов ответов 4 ** или 5 **. И да ... я знаю, что это включает 403 и 401, 410 - может быть, даже нечетные 418, если мне повезет! Но это нормально ... это просто обзор, и я буду копать глубже, если это необходимо. Например, я, конечно, хотел бы знать, что вызвало всплеск, показанный ниже… Я бы обратился к разделу «Обнаружение» и запросил его, возможно, создав новый график, если посчитал его полезным.

4 - Temp Redirects

Что-то еще, что я хотел бы проверить на обзорной панели мониторинга, это временные перенаправления (302 и 307 - извините за огромный красный прямоугольник - конфиденциальность клиента и все!):

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

5 - размер изображения

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

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

6 - Проблемы с обходом бюджета (быстрый обзор только для панели инструментов)

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

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

Чтобы проиллюстрировать эффект такого частого обхода одного параметра и то, как это может повлиять на бюджет обхода, на диаграммах ниже показана активность робота Google для URL-адресов, у которых этот параметр находится в правом нижнем углу (который нельзя сканировать или индексировать) по сравнению с Активность робота Google для наиболее важных разделов веб-сайта (в данном случае это подпапки для сервисных разделов, некоторые из которых имеют подстраницы под ними. Робот Googlebot обращается как к основной подпапке, так и к любым подстраницам в этом разделе).

Сканирование URL-адресов с параметром запроса выполняется в правом нижнем углу.

Команда разработчиков клиента недавно добавила параметр запроса (наряду с несколькими другими, которые я нашел) в консоль поиска Google, чтобы запросить Google не сканировать этот параметр. Я буду следить за этой диаграммой с течением времени, основываясь на последовательных файлах журналов, чтобы увидеть, если / когда это вступит в силу и насколько это повлияет.

Мне также нравится иметь общее количество показов Google-ботов в важных разделах веб-сайта под рукой за последние «х» дней:

В дополнение к техническим проблемам, связанным с бюджетом обхода контента, таким как параметры запроса, фасетная навигация и строки поиска, еще одна распространенная быстрая победа (для некоторых крупных сайтов) заключается в запуске аудита контента и объединении нескольких отдельных частей в контент, находящийся в аналогичном контенте. тема в темы. Слишком долго некоторые люди придерживались подхода «1 статья на ключевое слово», что приводило к гораздо большему количеству URL, чем необходимо. Рассмотрите возможность объединения и объединения таких статей в сплошные, более глубокие темы.

Это действительно все, что я сейчас настроил на уровне «обзора» на панели управления Kibana. Я намерен добавить еще несколько виджетов, но я считаю эту панель удобной и использую ее в сочетании с детализацией запросов по обнаруженным мной проблемам, а также в сочетании с Screaming Frog Log Analyzer (и, конечно, Screaming Frog сканирует - получите их платную версию, это дешево и стоит того!), данные GSC, данные GA, и сканирование от подобных SEMrush , Я тоже хочу хорошо пройти Глубокий обход , как я знаю, люди любят Барри Адамс (кого я уважаю за его технические знания SEO) как Deep Crawl.

Хотя это именно для SEO-визуализаций, я также использую Kibana для информационной панели безопасности, что выводит меня на номер 7…

7 - Проблемы безопасности

Хорошо, некоторые могут кричать в этот момент, что безопасность сайта НЕ является «проблемой SEO». Хотя я согласен с тем, что веб-безопасность - это область, которая требует очень специальных знаний и должна действительно выполняться людьми, которые оставляют и делают вдохи SQL-инъекции, XSS-хаки и RAT-ы ... Я чувствую довольно сильно, что как SEO мы можем (и должны!), Следите за наиболее распространенными проблемами безопасности, с которыми сталкиваются клиенты, особенно когда клиент использует популярную CMS.

Между прочим, вышеупомянутый мем взят из реальной ситуации, когда я видел британский, только на английском, веб-сайт, появляющийся в выдаче Google на китайском языке. Они были взломаны, и присутствовал сценарий, который подготавливал китайскую версию сайта с некоторыми очень сомнительными ссылками… но ТОЛЬКО если пользователь был агентом Googlebot.

Как и в случае с Dashboard для SEO, «Security Dash», который я создаю из файлов журналов, предназначен только для обзора. Это место, где можно обнаружить любые насущные проблемы, а затем копать глубже.

Попытки входа в WordPress

Приведенная выше таблица показывает количество посещений страниц wp-login.php ИЛИ страниц xmlrpc.php. Оба из них могут показать проблемы безопасности. Фактически, взглянув на диаграмму выше и учитывая, что это для британского сайта, где нет сотрудников, писателей или дизайнеров за границей, я бы сказал, что на это нужно смотреть. О, и я спросил клиента ... они тоже не летали между Россией и Бразилией.

Я считаю, что вышеизложенное полезно для иллюстрации «сомнительных» попыток входа в систему для клиентов, но также может быть полезна детализация до IP-адресов, пытающихся выполнить вход в систему:

С Kibana вы можете легко щелкнуть по стране (на приведенной выше карте), чтобы отфильтровать всю панель мониторинга (включая приведенную выше таблицу IP-адресов), а также выполнить сортировку по IP-адресу или щелкнуть по IP-адресу для фильтрации, чтобы показать только результаты с этого IP-адреса. С опциями экспорта это также позволяет довольно легко загружать IP-адреса для запрета. Возможно, в этом случае стоит подумать об использовании чего-то вроде премиальной версии Wordfence для блокировки доступа к wp-login.php в определенных странах.

Более дешевой альтернативой является создание списка IP-адресов для конкретной страны и либо блокирование всего доступа, либо разрешение доступа только к wp-admin из заданных стран с использованием службы, подобной этой, на countryipblocks.net (всегда будьте осторожны, чтобы НЕ заблокировать себя!).

Попытки Внедрения SQL

Это только ОЧЕНЬ базовая проверка, которая не обязательно перехватит все попытки и, скорее всего, вызовет ложные срабатывания. Однако я считаю это полезным. На приведенной ниже диаграмме показаны попадания, которые содержат в запросе строки, которые МОГУТ указывать на попытки внедрения MySQL (вы можете увидеть строки, которые я использовал в заголовке диаграммы, хотя я также включаю людей, чей запрос содержит 'sql'), или люди, пытающиеся получить доступ к файлам SQL, оставленным людьми - скажем, после установки инструмента или чего-то подобного.

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

Один IP явно появляется чаще других. Я немного покопался в этом IP и нашел еще много записей, (небольшой) выбор которых ниже:

Резюме - & Я впечатлен Intel NUC

Хорошо, вот и все, ребята! Надеюсь, вам понравился обзор визуализации приборной панели, которую я люблю использовать в Кибане. В целом, я впечатлен тем, насколько хорошо Intel NUC справляется со стеком ELK. Конечно, при фильтрации больших наборов данных это немного замедлится, но в целом это работает чертовски гладко и намного эффективнее, чем у моего настольного ПК.

Как насчет вас? Что-нибудь, что я пропустил в этом посте, что вы хотели бы извлечь из файлов журнала сервера, чтобы помочь с SEO? Комментарий ниже и дайте мне знать!

Похожие

Комментарии