График работы SEO, 1 июля 2022 г.

Это краткое изложение самых интересных вопросов и ответов из Google SEO Office Hours с Джоном Мюллером 1 июля 2022 года.

PageSpeed ​​Insights или Google Search Console — что точнее?

0:44 «Когда я проверяю свою оценку PageSpeed ​​Insights на своем веб-сайте, я вижу простое число. Почему это не соответствует тому, что я вижу в Search Console и отчете Core Web Vitals? Какое из этих чисел верное?»

По словам Джона: «[…] Нет правильного числа, когда речь идет о скорости — когда речь идет о понимании того, как ваш сайт работает для ваших пользователей. Я считаю, что в PageSpeed ​​Insights по умолчанию мы показываем одно число, представляющее собой оценку от 0 до 100, которая основана на ряде предположений, в которых мы предполагаем, что разные вещи немного быстрее или медленнее для пользователей. И на основании этого мы рассчитываем балл.

В Search Console у нас есть информация Core Web Vitals , основанная на трех показателях скорости, отклика и интерактивности. И эти числа, конечно, немного отличаются, потому что это три числа, а не одно число. Но также есть большая разница в том, как определяются эти числа. А именно, есть разница между так называемыми полевыми данными и лабораторными данными.

Полевые данные — это то, что видят пользователи, когда заходят на ваш сайт. И это то, что мы используем в Search Console. Это то, что мы также используем для поиска. Принимая во внимание, что лабораторные данные — это теоретическое представление вашего веб-сайта, где наши системы имеют определенные предположения, в соответствии с которыми они думают, что средний пользователь, вероятно, выглядит так, используя такое-то устройство и, возможно, с таким-то подключением. И на основе этих предположений мы оценим, какими могут быть эти цифры для среднего пользователя. Вы можете себе представить, что эти оценки никогда не будут на 100% правильными.

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

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

Короче говоря, опять же, нет правильного числа, когда дело доходит до любой из этих метрик. […] Но, скорее, есть разные предположения и разные способы сбора данных, и каждый из них немного отличается».

Почему Googlebot не может индексировать страницы на основе JavaScript?

4:19 «У нас есть несколько страниц клиентов, использующих Next.js без robots.txt или файла карты сайта. Теоретически робот Googlebot может получить доступ ко всем этим страницам, но почему индексируется только домашняя страница? В Search Console нет ошибок или предупреждений. Почему робот Googlebot не находит другие страницы?»

Джон сказал: «[…] Next.js — это среда JavaScript, а это означает, что вся страница создается с помощью JavaScript. Но общий ответ на все эти вопросы, например, почему Google не индексирует все – важно сначала сказать, что робот Googlebot никогда не будет индексировать все на веб-сайте. Я не думаю, что на любом веб-сайте нетривиального размера случится так, что Google отключится и проиндексирует полностью все. С практической точки зрения невозможно проиндексировать все во всей сети. Так что предположение о том, что в идеальной ситуации индексируется все, я бы оставил в стороне и сказал, что вы хотите, чтобы робот Googlebot сосредоточился на важных страницах.

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

И с этой структурой он не генерировал эти обычные HTML-ссылки. Таким образом, мы не могли понять, что есть еще что сканировать, больше страниц, на которые нужно смотреть. И это то, что вы можете исправить в том, как вы реализуете свой сайт JavaScript. У нас есть тонна информации на сайте Search Developer Documentation по JavaScript и SEO, в частности, по теме ссылок, потому что это время от времени всплывает. Существует множество креативных способов создания ссылок, и роботу Googlebot необходимо найти эти HTML-ссылки, чтобы заставить его работать. […]”

Кроме официальной документации Google, ознакомьтесь с Ultimate Guide to JavaScript SEO в нашем блоге. “

Влияют ли ссылки на страницы HTTP на SEO вашего сайта?

7:35 «Повлияет ли отрицательно на мою оценку SEO, если моя страница ссылается на внешний небезопасный веб-сайт? Так что по HTTP, а не по HTTPS».

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

Но, тем не менее, я понимаю, что вопрос звучит так: плохо ли, если я ссылаюсь на страницу HTTP вместо страницы HTTPS. И, с нашей точки зрения, это совершенно нормально. Если эти страницы находятся на HTTP, то это то, на что вы должны ссылаться. Это то, что пользователи ожидают найти. Нет ничего против ссылок на такие сайты. Для вашего веб-сайта нет недостатка в том, чтобы избегать ссылок на HTTP-страницы, потому что они старые или корявые и не такие крутые, как на HTTPS. Я бы не беспокоился об этом».

Стоит ли удалять файл отклонения?

10:16 «За последние 15 лет я дезавуировал в общей сложности более 11 000 ссылок. […] Ссылки, которые я отклонил, могли быть со взломанных сайтов или из бессмысленного, автоматически сгенерированного контента. Поскольку теперь Google утверждает, что у них есть лучшие инструменты, чтобы не учитывать эти типы взломанных или спам-ссылок в своих алгоритмах, должен ли я удалить свой файл отклонения? Есть ли какой-либо риск или недостаток в том, чтобы просто удалить его?»

Джон ответил: «[…] Отклонение ссылок всегда является одной из тех сложных тем, потому что кажется, что Google, вероятно, не сообщает вам полную информацию.

Но, с нашей точки зрения, […] мы прилагаем все усилия, чтобы не принимать во внимание эти ссылки. И мы делаем это, потому что знаем, что инструмент Disavow links — это своего рода нишевый инструмент, и SEO-специалисты знают о нем, но обычный человек, который управляет веб-сайтом, понятия не имеет об этом. И все те ссылки, которые вы упомянули, являются ссылками, которые любой веб-сайт получает на протяжении многих лет. И наши системы понимают, что это не то, что вы пытаетесь сделать, чтобы обмануть наши алгоритмы.

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

Что лучше блокировать сканирование с помощью файла robots.txt или метатега robots?

14:19 «Что лучше: блокировка с помощью robots.txt или использование метатега robots на странице? Как нам лучше всего предотвратить ползание?»

Джон: «[…] Недавно мы сделали выпуск подкаста об этом . Так что я бы проверил это. […]

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

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

Так что если мы не можем ползать, то мы не знаем, что теряем. И может случиться так, что мы скажем, ну, на самом деле, на эту страницу есть много ссылок. Может для чего пригодится. Мы не знаем. И тогда этот URL-адрес может появиться в результатах поиска без какого-либо содержимого, потому что мы не можем его просмотреть. Принимая во внимание, что с метатегом robots, если мы можем посмотреть на страницу, мы можем посмотреть на метатег и увидеть, например, есть ли там noindex. Затем мы прекращаем индексировать эту страницу, а затем полностью исключаем ее из результатов поиска.

Так что, если вы пытаетесь заблокировать сканирование, то, безусловно, robots.txt — это то, что вам нужно. Если вы не хотите, чтобы страница отображалась в результатах поиска, я бы выбрал ту, которую вам проще реализовать. На некоторых сайтах проще поставить галочку о том, что я не хочу, чтобы эта страница была в поиске, а затем добавить метатег noindex. На других, возможно, проще редактировать файл robots.txt. [Это] зависит от того, что у вас там есть».

Можно ли разместить один и тот же URL в нескольких файлах карты сайта?

16:40 « Есть ли какие-либо негативные последствия дублирования URL-адресов с разными атрибутами в ваших XML-картах сайта? Например, один URL-адрес в одной карте сайта с аннотацией hreflang и тот же URL-адрес в другой карте сайта без этой аннотации».

Джон сказал: «[…] С нашей точки зрения, это совершенно нормально. […] Это случается время от времени. У некоторых людей аннотации hreflang в файлах карты сайта специально отделены друг от друга, а затем у них есть обычный файл карты сайта для всего. И там есть некоторое совпадение.

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

Единственное, на что я хотел бы обратить внимание, это на то, чтобы у вас не было противоречивой информации в этих файлах карты сайта. Так, например, если с аннотациями hreflang вы говорите, что эта страница для Германии, а затем в другом файле карты сайта вы говорите, ну, на самом деле эта страница также для Франции, […] тогда наш системы могут сказать: ну, что здесь происходит? Мы не знаем, что делать с этим набором аннотаций. И тогда может случиться так, что мы выберем одно или другое.

Точно так же, если вы говорите, что эта страница последний раз изменялась 20 лет назад […], а в другом файле карты сайта вы говорите, ну, на самом деле, это было пять минут назад. Тогда наши системы могут посмотреть на это и сказать, что один из вас не прав. Мы не знаем, какой. Может быть, мы последуем за тем или другим. Может быть, мы полностью проигнорируем дату последней модификации. Так что это то, что нужно остерегаться.

Но в противном случае, если он просто упомянул несколько файлов карты сайта, и информация либо согласована, либо работает вместе, в том, что, возможно, у одного есть дата последнего изменения, у другого есть аннотации hreflang, это совершенно нормально ».

Как предотвратить индексацию встроенных видео-страниц?

19:00 «Я отвечаю за платформу воспроизведения видео, и наши встраивания иногда индексируются по отдельности. Как мы можем предотвратить это?»

Джон ответил: «[…] Я просмотрел веб-сайт, и это фреймы, которые включают упрощенную HTML-страницу со встроенным видеоплеером.

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

И есть один способ предотвратить это, который представляет собой довольно новую комбинацию с метатегами robots, которую вы можете сделать, а именно с метатегом indexifembedded robots вместе с метатегом noindex robots .

А во встроенной версии, то есть в файле HTML с видео непосредственно в нем, вы должны добавить комбинацию метатегов noindex плюс indexifembedded robots. И это будет означать, что если мы найдем эту страницу отдельно, мы увидим, что там нет индекса [тег]. Нам не нужно индексировать это.

Но со встроенным индексом это говорит нам, что […] если мы найдем эту страницу с видео, встроенным в общий веб-сайт, то мы сможем проиндексировать этот видеоконтент, а это означает, что отдельная HTML-страница не будет проиндексирована. Но HTML-страница с вставкой, с информацией о видео, нормально проиндексировалась бы. Так что это установка, которую я бы использовал там. И это довольно новый метатег robots, поэтому он нужен не всем. Потому что такое сочетание содержимого iframe или встроенного содержимого встречается редко. Но для некоторых сайтов это просто имеет смысл».