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

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

Стоимость внутренних ссылок

00:44 «Существует ли разное значение внутренних ссылок в шапке, футере или в контенте?»

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

Проблемы со сканированием

03:33 «После ноября [2021 года] Google [Core] обновил мой сайт [имеет некоторые проблемы с] сканированием. Некоторые ссылки [были просканированы, а] некоторые нет. […] Как я могу исправить [это]?»

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

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

Снижение количества проиндексированных страниц

05:47 «За последний год мы внесли много технических улучшений в сайт, и наши клиенты, кажется, довольны сайтом. Однако с конца октября количество страниц, проиндексированных Google, резко сократилось на 25 процентов [что составляет] около 500 000 страниц. Те, которые мы представили […], упали более чем на 50 процентов. […] Мы обнаружили, что […] если на странице продукта нет обзоров, валидатор схемы недоволен, потому что обзор не упоминается. […] Есть ли что-то, что мы упускаем […] или этого на самом деле достаточно, чтобы быть основной причиной?»

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

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

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

09:13 «Одна вещь, которую мы заметили, это был первый раз, когда мы видели Crawled [– в настоящее время] не проиндексированным. […] Мы чувствуем, что это нам что-то говорит, но мы не совсем уверены, как это интерпретировать».

Джон: Не думаю, что из этого можно что-то извлечь. Два статуса: Просканировано [ ‒ в настоящее время] не проиндексировано и Обнаружено [ ‒ в настоящее время] не проиндексировано, они по существу эквивалентны в том смысле, что мы знаем об URL-адресе. Мы подтвердили, что слышали об этом, но решили не индексировать. Это то, что мы ищем вместе с группами индексаторов, чтобы выяснить, является ли это общей проблемой? Потому что мы слышим все больше и больше сообщений об этом. Или он существенно более заметен, чем раньше? Потому что даже раньше мы всегда индексировали только часть веб-сайта. Но мы никогда не показывали это людям в Search Console. Мы ориентируемся на трафик, который вы получаете, а не на то, почему мы не индексируем отдельные страницы».

Деиндексированные страницы и специальные символы в URL

23:56 «Мы только что обнаружили, что с 13 января наши проиндексированные страницы упали более чем на 90 процентов. […] Можете ли вы дать нам несколько рекомендаций, какие аспекты мы можем выяснить, чтобы выявить проблему? […] Когда мы проверили образцы, мы заметили, что URL-адреса [которые просканировал Google] имеют некоторые необычные знаки, такие как вопросительные знаки [и] некоторые знаки плюса в URL-адресе, но наши фактические URL-адреса не имеют этих знаков. Это одна из необычных вещей, когда тебя замечают».

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

Когда дело доходит до специальных символов в URL-адресах, Джон добавил: «Что всегда происходит, так это то, что мы обнаруживаем множество URL-адресов для веб-сайтов. Если мы не считаем их важными, мы оставим их в нашем списке и в какой-то момент попытаемся их просканировать. Я подозреваю, что это просто случайные URL-адреса, которые мы обнаружили с течением времени. Мы пытаемся сканировать их время от времени, чтобы увидеть, что мы упустили, но это не является признаком проблемы веб-сайта, если мы также сканируем некоторые случайные URL-адреса».

Говоря о технических аспектах, которые могут привести к такой ситуации, Джон сказал: «Обычно основной вопрос касается общего качества веб-сайта , от которого зависит решение о том, индексировать ли отдельные URL-адреса. Это то, что также может измениться со временем. Меняется не столько качество вашего веб-сайта, сколько наше восприятие качества веб-сайта со временем. И это обычно главный элемент, который вступает в игру.

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

Свойства GSC и неконечные проиндексированные страницы

33:18 «Мы пытались создать свойства GSC для некоторых папок, характерных для нашей страны, чтобы лучше отслеживать их производительность. Мы не используем косую черту в конце наших URL-адресов. Таким образом, когда новое свойство папки добавляется в GSC, косая черта в конце автоматически добавляется к адресу, а данные для неконечной версии страницы индекса не захватываются и не сообщаются. Есть ли способ добавить папку в качестве свойства GSC и также получить статистику для неконечной проиндексированной страницы? “

Джон: «Нет, в настоящее время нет. С нашей точки зрения, страница без косой черты в конце — это просто страница. Если есть косая черта, значит это папка, это модель, которую мы использовали для Search Console. Таким образом , если у вас есть домашняя страница одного из разделов вашего веб-сайта и у нее нет косой черты в конце, то мы будем рассматривать ее как страницу на сайте более высокого уровня. На уровне домена вы, вероятно, увидите все это. Если вы хотите, чтобы данные отображались независимо, вам нужно извлечь их из свойства более высокого уровня в Search Console».

Восстановление после простоя сайта

34:29 «На моем веб-сайте, который посещает в среднем около 200 000 посещений в день, возникла техническая проблема. Всего два дня назад сайт был недоступен 14-15 часов. В то время как вчерашний трафик был примерно нормальным, сегодня многие наши страницы пропали из результатов поиска Google. Сайт был стабильным в течение последних 8 лет, и у нас никогда не было подобных проблем. Что ты порекомендуешь? “

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

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

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

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

В случае, если вы не можете сделать это, как здесь, я бы предположил, что это вернется автоматически. Я не думаю, что есть что-то ручное, что вам нужно делать. Мы просканируем эти страницы. Мы заметим, что там снова есть хороший контент. Мы проиндексируем их снова, [...] поймаем сигналы, которые у нас были раньше. По сути, он должен быть проиндексирован и ранжирован так же, как и раньше. Здесь не должно быть никаких долгосрочных проблем».

Миграция сайта

38:37 «Мы хотим перенести содержимое одного веб-сайта на два отдельных домена и разделить его. Что нам делать в GSC старых доменов? Какой домен мы должны указать в качестве получателя? Как сообщить об этом Google?»

Джон сказал: «В таком случае, когда вы разделяете или объединяете веб-сайты, вы не можете использовать инструмент «Смена адреса» в Search Console, потому что он основан на том факте, что перемещение является индивидуальным перемещением. с одного домена на другой домен. Как только вы разделяете или объединяете веб-сайты, это больше не является перемещением один к одному, это, по сути, то, что должно обрабатываться для каждого URL-адреса. Таким образом, для этих вещей, по сути, вам нужно просто правильно настроить перенаправления. Следуйте обычным рекомендациям, которые у нас есть для перемещения сайта, и имейте в виду, что настройка Search Console для изменения адреса, вероятно, не подходит для этого.

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

Внутренняя перелинковка и структура сайта

51:16 «Имеет ли смысл просматривать внутренние ссылки с важных страниц веб-сайта, чтобы увидеть, есть ли на них ссылки с других важных внутренних страниц, и [...] [удалить] ссылки на менее важные страницы, чтобы ссылки на важные страницы имеют больший вес?»

Джон ответил: «Это то, что вы можете сделать. Это немного сложно, потому что мы пытаемся быть умными в том, как мы обрабатываем внутренние ссылки. В частности, некоторые очень распространенные страницы, которые получают много ссылок, такие как страница «О нас» или «Условия обслуживания», связаны со всем веб-сайтом. Но в то же время мы понимаем, что это нормальный шаблон, и это не означает, что мы должны ранжировать страницу с Условиями обслуживания для всех, кто ищет название компании. Это то, где, с одной стороны, внутренние ссылки — это то, что вы можете контролировать. Но я бы не стал перегибать палку и сказать, что я удаляю ссылки на страницы, которые не считаю критическими. Потому что именно это произошло, когда мы ввели nofollow, о котором люди говорили: «О, мои Условия предоставления услуг [страница]» — все ссылки на него будут nofollow. Это ничего не меняет. Это много работы, и вы должны поддерживать ее вечно, но это ничего не меняет для вашего веб-сайта, так что это похоже на напрасную работу.

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

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

55:03 «А как насчет внутреннего PageRank, который довольно легко рассчитать? Вы бы порекомендовали сделать это, чтобы увидеть, какие страницы имеют наибольший вес от внутренних ссылок, или вы бы сказали, что это что-то да, в этом нет необходимости?»

Джон ответил: «[…] Аспект, который вы не можете здесь смоделировать, заключается в том, что отдельные страницы будут получать разные внешние ссылки, и это существенно влияет и на внутренний PageRank. Если все ссылаются на вашу страницу с Условиями обслуживания, то это внезапно становится чем-то, что имеет высокий PageRank. И PageRank — это то, что мы используем в наших системах, но мы используем множество других вещей. Это интересный гаджет с технической точки зрения, но я не считаю его чем-то сверхкритическим с практической точки зрения. Вам больше нравится возиться с цифрами и играть с графиками — уверен, что вы можете это вычислить. Я бы не стал рассматривать это как то, что один к одному отражается в Google».