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

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

Могу ли я использовать два кода результата HTTP на странице?

1:22 «[…] Теоретически возможно иметь на странице два разных кода результатов HTTP, но что Google будет делать с этими двумя кодами? Увидит ли их Google? И если да, то что будет делать Google? Например, 503 плюс 302».

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

И теоретически у вас все еще может быть два кода результата HTTP или больше, если они являются перенаправлениями, ведущими на какую-то конечную страницу. Так, например, у вас может быть перенаправление с одной страницы на другую. Это один код результата. А затем на этой другой странице вы можете отобразить другой код результата. Так что это может быть редирект 301 на страницу 404 […]. И с нашей точки зрения, в тех цепочках ситуаций, когда мы можем следовать перенаправлению, чтобы получить окончательный результат, мы, по сути, просто сосредоточимся на этом конечном результате.

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

Улучшает ли использование CDN рейтинг, если мой сайт уже работает быстро в моей основной стране?

2:50 «[…] Мы получаем большую часть нашего трафика из определенной страны. Мы разместили наш сайт на сервере, расположенном в этой стране. Вы предлагаете разместить весь наш веб-сайт за CDN, чтобы повысить скорость страницы для пользователей во всем мире, или в нашем случае это не требуется?»

Джон ответил: « Я не думаю, что это сильно повлияет на Google с точки зрения SEO.

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

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

Возможно, я должен уточнить одну вещь: если сканирование Google действительно, очень медленное, то, конечно, это может повлиять на то, сколько мы можем сканировать и индексировать с веб-сайта […]. На самом деле я не видел в этом проблемы в отношении любого веб-сайта, размер которого не превышает миллионы и миллионы страниц […].

Вы можете перепроверить скорость сканирования Google в Search Console и статистику сканирования. И если это выглядит разумно, даже если это не очень быстро, то я бы не стал об этом беспокоиться».

Должен ли я запрещать запросы API, чтобы уменьшить сканирование?

5:20 «[…] В настоящее время наш сайт тратит около 20% краулингового бюджета на поддомен API, еще 20% — на миниатюры изображений видео. Ни в одном из этих субдоменов нет контента, который является частью нашей стратегии SEO. Должны ли мы запретить сканирование этих поддоменов или как обнаруживаются или используются конечные точки API?»

Как сказал Джон, «[…] Во многих случаях конечные точки API используются JavaScript на веб-сайте , и мы будем отображать ваши страницы. И если они получат доступ к API, который находится на вашем веб-сайте, мы попытаемся загрузить контент из этого API и использовать его для рендеринга страницы.

И в зависимости от того, как настроен ваш API и как настроен ваш JavaScript, нам может быть сложно кэшировать эти результаты API, а это означает, что, возможно, мы сканируем множество этих запросов API, чтобы попытаться получить обработанную версию. ваших страниц, чтобы мы могли использовать их для индексации. Так что это обычно место, где это обнаруживается. И это то, чему вы можете помочь, убедившись, что результаты API можно кэшировать, что вы не вводите временные метки в URL-адреса […], когда используете JavaScript для API […].

Если вас не волнует контент, возвращаемый этими конечными точками API, то, конечно, вы можете заблокировать сканирование всего этого субдомена с помощью файла robots.txt. И это по существу заблокирует все эти запросы API.

[…] Прежде всего вам нужно выяснить, являются ли эти результаты API […] частью […] важного контента, который я хочу проиндексировать из Google? А раз так, то наверное не стоит блокировать сканирование. Но если […] он […] генерирует что-то […] не критичное для ваших страниц […], то, возможно, стоит перепроверить, как это выглядит, когда они заблокированы.

И один из способов перепроверить это — создать отдельную тестовую страницу, которая не вызывает API или использует неработающий URL-адрес для конечной точки API. […] Вы видите, как эта страница на самом деле отображается в моем браузере? Как это отображается для Google?»

Должен ли я использовать rel="nofollow" для внутренних ссылок?

8:05 «Уместно ли использовать атрибут nofollow для внутренних ссылок, чтобы избежать ненужных запросов сканера к URL-адресам, которые мы не хотим сканировать или индексировать?»

Вот что ответил Джон: «[…] Я думаю, что по большей части нет смысла использовать nofollow для внутренних ссылок. Но если это то, что вы хотите сделать, сделайте это.

В большинстве случаев я попытаюсь сделать что-то вроде использования rel=canonical , чтобы указать на URL-адреса, которые вы хотите проиндексировать, или использовать robots.txt для вещей, которые вы действительно не хотите сканировать.

Попытайтесь выяснить, это больше похоже на тонкую вещь […], которую вы предпочитаете проиндексировать, а затем использовать для этого rel=canonical? Или это что-то там, где вы говорите — на самом деле, когда Googlebot получает доступ к этим URL-адресам, это вызывает проблемы на моем сервере. Это вызывает большую нагрузку. Это делает все очень медленным. Это дорого или что у вас есть.

И в этих случаях я бы просто запретил сканирование этих URL-адресов. […] С rel=canonical, очевидно, нам сначала нужно просканировать эту страницу, чтобы увидеть rel=canonical. Но со временем мы сосредоточимся на каноническом, который вы определили. И мы будем использовать его в первую очередь для сканирования и индексации».

Есть ли способ заставить дополнительные ссылки отображаться?

16:02 «Существует ли какая-либо стратегия, с помощью которой нужные страницы могут отображаться в качестве ссылки на сайт в результатах поиска Google?»

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

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

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

Наш сайт встраивает PDF-файлы с фреймами, должны ли мы распознавать текст?

17:14 «Наш веб-сайт использует iframe и скрипт для встраивания PDF-файлов на наши страницы и наш веб-сайт. Есть ли какое-либо преимущество в том, чтобы взять текст OCR из PDF и вставить его куда-нибудь в HTML-код документа для целей SEO, или Google просто проанализирует содержимое PDF с тем же весом и релевантностью для индексации контента?»

Джон ответил: «[…] Похоже, вы хотите взять текст PDF и [...] скрыть его в HTML для целей SEO. И это то, что я бы точно не рекомендовал делать. Если вы хотите, чтобы содержимое индексировалось, сделайте его видимым на странице.

[…] Мы пытаемся извлечь текст из PDF-файлов и проиндексировать его для самих PDF-файлов. С практической точки зрения то, что происходит с PDF-файлом, — это один из первых шагов: мы конвертируем его в HTML-страницу и пытаемся индексировать ее как HTML-страницу. […] То, что вы делаете, это […] iframe непрямой HTML-страницы. А когда дело доходит до фреймов, мы можем учитывать этот контент для индексации на основной странице. Но также может случиться так, что мы все равно проиндексируем PDF отдельно. […] Я бы перевернул вопрос и сформулировал его так: чего вы хотите, чтобы произошло?

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

И тогда возникает вопрос, хотите ли вы, чтобы эти PDF-файлы индексировались отдельно или нет? Иногда вы хотите, чтобы PDF-файлы индексировались отдельно. И если вы хотите, чтобы они индексировались отдельно, то ссылка на них — это здорово.

Если вы не хотите, чтобы они индексировались отдельно, то также можно использовать robots.txt для блокировки их индексации. Вы также можете использовать noindex [? x-robots ?] HTTP-заголовок. Это немного сложнее, потому что вы должны использовать это как заголовок для файлов PDF, если вы хотите, чтобы эти файлы PDF были доступны в iframe, но на самом деле не индексировались».

Сканирует ли Google URL-адреса в разметке структурированных данных?

23:24 «Сканирует ли Google URL-адреса, расположенные в разметке структурированных данных, или Google просто сохраняет данные?»

Джон объяснил, что «по большей части, когда мы смотрим на HTML-страницы, если мы видим что-то похожее на ссылку, мы можем пойти и попробовать этот URL-адрес. […] Если мы найдем URL-адрес в JavaScript, мы можем попытаться подобрать его и попытаться использовать. Если мы находим ссылку в текстовом файле на сайте, мы можем попытаться просканировать ее и использовать. Но это не совсем нормальная ссылка.

[…] Если вы хотите, чтобы Google отключился и просканировал этот URL-адрес, убедитесь, что к этому URL-адресу есть естественная HTML-ссылка с четким якорным текстом, что вы предоставляете некоторую информацию о целевой странице.

Если вы не хотите, чтобы Google сканировал этот конкретный URL-адрес, то, возможно, заблокируйте его с помощью robots.txt или на этой странице используйте rel=canonical, указывающий на вашу предпочтительную версию, что-то в этом роде. […] Я бы не стал слепо предполагать, что только потому, что он находится в структурированных данных, он не будет найден, и я бы не стал слепо предполагать, что только потому, что он находится в структурированных данных, он будет найден.

[…] Вместо этого я бы сосредоточился на том, что вы хотите, чтобы там произошло. Если вы хотите, чтобы это было видно как ссылка, сделайте это ссылкой. Если вы не хотите, чтобы он сканировался или индексировался, заблокируйте сканирование или индексирование [...]».