5 способов использовать лог-файлы для SEO с Джерри Уайтом

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

Об этом мы и поговорим сегодня с человеком с более чем 20-летним опытом работы в индустрии SEO, работающим с брендами и агентствами, включая BBC, Just Eat и Rise at Seven. Добро пожаловать в подкаст In Search SEO, Джерри Уайт.

В этом выпуске Джерри рассказывает о пяти способах использования лог-файлов для SEO, в том числе:

• Посмотрите, как Google смотрит на ваш сайт
• Параметры
• Есть ли поддомены, потребляющие ваш краулинговый бюджет?
• Файлы JavaScript и CSS
• Коды ответов

Джерри: Эй, рад быть здесь.

Д: Хорошо, что ты на связи. Вы можете найти Джерри, выполнив поиск Gerry White на LinkedIn. Итак, Джерри, должен ли каждый оптимизатор использовать лог-файлы?

G: Нет, я знаю, что это звучит спорно, когда я говорю, что лог-файлы содержат огромное количество информации. Но, честно говоря, в большинстве случаев это убывающая отдача. А часто вообще можно найти много информации, прежде чем залезть в лог-файлы. Под этим я подразумеваю, что если вы посмотрите на информацию Google Search Console, там есть огромное количество информации. Когда я просматривал файлы журналов, я сначала исчерпал много других мест. Я всегда рекомендую сканировать сайт с помощью чего-нибудь вроде Screaming Frog или любого другого настольного сканера, который у вас есть, а затем заглянуть в консоль поиска Google, прежде чем вы начнете просматривать файлы журналов.

Причина, по которой я это говорю, и причина, по которой я звучу почти как антилог-файлы, когда собираюсь говорить о том, насколько они полезны, заключается в том, что с ними на самом деле довольно сложно работать на начальном этапе. И действительно требуется немного навыков, знаний и опыта, чтобы действительно получить к ним доступ и даже получить к ним доступ. Но одна замечательная вещь сегодня заключается в том, что теперь у нас действительно больше доступа к файлам журналов, чем когда-либо прежде. Изначально, когда я только начинал, у нас не было ни Google Analytics, ни какого-либо другого аналитического программного обеспечения, которое есть сейчас. Анализ файла журнала — это то, как мы смотрели, как люди посещают веб-сайты. Теперь мы редко смотрим в лог-файлы на то, как люди смотрят на веб-сайты, если только мы не делаем что-то с информационной безопасностью. Или мы делаем что-то, чтобы диагностировать что-то действительно странное и замечательное.

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

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

Д.: Итак, сегодня вы поделились пятью способами, которыми поисковая оптимизация должна использовать лог-файлы. Начнем с первого, посмотрим, как Google смотрит на ваш сайт.

1. Посмотрите, как Google смотрит на ваш сайт

G: Да, Google довольно непредсказуем, почти как непослушный ребенок. Это странно, потому что, хотя я говорю, что мы можем смотреть на сайты и можем использовать инструменты сканирования, чтобы посмотреть, как Google должен смотреть на сайт, мы часто удивляемся, обнаружив, что Google стал одержим одним набором страниц или по какому-то странному маршруту куда-то. Или, совсем недавно, я работал в течение последнего года для супермаркета под названием Odor, и одна из вещей, которую мы обнаружили, заключалась в том, что бот Google очень внимательно следил за конфигурацией аналитики и создавал из нее искусственные ссылки. Google находит битые ссылки. И долго пытался понять, почему он находит десятки тысяч 404, которых вообще нет на странице. Но оказалось, что он просматривает конфигурацию аналитики и создает ссылку на нее. Итак, мы смотрим, какое влияние это оказало. И если мы посмотрим на тот факт, что Google находит все эти ошибки 404, это не может быть серьезной проблемой. Но теперь мы хотим знать, сколько времени он тратит на эти ошибки 404, и если мы исправим эту маленькую проблему, будет ли это означать, что сканирование остальной части сайта увеличится на 20-30%? Какая возможность, если мы исправим это там? Все дело в том, чтобы понять, почему Google так смотрит на сайт и что он находит, чего на самом деле не должен находить.

2. Параметры

Еще одна вещь, на которую мы часто обращаем внимание, — это параметры. Я не знаю, знаете ли вы, но SEO-специалисты всегда ссылаются на каноническую версию страницы. Я имею в виду, что часто существует несколько версий страницы, которые иногда имеют какое-то внутреннее отслеживание или внешнее отслеживание. Существует так много способов, которыми мы можем ссылаться на страницу, и часто, например, продукт может находиться в нескольких местах на сайте. Хорошим примером этого является то, что я работал над сайтом, который был Magento. И каждый продукт, казалось, находился в каждой отдельной категории, поэтому было удивительно, когда мы узнали, что существует около 20 версий каждого продукта, и каждый продукт можно сканировать. Отсюда мы знали, что Google также тратит огромное количество времени на сканирование сайта. И что интересно, если вы удалите продукт, Google скажет: «О, но у меня есть 19 других версий этого продукта», поэтому потребуется некоторое время, чтобы фактическая страница почти исчезла, если вы использовали 404 или что-то в этом роде из-за того, как работает Google. Google увидит, что это каноническая версия этой страницы. Но если вы уберете каноническую версию, то он начнет использовать другие. И это вид информации, которую дает нам файл журнала. Возможность для нас смотреть на сайт так, как это делает Google.

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

То, как Google смотрит на вещи, которые нужны нам, администраторам серверов и всем желающим, заключается в том, чтобы сервер был максимально быстрым и эффективным. Опять же, возвращаясь к лог-файлам, в настоящее время мы не могли эффективно использовать лог-файлы в течение многих лет. Потому что с CDN вы часто обнаружите, что будет несколько мест, в которых будет открываться страница. И у CDN часто не было самого файла журнала. Итак, мы рассмотрим все эти разные места и посмотрим, какая нагрузка на этот сервер и какая нагрузка на этот сервер. И мы пытаемся собрать все воедино, и лог-файлы будут в другом формате. Теперь, когда мы имеем дело с CDN, мы действительно можем начать понимать эффективность CDN. Внезапно на такие вещи, как PageSpeed, сильно повлиял и улучшился тот факт, что если мы используем файлы журналов, мы можем начать понимать тот факт, что изображение, например, канонизирует изображения, поэтому, если одно изображение используется на нескольких страницах, как пока URL-адреса согласуются, CDN работает, и Google лучше его сканирует. Да, есть так много разных способов, которыми файлы журналов помогают улучшить PageSpeed, кэширование и более эффективное обслуживание пользователей и поисковых систем.

Д.: Я повторяю ваши пять пунктов, которыми вы хотели поделиться. И есть различные их элементы, которыми вы уже поделились. Вы напоминаете мне кого-то, кому я могу задать один вопрос, и они дадут мне 15-минутный эпизод подкаста, не задавая никаких дополнительных вопросов. Так что есть один человек, который, вероятно, может сделать это, даже больше, чем вы. И это, вероятно, Дуэйн Форрестер. Мы с Дуэйном шутили, что он делает это, я просто задаю ему один вопрос, а я ухожу и просто оставляю его делиться контентом до конца эпизода. Но вы немного говорили о параметрах. Я не знаю, затронули ли вы пункт номер три, а именно обнаружение субдоменов, потребляющих краулинговый бюджет, а их быть не должно.

3. Используют ли поддомены ваш краулинговый бюджет?

G: На самом деле это восходит к Just Eat. В какой-то момент мы обнаружили, что веб-сайт реплицирован на несколько разных поддоменов, и все они доступны для сканирования. Что интересно, такие инструменты, как Citrix, не отображали их. И причина, по которой они этого не сделали, заключалась в том, что все это было канонизировано. Поэтому, когда мы обнаружили, что хотя эти дубликаты и существуют, Google тратит от 60 до 70% своего бюджета на сканирование этих поддоменов. И из-за того, что они не кэшировались таким же образом из-за CDN и других технологий, это фактически создавало большую нагрузку на сервер. Так что это было чем-то захватывающим для нас, потому что мы просто игнорировали это как проблему, которую нужно решить когда-нибудь в самом будущем. Потому что мы знали о проблеме. Мы знали, что существует своего рода проблема, и я говорил об этом. Но я лишила его приоритета, пока мы не начали просматривать лог-файлы.

Мы видели, что Google тратит на это много энергии, времени и ресурсов. Какую нагрузку на сервер он создает? Насколько сильно это повлияло? И мы не могли понять, насколько велика была нагрузка на сервер из-за того, что сервер не мог интерпретировать разные источники. Так что было удивительно, что когда мы получили лог-файлы, мы смогли значительно повысить надежность веб-сайта. Итак, мы знали о поддоменах, мы просто не знали, насколько это проблема, пока не начали изучать лог-файлы. И вдруг мы увидели, что это нужно исправлять как можно скорее. Это была одна из тех вещей, которые мы знали, как исправить, это была просто расстановка приоритетов. Он был в конце очереди и поднялся до второго места.

4. Файлы JavaScript и CSS

Д: Вы упомянули канонизацию, но также сказали, что, в частности, файлы JavaScript и CSS могут быть проблемой. Почему это?

G: Одна из вещей, которую мы часто делаем, — это взламываем кеш, добавляя параметр в файл CSS. Причина, по которой мы делаем это, заключается в том, что происходит, если вы используете CDN или что-то подобное, заключается в том, что всякий раз, когда вы обновляете CSS, создаете новые страницы или что-то еще, проблема заключается в том, что у вас есть файл CSS, который кэшируется и новые страницы не смогут его использовать. И у нас долгое время кеша для всех этих разных файлов JavaScript и CSS. Итак, на странице, как только мы добавим что-то, что требует обновления JavaScript или CSS, вы просто немного измените параметр внутри него. Оттуда мы должны были убедиться, что все разные серверы используют одну и ту же версию параметров в будущем. И это было то, где, если вы работаете в нескольких разных командах, на нескольких разных веб-сайтах, один лучший JavaScript, который поддерживает все это, мы всегда следили за тем, чтобы это была правильная версия. И файлы журналов были одним из способов убедиться, что все разные страницы последовательно обращаются к правильной версии JavaScript, потому что, возможно, нам нужно было обновить ключ API или что-то подобное. Было так много разных способов, которыми мы должны были это сделать. И это было огромной задачей для разработчиков.

Одна из вещей, которую мы просматривали в лог-файлах, заключалась в том, был ли удар по старому, откуда он был поражен, и можем ли мы это исправить? Мы также обнаружили, что существует много разных способов записи пути к файлу JavaScript. Например, это было в поддомене, если мы использовали другое имя хоста, потому что, что интересно, если вы работаете с несколькими разными веб-сайтами, вы часто обнаруживаете, что существуют разные URL-адреса или разные доменные имена, которые фактически обращаются к одному и тому же серверу. И часто, если вы используете CDN или подкаталог, иногда это может быть очень непоследовательным. А с точки зрения пользователя, если вы открываете один и тот же файл JavaScript шестью или семью разными способами в рамках путешествия, значит, вы загружаете его шестью или семью разными способами. И хотя это может показаться не таким уж большим, в совокупности это добавляет несколько мегабайт к вашему путешествию. И это, конечно, замедляет весь процесс и делает серверы менее эффективными. И это еще не все. Поэтому следите за тем, чтобы всегда использовалась правильная версия JavaScript, CSS и других фрагментов. А также убедитесь, что нет причин скрывать JavaScript с параметрами или чем-то еще. Существует так много способов создания ловушек для пауков, которые включают в себя файлы JavaScript, где, например, что-то помечается, где, возможно, они не используют правильную абсолютную ссылку на JavaScript. Таким образом, он находится в другом каталоге, чем в другое время. Удивительно, как много разных способов определить, когда JavaScript загружается немного по-разному на разных страницах. Так что да, это очень просто. Но это удивительно дорого, когда дело доходит до анализа.

5. Коды ответов

D: Также убедитесь, что коды ответов доставляются так, как вы хотите. Примером этого является то, что Google иногда видит или не видит TOS, что должно или не должно быть. Так почему же это произошло?

G: Опять же, мы всегда посещаем веб-страницы, используя один и тот же браузер, одну и ту же технологию, один и тот же опыт и все такое. Я стараюсь убедиться, что использую другие инструменты, отличные от тех, которые я обычно использую, поскольку все проводят аудит Screaming Frog, поэтому я стараюсь использовать всевозможные кусочки. Но мы всегда притворяемся, что мы вроде как компьютер. Поэтому мы никогда не притворяемся, что мы Googlebot, мы никогда не притворяемся, что мы все эти разные вещи. Итак, если вы посмотрите, как боты Google получают доступ к определенному файлу с другого IP-адреса… многие технологии, такие как CloudFlare, если вы притворяетесь, что вы Googlebot, и пытаетесь получить к нему доступ с помощью Screaming Frog, он знает, что вы не Googlebot, вы на самом деле это. И поэтому он относится к вам иначе, чем вы относитесь к Googlebot. И так часто серверы настроены на предварительный рендеринг, чтобы делать все по кусочкам. И это просто гарантия того, что в этот момент все получат правильный код ответа от сервера.

И это кажется довольно простым, но когда вы расширяетесь по всему миру… Когда у вас есть гео-перенаправления, если пользователь или поисковая система не могут получить доступ к определенной странице, потому что кто-то вставил гео-перенаправление, чтобы сказать, что если вы посетите это веб-сайт из Испании, затем перейдите и загрузите этот подкаталог... Поэтому он не может просматривать корневые версии или альтернативные версии. Вот почему такие вещи, как правильные коды ответов, абсолютно важны. И удивительно, как часто вы проходите через эти вещи и считаете, что все настроено правильно. Потому что снова и снова мы знаем, как это должно быть настроено. Мы даем это кому-то, кто-то это интерпретирует, другой реализует, а кто-то проходит через это. А затем кто-то еще нажимает кнопку на CDN, которая говорит: «О, мы можем геолоцировать кого-то в этом конкретном месте». Дело не столько в том, что какой-то один человек сделал что-то не так, сколько в том, что в цепочке есть что-то, что фактически слегка ее разорвало.

Рассол Парето - низко висящие фрукты

D: Давайте закончим рассолом Парето. Парето говорит, что вы можете получить 80% результатов, прилагая 20% усилий. Какое SEO-направление вы бы порекомендовали, чтобы получить невероятные результаты при скромных усилиях?

G: На данный момент мне больше всего нравится то, что у меня есть очень простая панель инструментов Google Data Studio, которая позволяет мне взглянуть на то, что я называю низко висящими фруктами. Теперь все ненавидят модное словцо бинго. Но это мое дело, когда я смотрю на вещи, которые не совсем ранжируются так, как должны. Я просматриваю все ключевые слова, по которым они ранжируются для определенного набора страниц, или рецептов, или продуктов, или чего-то еще. Хороший пример: на данный момент я работаю с десятками тысяч продуктов, я просматриваю все страницы, которые получили высокие показы, но они могут быть на позиции шесть, и я могу поднять их до позиции 3. И в девяти случаях из десяти вы можете сделать это, просто убедившись, что теги заголовков улучшились, а внутренние ссылки улучшились. Очень простая вещь, чтобы узнать, какие из ключевых слов с большим объемом поиска можно увеличить еще немного, чтобы увеличить рейтинг кликов.

D: Я был вашим хозяином, Дэвид Бейн. Вы можете найти Джерри, выполнив поиск Gerry White на LinkedIn. Джерри, большое спасибо за участие в подкасте In Search SEO.

Г: С удовольствием. Спасибо за ваше время.

Д: И спасибо, что выслушали. Ознакомьтесь со всеми предыдущими эпизодами и подпишитесь на бесплатную пробную версию платформы Rank Ranger.