Переезд сайта на https в гугл: переезд сайта на HTTPS в Яндекс Вебмастер и Google Search Console

Наброски

1. Предварительный ход

   Перед фактическим переездом вам нужно немного подготовиться, это включает в себя выбор типа сертификата SSL, который вы хотите подготовить на случай, если вам нужно будет приобрести его заранее.

2. День переезда

   Пора получить / купить, установить и проверить сертификат SSL, исправить проблемы со смешанным контентом, настроить перенаправления и проверить стороннюю интеграцию.

3. Пост переезд

   Вскоре после первого перемещения проверьте наличие новых проблем.Затем, когда будете готовы, настройте сайт так, чтобы он всегда использовал HTTPS.

4. Все больше и больше

   Для студентов A +: устранение дополнительных проблем и аналогичные улучшения безопасности.

Переход с HTTP на HTTPS: пошаговое руководство по предотвращению ошибок SEO и увеличению органического трафика Google

Существует множество причин для перевода сайта с HTTP на HTTPS: безопасность, потенциальное повышение рейтинга Google, и вскоре (с Chrome 62) Chrome будет предупреждать пользователей о том, что сайт небезопасен, когда они заполняют форму (например, поиск поле или подписка по электронной почте).Это новейшее оповещение в сочетании с преимуществами Google SEO позволило сократить сроки миграции для многих сайтов.

Существует множество деталей и контрольных списков для инженерной стороны вещей, но иногда особенности SEO могут упускаться из виду. Ниже приведен контрольный список HTTP to HTTPS, в котором основное внимание уделяется соображениям SEO: планированию, миграции и мониторингу после миграции. (Этот пост не включает в себя все задачи, не связанные с поисковой оптимизацией, необходимые для перехода с HTTP на HTTPS. Он предназначен для расширения существующего плана технической миграции, а не для его замены.)

Контрольный список сопровождается объяснением каждой задачи и списком часто задаваемых вопросов.

Вы также можете скопировать этот шаблон Google Sheets, чтобы создать свой собственный внутренний контрольный список и план тестирования QA.

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

• С помощью Keylime Toolbox Query Analytics вы можете агрегировать данные запросов HTTP и HTTPS из Google Search Console и отслеживать тенденции кликов, рейтинга, показов и рейтинга кликов с течением времени (в совокупности, на уровне отдельных запросов и для категорий запросы).

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

А ниже вы можете увидеть пример тенденций ранжирования для самых популярных ключевых слов за тот же диапазон дат.

Например, на приведенной ниже диаграмме вы можете видеть, что миграция, похоже, идет хорошо с точки зрения сканирования роботом Googlebot: большинство просканированных URL-адресов возвращают 200, хотя количество 301-х резко увеличилось, когда миграция началась, и было нет увеличения кодов состояния ошибок (например, 404 или 500).

Контрольный список для миграции

Каждая ссылка в контрольном списке ведет к разделу этого документа с более подробной информацией.

• Эффективность сканирования: если сайт большой и сканирование особенно неэффективно, рассмотрите возможность внедрения элементов эффективности сканирования перед началом миграции (чтобы процесс переиндексации происходил как можно быстрее).
• Перенаправления HTTP на HTTPS: 301 перенаправление URL-адресов HTTP на URL-адреса HTTPS
• Существующие перенаправления: в максимально возможной степени включите все существующие правила перенаправления в начальное перенаправление на конечную цель (это в основном не связано с перенаправлением HTTP на HTTPS, но это перенаправление добавит к любым существующим цепочкам перенаправления, и Google будет сканировать только до 5 перенаправляет в цепочке)
• Внутренние ссылки: обновите все внутренние ссылки на URL-адреса HTTPS, если возможно.
• Метаданные и структурированная разметка: обновите метаданные и структурированную разметку, включая:
Ресурсы
• : убедитесь, что все ресурсы перемещены на HTTPS, а ссылки обновлены в исходном коде страницы
• Google Search Console: проверьте свойство https в Google Search Console и выполните следующие действия:
• Протокол исключения роботов:
  • Убедитесь, что HTTPS robots.txt содержит то же содержимое, что было указано ранее для HTTP (и не запрещает все)
  • Убедитесь, что файл HTTP robots.txt либо перенаправляет, либо 404 (и убедитесь, что он не запрещает все)
  • Убедитесь, что страницы HTTPS не имеют атрибутов мета-индекса noindex.
• Веб-аналитика: убедитесь, что используются теги веб-аналитики (и других сторонних поставщиков) (это может происходить автоматически)
• XML-файлы Sitemap:
  • Отправьте XML-файл Sitemap для URL-адресов на HTTPS
  • Оставить существующий XML-файл Sitemap для HTTP (для отслеживания показателей индексации для обоих)
  • Удалите старую ссылку на файл Sitemap из файла robots.txt (теперь размещенный на HTTPS) и замените его ссылкой на новый
  • Убедитесь, что версии файлов Sitemap XML как HTTP, так и HTTPS являются полными и каноническими.

Чего нельзя делать

• Не блокируйте URL-адреса HTTP с помощью robots.txt — если вы заблокируете URL-адреса HTTP с помощью robots.txt, поисковые системы не смогут видеть перенаправления на URL-адреса HTTPS, а также PageRank и другие сигналы ценности. т быть переданы.
• Не удаляйте URL-адреса HTTP из индекса Google с помощью инструмента удаления URL-адресов — поскольку Google повторно сканирует URL-адреса HTTP и получает код статуса 301, они начнут сканировать URL-адреса HTTPS и заменять URL-адреса HTTP в индексе.Если вы запросите удаление HTTP, Google также удалит HTTPS. (Обратите внимание, что то же самое происходит, если вы пытаетесь удалить URL-адреса без www с помощью этого инструмента. URL-адреса www также удаляются в этом случае.) Инструмент удаления URL-адресов следует использовать только тогда, когда вы хотите, чтобы страница (и все варианты URL-адресов которые загружают эту страницу), чтобы удалить из индекса.

Контрольный список для мониторинга

• Состояние индексирования консоли поиска Google: отслеживайте статистику индексирования XML Sitemap консоли поиска Google, чтобы убедиться, что индексирование снижается по HTTP и увеличивается по HTTPS.(Или, если полные канонические XML-файлы Sitemap недоступны, проследите за отчетами о статусе индексирования в Google Search Console.
• Ошибки сканирования в Google Search Console: отслеживайте отчеты об ошибках сканирования в Google Search Console по протоколам HTTP и HTTPS.
• Ручные проверки: выборочная проверка того, что все на месте (перенаправления, канонические атрибуты и т. Д.), Путем сканирования сайта, с помощью инструмента Google Search Console Fetch as Google и путем ручной загрузки страниц.
• Трафик и ранжирование: отслеживайте органический поисковый трафик в веб-аналитике, чтобы убедиться, что трафик стабильный или только временно снижается, поскольку URL-адреса HTTP деиндексированы, а URL-адреса HTTPS индексируются (это непрерывный процесс, который не происходит сразу).Отслеживайте рейтинги и другие данные, ориентированные на SEO, в Google Search Console.
• Отображение результатов поиска: вручную проверьте отображение результатов поиска, чтобы убедиться, что все выглядит правильно, поскольку URL-адреса HTTPS проиндексированы.

Дополнительные шаги мониторинга Keylime Toolbox

С помощью Keylime Toolbox вы также можете отслеживать следующее:

• Поведение робота Googlebot при сканировании: отслеживайте, как робот Googlebot сканирует как HTTP, так и HTTPS (какие URL сканируются, какие коды ответов получает робот Googlebot).Эти данные доступны только в том случае, если вы используете Crawl Analytics и загружаете файлы журналов сервера для обработки.
• Ошибки, сообщаемые Google: загрузите полный список предоставленных Google ошибок сканирования как для HTTP, так и для HTTPS (по сравнению с меньшей выборкой, доступной в пользовательском интерфейсе Google Search Console), а также данные источника ссылок для каждой ошибки.
• SEO-ориентированные метрики запросов: отслеживание агрегированного рейтинга HTTP и HTTPS и трафика с течением времени (для брендированных и небрендированных запросов, для определенных тем запросов и для отдельных запросов), а также других данных SEO, таких как индивидуальные и агрегированные показатели CTR. и общее количество запросов, отображаемых сайтом, для

Контрольный список Подробности

Внедрение элементов эффективности сканирования

Если сайт большой и сканирование неэффективно, Google может потребоваться некоторое время, чтобы повторно просканировать все URL-адреса HTTP и заменить их в индексе версиями HTTPS.Чтобы ускорить этот процесс, вы можете сделать сканирование максимально эффективным. Файлы журнала — отличный ресурс для выявления проблем с эффективностью сканирования. (Keylime Toolbox Crawl Analytics предлагает обработку файлов журнала, как и другие сторонние инструменты.)

Просмотрите наш пост о том, как Google сканирует сайты, чтобы получить исчерпывающие сведения об эффективности сканирования, но некоторые ключевые элементы, которые делают сканирование эффективным, включают:

• 301 перенаправляет, а не возвращает код состояния 200 для всех вариантов URL (например, URL с косой чертой в конце и без, URL с www и без, варианты регистра и т. Д.).
• Настройка параметров, не изменяющих содержание в инструменте Параметры URL в Google Search Console.

301 перенаправление URL-адресов HTTP на URL-адреса HTTPS

перенаправления 301 являются постоянными (по сравнению с 302 перенаправлениями, которые являются временными).

Хотя Google сказал, что теперь они обрабатывают поток PageRank одинаково для 301 и 302, они по-прежнему обрабатывают эти перенаправления по-разному и другими способами. Поскольку переадресация 302 технически является «временной», Google продолжает индексировать URL-адрес, который перенаправляет 302 (а также индексирует целевой URL-адрес 302).Однако при перенаправлении 301 Google удаляет URL-адрес перенаправления из индекса и индексирует только целевой URL-адрес 301. (Обратите внимание, что это может быть меньше проблем с переадресацией HTTP на HTTPS по сравнению с другими типами изменения URL-адресов, но все же рекомендуется, чтобы обеспечить как можно более плавный переход.)

Чтобы убедиться, что URL-адреса HTTP удалены из индекса и заменены URL-адресами HTTPS, убедитесь, что все перенаправления имеют значение 301.

Как можно больше, объедините правила перенаправления

Робот Googlebot отслеживает только до 5 переадресаций, и по мере того, как URL-адреса меняются со временем и добавляются правила канонизации, цепочки переадресации становятся обычным явлением.Кроме того, цепочки перенаправления замедляют загрузку страницы (особенно на мобильных устройствах).

Google говорит: «Избегайте цепочки переадресации. Хотя робот Googlebot и браузеры могут следовать «цепочке» из нескольких перенаправлений (например, Страница 1> Страница 2> Страница 3), мы рекомендуем выполнять перенаправление в конечный пункт назначения. Если это невозможно, поддерживайте небольшое количество перенаправлений в цепочке, в идеале не более 3 и менее 5. Объединение перенаправлений в цепочку увеличивает задержку для пользователей, и не все браузеры поддерживают длинные цепочки перенаправления.”

Во многих случаях перенаправления HTTP / HTTPS и www / не-www выполняются на уровне сервера, а все остальные перенаправления выполняются на уровне приложения. В этом случае идеальным сценарием является использование одного перенаправления 301 (на уровне сервера) для учета как HTTP / HTTPS, так и без www / www и одного (на уровне приложения) 301 перенаправления для учета всех других перенаправлений.

Это последнее перенаправление будет включать такие правила, как:

• От старых шаблонов URL до текущих (убедитесь, что все старые правила обновлены с текущими конечными целями)
• Нормализация регистра (например, из example.com / Page1 до example.com/page1) и косую черту в конце (например, от example.com/page1 до example.com/page1/). В этом примере example.com/Page1 будет перенаправлять 301 напрямую на example.com/page1/ за одно перенаправление.

При просмотре всех старых правил, обновлении и объединении их также убедитесь, что все перенаправления — 301, а не 302. Хотя, как отмечалось выше, Google сказал, что 302 перенаправляет сигналы значения передачи, такие как PageRank, таким же образом, как 301 перенаправления, URL-адреса, которые перенаправляют 302, могут оставаться индексированными, что приводит к появлению неожиданных элементов отображения результатов поиска.В результатах поиска может появиться не только неправильный URL, но и другое нежелательное поведение. Например, если метаданные, такие как дополнительные ссылки, связаны с текущим URL, но старый URL отображается в результатах поиска, дополнительные ссылки отображаться не будут.

Обновить все внутренние ссылки на канонические URL-адреса

Это необязательный шаг. Но обновление внутренних ссылок полезно по нескольким причинам:

• Перенаправления увеличивают время загрузки страницы, особенно на мобильных устройствах, поэтому, когда пользователь нажимает ссылку на сайте, результирующая загрузка страницы происходит медленнее, чем в противном случае.
• Поисковые системы используют внутренние ссылки в качестве сигнала при определении того, как сканировать сайт, поэтому эффективность сканирования может быть немного ниже, если внутренние ссылки ведут на URL-адреса, которые перенаправляют (поисковые системы будут сканировать URL-адреса HTTP, поскольку они связаны внутренне, а URL-адреса HTTPS на основе о перенаправлениях и сокращении сканирования URL-адресов HTTP с течением времени).

В идеале внутренние ссылки должны быть абсолютными, а не относительными и должны обновляться до URL-адресов HTTPS. Это означает, что если на странице есть внутренняя ссылка на http: // www.example.com/page1, вы должны обновить эту внутреннюю ссылку на https://www.example.com/page1.

Вы также можете использовать относительные ссылки, а не абсолютные, что избавит от необходимости обновлять внутренние ссылки. Это нормально, но не идеально. Это связано с тем, что внутренние ссылки являются сильным каноническим сигналом для поисковых систем, поэтому, если какие-либо URL-адреса неправильно настроены, чтобы не перенаправлять (или сайт случайно дублируется на поддомене, или удаляется и т. к неканоническим версиям.

Если вы используете абсолютные ссылки и не обновляете внутренние ссылки, все они будут перенаправлять на URL-адреса HTTPS. Google сказал, что это нормально — возможно, обновление не стоит усилий. Хотя это утверждение действительно касалось внешних входящих ссылок, а не внутренних.

Было бы много работы, чтобы попытаться обновить внешние ссылки, но в большинстве случаев не должно быть много работы для обновления внутренних ссылок. Часто внутренние ссылки можно обновить с помощью настроек конфигурации, программно или все сразу с помощью сценария.

Обновление метаданных и структурированной разметки

Убедитесь, что все ресурсы перемещены на HTTPS

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

Google рекомендует инструменты для поиска «смешанного содержания» на вашем сайте.

Проверьте версию HTTPS домена в Google Search Console

В зависимости от метода проверки вы можете потерять проверку HTTP.Если возможно, сохраните проверку HTTP или повторите проверку другим методом.

Стоит проверить http: //, http: // www, https: // и https: // www. Таким образом, вы можете определить, получает ли какой-либо URL-адрес в любом варианте трафик (поэтому, возможно, не перенаправлять), и можете установить параметры конфигурации (например, предпочтительный домен) и получать предупреждения о любых ошибках, которые Google имеет перенаправления сканирования из этих вариантов.

Настроить консоль поиска Google

Установить протокол исключения роботов для HTTP и HTTPS

• Обеспечьте HTTP robots.txt перенаправляет или 404s.
• Убедитесь, что файл HTTPS robots.txt имеет то же содержание, что и предыдущий HTTP (кроме ссылки на файлы Sitemap, как указано ниже).
• Убедитесь, что страницы HTTPS не имеют мета-атрибута noindex.

Убедитесь, что теги веб-аналитики (и прочего) все еще используются

Во многих случаях сайт будет продолжать использовать те же теги веб-аналитики (например, идентификатор ресурса Google Analytics). Но если вы измените это, убедитесь, что страницы сайта обновляются.Кроме того, убедитесь, что исходный код, содержащий теги, не сбрасывается со страниц в процессе миграции.

Вы можете использовать сторонний инструмент, который проверяет наличие тегов, или можете настроить поисковый робот, такой как Screaming Frog, для его проверки.

Отправка исчерпывающих и канонических XML-файлов Sitemap для HTTPS-ресурса

В идеале у вас уже есть полный и канонический набор XML-файлов Sitemap для свойства HTTP. В этом случае вы можете оставить эти файлы Sitemap на месте и добавить соответствующие файлы Sitemap для свойства HTTPS.

Оставление файлов Sitemap HTTP XML на месте

Есть две причины оставить файлы Sitemap для HTTP:

• URL-адресов, перечисленных в XML-файле Sitemap, являются сигналом для робота Googlebot для (повторного) сканирования этих URL-адресов, и вы хотите предоставить как можно больше сигналов, чтобы Google мог быстро повторно сканировать URL-адреса HTTP (чтобы получить перенаправления 301, а затем сканировать и индексировать HTTPS URL)
• Если XML-файлы Sitemap добавлены в Google Search Console, вы можете использовать отчеты Google Search Console по XML-файлам Sitemap для отслеживания снижения индексации (подробнее об этом см. В разделе мониторинга ниже).

Создание файлов Sitemap для HTTPS XML

Причины создания файлов Sitemap для свойства HTTPS аналогичны:

• Вы быстро запускаете сканирование роботом Googlebot URL-адресов HTTPS, когда они находятся в XML-файлах Sitemap
• Вы можете отслеживать рост индексации с помощью отчетов об индексировании XML Sitemaps в Google Search Console (как описано далее в разделе мониторинга).

Отправка полных и канонических XML-файлов Sitemap

По возможности всегда создавайте XML-файлы Sitemap, которые являются исчерпывающими и каноническими (не только для целей перехода с HTTP на HTTPS).

• Канонические URL-адреса — включая только канонические URL-адреса, вы предоставляете поисковым системам полезный сигнал о том, какие URL-адреса сканировать, а также позволяете использовать отчеты об индексировании XML-файлов Sitemap в Google Search Console. (Если включены неканонические URL-адреса, отчеты об индексировании будут предоставлять искаженные проценты.)
• Исчерпывающие URL-адреса — путем включения всех URL-адресов, которые вы хотите проиндексировать (или повторно сканировать в случае перехода с HTTP на HTTPS), вы обеспечиваете полное представление сайта, предоставляете сигнал о том, какие URL-адреса следует сканировать регулярно (даже если они уже проиндексированы) и позволяют отчетам об индексировании быть точными.Как более подробно описано в разделе мониторинга ниже, отчеты об индексировании XML-файлов Sitemap могут предоставлять только общее количество URL-адресов, проиндексированных из Sitemap, поэтому вам нужен полный список URL-адресов, чтобы получить исчерпывающую статистику индексирования.

Замена ссылки на XML-файлы Sitemap в файле robots.txt

Ссылка на XML-карту сайта в файле robots.txt позволяет поисковым системам (например, Google и Bing) узнать о существовании файлов. когда вы отправляете XML-файлы Sitemap в Google через консоль поиска Google, файл robots.txt является избыточной. Но полезно добавить ссылку для других поисковых систем и в качестве резервной копии на случай, если учетная запись Google Search Console потеряет подтверждение или станет недоступной по иным причинам.

Файл robots.txt относится к свойству HTTP или HTTPS, и содержимое файла применяется только к этому свойству. Это означает, что вы не можете указать одновременно расположение файлов Sitemap HTTP и HTTPS XML в файле robots.txt для свойства HTTPS.

Вместо этого вам, вероятно, потребуется переместить или скопировать robots.txt из свойства HTTP в свойство HTTPS, а затем обновите ссылку на XML-файлы Sitemap (большинство директив в файле robots.txt являются относительными, но ссылка на Sitemap является абсолютной).

Монитор Google Search Console XML Sitemap Indexing Stats

Как отмечено в шагах миграции, вы должны отправить XML Sitemap для URL-адресов на HTTPS и оставить существующий XML Sitemap для HTTP. Это позволит вам отслеживать уменьшение индексации для свойства HTTP и увеличение индексации для свойства HTTPS.

• Все URL-адреса в карте сайта HTTP должны иметь код состояния 301, и со временем индексирование должно снижаться.
• Все URL-адреса в карте сайта HTTPS должны иметь код состояния 200, а индексирование со временем должно увеличиваться.

Этот процесс может занять некоторое время, и вы можете обнаружить, что некоторые URL-адреса HTTP все еще проиндексированы несколько месяцев спустя. Наиболее частые причины этого:

• URL-адреса HTTP заблокированы файлом robots.txt (поэтому робот Googlebot не может сканировать перенаправление) и частично проиндексированы.
• URL-адреса HTTP являются «неканоническими» (например, до 301 имели канонический атрибут для другого URL-адреса) и не сканируются очень часто.
• URL-адреса HTTP не возвращают 301 (вместо этого возвращают 302 или ошибку)

Если вы обнаружите, что некоторые URL-адреса все еще проиндексированы несколько месяцев спустя, но отчеты Search Analytics в Google Search Console не показывают кликов по свойству HTTP, возможно, эту проблему не стоит исследовать.URL-адреса не ранжируются по запросам и не вызывают проблем.

Однако, если вы видите щелчки по свойству HTTP, значит, URL-адреса ранжируются по запросам. Самый простой способ начать расследование — просмотреть журналы сервера (подробнее об этом ниже), чтобы точно узнать, что робот Googlebot получает при сканировании. В файлах Excel с подробным описанием журнала аналитики сканирования Keylime Toolbox есть вкладка, на которой перечислены все URL-адреса с кодом ответа 200, все URL-адреса с кодом ответа 302 и т. Д.

Вы также можете сканировать сайт с помощью такого инструмента, как Screaming Frog, чтобы получить список URL-адресов, которые возвращают 200, заблокированных роботами.txt и тому подобное.

Также посмотрите Google Search Console> Сканирование> robots.txt Tester для свойства HTTP, чтобы узнать, видит ли Google файл robots.txt и, если да, блокирует ли он какие-либо URL.

Отслеживание статуса индексирования в Google Search Console

Эти отчеты менее полезны, чем метрики индексации XML Sitemaps, подробно описанные выше, но если вы не можете отправить исчерпывающие и канонические XML Sitemap, то лучшим вариантом могут быть тенденции состояния индексации.

Свойство HTTP:

HTTPS Свойство:

Отслеживание отчетов об ошибках сканирования в Google Search Console

Отслеживайте отчеты об ошибках сканирования в Google Search Console для свойств HTTP и HTTPS. Если вы видите увеличение количества ошибок (например, 404 или 500) для любого свойства, то, например, что-то может быть не так с переадресацией.

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

Если вы используете Keylime Toolbox (см. Ниже), вы можете получить полный список всех URL-адресов и ссылки из источников в файле CSV для облегчения просмотра.

Убедитесь, что все работает правильно

Для этого также можно настроить сценарии автоматического тестирования, но я считаю, что быстрая ручная проверка иногда также может дать хорошее понимание. Проверка QA может выявить проблемы до того, как они появятся в других местах (отчеты об ошибках сканирования, файлы журналов и т. Д.).

• Просканируйте свойства HTTP и HTTPS (например, с помощью Screaming Frog), чтобы проверить такие элементы, как канонические атрибуты и внутренние ссылки.
• Вручную проверьте несколько URL-адресов HTTP (например, с помощью надстройки HTTP-заголовков Firefox), чтобы убедиться, что перенаправления работают должным образом.
• Вручную проверьте несколько URL-адресов HTTP с помощью функции «Выбрать как Google» в консоли поиска, чтобы убедиться, что Google правильно видит перенаправления.

Мониторинг органического поискового трафика в Google Search Console и веб-аналитике

Органический трафик Google должен либо оставаться стабильным, либо временно снижаться во время миграции.Поскольку переиндексация — это непрерывный процесс, который не происходит сразу, вы не должны видеть резкого снижения трафика (даже если с переадресацией что-то пошло не так).

Вы можете выполнять более детальный мониторинг трафика (по брендированному / небрендированному трафику и категориям запросов) с помощью Keylime Toolbox, как описано ниже.

Данные веб-аналитики

Если вы не измените теги аналитики, вы сможете видеть только агрегированные данные о трафике с трендом (vs.трафик для свойств http и https отдельно). Агрегированные данные полезны для отслеживания любых спадов или продолжающихся спадов, которые могут потребовать дальнейшего изучения.

Google Search Console Search Analytics

Вы должны увидеть увеличение количества кликов по свойству HTTPS и уменьшение по свойству HTTP. Эти тенденции, вероятно, будут постепенными в течение нескольких недель (а возможно и месяцев), поскольку робот Googlebot повторно сканирует уже проиндексированные URL-адреса HTTP, затем сканирует URL-адреса HTTPS и, соответственно, выполняет повторную индексацию.

Поскольку данные запроса в Google Search Console обычно отстают на 2-3 дня, и пройдет как минимум несколько дней, прежде чем вы начнете видеть большой трафик на свойстве https (из-за времени для сканирования и индексации страниц), вы не будете иметь возможность следить за этим сразу.

Вы должны просматривать данные о кликах для свойств HTTP и HTTPS отдельно, а также можете отслеживать агрегированные клики с помощью набора свойств.

Рейтинг мониторинга в Google Search Console

Трудно отслеживать крупномасштабные рейтинги по всем запросам в Google Search Console.Существуют сторонние инструменты, которые могут помочь, включая Keylime Toolbox (как более подробно описано ниже).

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

Посмотрите на периоды до и после миграции для свойств HTTP и HTTPS и сравните:

• Переход к ценным страницам
• Рейтинг по запросам с высоким трафиком

В идеале, недавно проиндексированный URL-адрес HTTPS будет занимать ту же позицию для запроса, что и ранее проиндексированный URL-адрес HTTP.В приведенном ниже примере показаны рейтинг, CTR, показы и клики для одного запроса за период в пять дней. Первый график — это свойство HTTP, а второй график — свойство HTTPS.

Окончательный рейтинг для HTTPS совпадает с исходным рейтингом для HTTP.

HTTP:

Добавьте свой сайт в поисковую систему Google

Что такое SEO?

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

Он складывается из заголовков страниц, описаний и контента, который вы добавили на сайт.

Размещение вашего веб-сайта в Google