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

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


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

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

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

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

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

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

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

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

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

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

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

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

READ  Могут ли эти альтернативные методы SEO стать ключом к успешному ранжированию?

Вы можете перепроверить скорость сканирования 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 для вещей, которые вы действительно не хотите сканировать.

READ  Шагомер для Андроид: топ-10 лучших и самых точных приложений, какое скачать

Попытайтесь выяснить, это больше похоже на тонкую вещь […] которые вы предпочитаете индексировать, а затем использовать для этого 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 отдельно. […] Я бы перевернул вопрос и сформулировал его так: что вы хотите, чтобы произошло?

READ  Amazfit выпустит смарт-часы GTS 4 Mini с пульсоксиметром, датчиком ЧСС и GPS • Interpult Studio

И если вы хотите, чтобы ваши обычные веб-страницы индексировались с содержимым файла 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, указывающий на вашу предпочтительную версию, что-то в этом роде. […] Я бы не стал слепо предполагать, что только потому, что он находится в структурированных данных, он не будет найден, и я бы не стал слепо предполагать, что только потому, что он находится в структурированных данных, он будет найден.

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





Source link