Перенос и изменение структуры сайта

Перенаправление URL — это практика разрешения существующего URL-адреса на другой, эффективно сообщающая вашим посетителям и Google Search, что страница имеет новое местоположение. Редиректы особенно полезны в следующих обстоятельствах:

Вы перенесли свой сайт на новый домен и хотите сделать переход максимально плавным.

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

Вы объединяете два веб-сайта и хотите убедиться, что ссылки на устаревшие URL-адреса перенаправляются на правильные страницы.

Если вы используете такую платформу, как Blogger или Shopify, на ней могут быть уже встроенные решения для редиректов. Попробуйте поискать справочные статьи (например, выполните поиск по запросу «blogger redirects»).

Обзор типов редиректов

Хотя ваши пользователи, как правило, не смогут заметить разницу между различными типами редиректов, Google Search использует их как сильный или слабый сигнал о том, что целевой URL редиректа должен быть каноническим. Выбор редиректа зависит от того, как долго он будет действовать и какую страницу вы хотите видеть в результатах поиска Google:

В следующей таблице описаны различные способы настройки постоянных и временных редиректов, упорядоченные по вероятности их правильной интерпретации Google (например, серверный редирект имеет наибольший шанс быть правильно интерпретированным Google). Выберите тип редиректа, который подходит для вашей ситуации и сайта:

Серверные редиректы

Настройка серверных редиректов требует доступа к файлам конфигурации сервера (например, файлу .htaccess на Apache) или установки заголовков перенаправления с помощью серверных скриптов (например, PHP). Вы можете создавать как постоянные, так и временные редиректы на стороне сервера.

Постоянные серверные редиректы

Если вам нужно изменить URL-адрес страницы, как он отображается в результатах поисковых систем, мы рекомендуем по возможности использовать постоянный серверный редирект. Это лучший способ гарантировать, что Google Search и пользователи будут направлены на нужную страницу. Коды состояния 301 и 308 означают, что страница навсегда перемещена в новое место.

Временные серверные редиректы

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

Реализация серверных редиректов

Реализация серверных редиректов зависит от вашего хостинга, серверной среды или языка сценариев бэкенда вашего сайта.

Чтобы настроить постоянный редирект с помощью PHP, используйте функцию header(). Вы должны установить заголовки до того, как что-либо будет отправлено на экран:

Если у вас есть доступ к файлам конфигурации вашего веб-сервера, вы можете написать правила перенаправления самостоятельно. Следуйте руководствам вашего веб-сервера:

Apache: Ознакомьтесь с руководством по Apache .htaccess, руководством по перезаписи URL Apache и документацией Apache mod_alias. Например, вы можете использовать mod_alias для настройки простейшей формы редиректов:# Постоянный редирект: Redirect permanent “/old” “http://example.com/new” # Временный редирект: Redirect temp “/two-old” “http://example.com/two-new”Для более сложных редиректов используйте mod_rewrite. Например:RewriteEngine on # перенаправить страницу услуги на новую страницу с постоянным редиректом RewriteRule “^/service$” “/about/service” [R=301] # перенаправить страницу услуги на новую страницу с временным редиректом RewriteRule “^/service$” “/about/service” [R]

NGINX: Прочитайте о создании правил перезаписи NGINX в блоге NGINX. Как и в случае с Apache, у вас есть несколько вариантов создания редиректов. Например:location = /service { # для постоянного редиректа return 301 $scheme://example.com/about/service # для временного редиректа return 302 $scheme://example.com/about/service }Для более сложных редиректов используйте директиву rewrite:location = /service { # для постоянного редиректа rewrite service?name=$1 ^service/offline/([a-z]+)/?$ permanent; # для временного редиректа rewrite service?name=$1 ^service/offline/([a-z]+)/?$ redirect; }

Для всех остальных веб-серверов обратитесь к своему системному администратору или хостинг-провайдеру, либо поищите руководства в своей любимой поисковой системе (например, выполните поиск по запросу «LiteSpeed redirects»).

Meta refresh и его HTTP-эквивалент

Если реализация серверных редиректов на вашей платформе невозможна, мета-обновление (meta refresh) может стать жизнеспособной альтернативой. Google различает два вида мета-обновлений:

Мгновенное мета-обновление: срабатывает сразу после загрузки страницы в браузере. Google Search интерпретирует мгновенные мета-обновления как постоянные редиректы.

Отложенное мета-обновление: срабатывает только через произвольное количество секунд, установленное владельцем сайта. Google Search интерпретирует отложенные мета-обновления как временные редиректы.

Разместите мета-обновление либо в разделе head HTML-кода, либо в HTTP-заголовке с помощью серверного кода. Например, вот мгновенное мета-обновление в разделе head HTML-кода:

Вот пример эквивалента HTTP-заголовка, который можно внедрить с помощью серверных скриптов:

Чтобы создать отложенный редирект, который интерпретируется Google как временный, установите атрибут content на количество секунд, на которое должен быть отложен редирект:

JavaScript-редиректы

Google Search интерпретирует и выполняет JavaScript с помощью службы Web Rendering Service после завершения сканирования URL. Используйте JavaScript-редиректы только в том случае, если вы не можете реализовать серверные редиректы или мета-обновления. Хотя Google пытается отрисовать каждый URL, просканированный Googlebot, отрисовка может не удаться по разным причинам. Это означает, что если вы установите JavaScript-редирект, Google может никогда его не увидеть, если отрисовка контента не удалась.

Чтобы настроить JavaScript-редирект, установите свойство location на целевой URL редиректа в блоке script в разделе head HTML-кода. Например:

Крипто-редиректы

Если вы не можете реализовать ни один из традиционных методов перенаправления, вам все равно следует приложить усилия, чтобы сообщить пользователям о том, что страница или ее контент перемещены. Самый простой способ сделать это — добавить ссылку на новую страницу, сопровождаемую кратким объяснением. Например:

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

Альтернативные версии URL

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

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

Рекомендации для всех переносов сайта

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

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

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

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

Если это связано с изменением URL, вы можете рассмотреть возможность проведения A/B-тестирования или пробного запуска. Запланируйте несколько недель, чтобы дать время на сканирование и индексацию для учета изменений, а также время для мониторинга трафика.

Перенос сайта без изменения URL

В этом руководстве показано, как минимизировать влияние на эффективность вашего сайта в Google Search при миграции инфраструктуры хостинга. Например, при смене хостинг-провайдеров или переходе на сеть доставки контента (CDN). Это руководство предназначено только для миграций, которые не влияют на видимый пользователю URL. Меняете URL-адреса? Если вы вносите видимые изменения в URL, начните с раздела «Перенос сайта с изменением URL».

Обзор

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

Подготовьте новую инфраструктуру хостинга. Загрузите свой контент на новые серверы или настройте свою CDN и исходные серверы, а затем протестируйте их.

Начните перенос сайта. Измените настройки DNS вашего доменного имени, чтобы они указывали на новую инфраструктуру хостинга. Этот шаг является фактическим шагом переноса сайта, который запускает процесс отправки вашего трафика на новую инфраструктуру.

Отключение. Отключите старую инфраструктуру хостинга, когда будете уверены, что все пользователи правильно получают контент с новой инфраструктуры и никто не использует старую.

Подготовка новой инфраструктуры хостинга

Скопируйте и протестируйте свой новый сайт

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

Откройте свой новый сайт в веб-браузере и просмотрите все элементы вашего сайта: веб-страницы, изображения, формы и загрузки (например, PDF-файлы).

Создайте среду тестирования, возможно, с доступом по IP, через которую вы протестируете все функции перед запуском веб-сайта.

Разрешите публичное тестирование с временным именем хоста для вашей новой инфраструктуры (например, beta.example.com), чтобы вы могли протестировать доступность браузерами. Временное имя хоста может помочь вам проверить, может ли Googlebot достичь вашего сайта или нет.

Проверьте, может ли Googlebot получить доступ к новой инфраструктуре хостинга

Если у вас еще нет аккаунта Search Console, создайте новый аккаунт для своего сайта, чтобы помочь вам отслеживать доступ Google и трафик. Если вы создали временное имя хоста для своего нового сайта, создайте аккаунт и для этого имени хоста. Проверьте, может ли Googlebot получить доступ к вашей новой инфраструктуре, используя инструмент проверки URL в Search Console. Внимание: Проверьте конфигурацию вашего брандмауэра или защиту от отказа в обслуживании (DoS). Убедитесь, что она не блокирует способность Googlebot достигать DNS или серверов хостинг-провайдера.

Уменьшите значение TTL для ваших DNS-записей

Вы можете помочь ускорить перенос сайта, если уменьшите значение TTL DNS-записей вашего сайта, что позволит новым настройкам быстрее распространяться среди интернет-провайдеров. Настройки DNS обычно кэшируются интернет-провайдерами на основе указанного параметра Time to Live (TTL). Рассмотрите возможность снижения TTL до консервативно низкого значения (например, несколько часов) как минимум за неделю до переноса сайта, чтобы быстрее обновлять кэши DNS.

Проверка верификации Search Console

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

Точно так же, если вы включаете в шаблоны вашей системы управления контентом метатег или Google Analytics для подтверждения владения, убедитесь, что новая копия CMS также включает их.

Начало переноса сайта

Удалите любые временные блокировки сканирования. При создании новой копии сайта некоторые владельцы сайтов используют файл robots.txt, чтобы запретить сканирование Googlebot и другим сканерам, или используют метатеги noindex или HTTP-заголовки для блокировки индексации контента. Обязательно удалите любые подобные блокировки из новой копии сайта, когда будете готовы начать перенос.

Обновите настройки DNS. Вы начинаете перенос сайта с обновления DNS-записей, чтобы они указывали на нового хостинг-провайдера. Узнайте у своего DNS-провайдера, как это сделать. Поскольку настройки кэша DNS кэшируются, записям требуется некоторое время для полного распространения среди всех пользователей в интернете.

Мониторинг трафика

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

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

Мониторинг сканирования. Следите за графиками покрытия индекса в Search Console. Позвольте Googlebot решать. Вместо того чтобы вручную устанавливать максимальную скорость сканирования в Search Console, оставьте настройку «Позвольте Googlebot решать». Таким образом, настройки, предназначенные только для старой системы, не будут мешать требованиям вашей новой системы.

Примечание о скорости сканирования Googlebot

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

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

Отключение старого хостинга

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

Перенос сайта с изменением URL

В этой статье описывается, как изменить URL-адреса существующих страниц на вашем сайте с минимальным влиянием на результаты Google Search. Примеры такого переноса сайта включают:

Не меняете URL-адреса? Если вы вносите изменения на сайт без видимых изменений URL, начните здесь.

Обзор

Ознакомьтесь с основной информацией о переносе сайта. Знайте, чего ожидать и как это может повлиять на ваших пользователей и рейтинги. Если вы переходите с HTTP на HTTPS, ознакомьтесь с лучшими практиками для HTTPS.

Начните перенос сайта с настройки сервера для перенаправления со старых URL-адресов на новые.

Часто задаваемые вопросы для всех переносов сайта с изменением URL

Рекомендует ли Google переносить все вместе или можно переносить по разделам? Перенос по разделам — это нормально.

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

Сколько времени потребуется Google для распознавания изменений URL? Фиксированных частот сканирования нет; это зависит от размера вашего сайта и скорости сканирования, которая возможна. Перенос происходит на основе каждого URL.

Теряете ли вы кредит за ссылки при перенаправлении на новые URL-адреса? Нет, редиректы 301 или 302 не вызывают потерю PageRank.

Миграция с HTTP на HTTPS

Обязательно добавьте свойство HTTPS в Search Console. Search Console обрабатывает HTTP и HTTPS отдельно; данные для этих свойств в Search Console не являются общими. Поэтому, если у вас есть страницы в обоих протоколах, у вас должно быть отдельное свойство Search Console для каждого из них.

Часто задаваемые вопросы по миграции с HTTP на HTTPS

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

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

Да, это нормально. Начните с части, протестируйте ее, а затем переносите больше в своем собственном темпе.

Если вы мигрируете с HTTP на HTTPS по частям и хотите избежать ранней индексации промежуточных URL-адресов, мы рекомендуем использовать rel=canonical вместо редиректов. Если вы используете редиректы, вы не сможете протестировать перенаправленные страницы.

Подтверждайте HTTP и HTTPS отдельно в Search Console и используйте отчет о покрытии индекса, чтобы увидеть, какие страницы были проиндексированы.

Фиксированных частот сканирования нет; это зависит от размера вашего сайта и скорости сканирования, которая возможна. Перенос происходит на основе каждого URL.

Мы рекомендуем обновить файл robots.txt, чтобы он указывал на HTTPS-версию ваших файлов карты сайта. Мы также рекомендуем указывать в карте сайта только HTTPS-URL.

Имейте в виду, что если вы перенаправляете каждый URL на своем сайте с HTTP на HTTPS, у вас все равно будет только один файл robots.txt, доступный для сканеров. Например, если http://example.com/robots.txt перенаправляется на https://example.com/robots.txt, содержимое HTTP-версии не будет видно Google и другим поисковым системам.

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

Укажите все новые HTTPS-URL в своей карте сайта и удалите старые HTTP-URL. Если вы предпочитаете создать новую карту сайта, укажите в ней только новые HTTPS-URL.

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

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

Центр издателей Google News обрабатывает переходы с HTTP на HTTPS прозрачно. В целом, вам не нужно ничего делать с точки зрения Google News, если вы также не используете карты сайта News. В этом случае свяжитесь с командой News и сообщите им об изменении. Вы также можете сообщить команде об изменении разделов, например, если вы переходите на HTTPS, вы можете указать, что переносите http://example.com/section на https://example.com/section.

Подготовка нового сайта

Детали подготовки сайта различаются для каждого переноса сайта, но обычно вы будете выполнять одно или несколько из следующих действий:

Перенесите изображения и загрузки (например, PDF-документы), которые вы размещаете в настоящее время. Они могут уже получать трафик из Google Search или по ссылкам, и полезно сообщить пользователям и Googlebot об их новом местоположении.

Для перехода на HTTPS получите и настройте необходимые TLS-сертификаты на своем сервере.

Настройте robots.txt для вашего нового сайта

Файл robots.txt для сайта управляет тем, какие области может сканировать Googlebot. Убедитесь, что директивы в файле robots.txt нового сайта правильно отражают части, которые вы хотите заблокировать от сканирования.

Обратите внимание, что некоторые владельцы сайтов блокируют все сканирование во время разработки. Если вы следуете этой стратегии, убедитесь, что подготовили то, как должен выглядеть файл robots.txt после начала переноса сайта. Точно так же, если вы используете директивы noindex во время разработки, подготовьте список URL-адресов, с которых вы удалите директивы noindex, когда начнете перенос сайта.

Предоставьте ошибки для удаленного или объединенного контента

Для контента на старом сайте, который не будет перенесен на новый сайт, убедитесь, что эти осиротевшие URL-адреса правильно возвращают код ответа HTTP 404 или 410. Вы можете вернуть код ответа об ошибке по старому URL в панели конфигурации вашего нового сайта, или вы можете создать редирект для нового URL и заставить его вернуть код ошибки HTTP. Избегайте нерелевантных редиректов

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

Обеспечьте правильные настройки Search Console

Если вы еще этого не сделали, подтвердите, что вы владеете как старым, так и новым сайтами в Search Console. Обязательно подтвердите все варианты как старого, так и нового сайтов. Например, подтвердите www.example.com и example.com, и включите оба варианта сайта HTTPS и HTTP, если вы используете HTTPS-URL. Сделайте это как для старого, так и для нового сайтов.

Убедитесь, что ваша верификация Search Console продолжит работать после переноса сайта. Если вы используете другой метод верификации, имейте в виду, что токены верификации могут отличаться при изменении URL.

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

Точно так же, если вы подтверждаете владение с помощью включаемого файла, который ссылается на метатег или Google Analytics для подтверждения владения, убедитесь, что новая копия CMS также включает их.

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

Параметры URL: Если вы настроили параметры URL для управления сканированием или индексацией ваших старых URL-адресов, убедитесь, что настройки также применены к новому сайту, если это необходимо.

Геотаргетинг: Ваш старый сайт может иметь явный геотаргетинг, такой как домен с возможностью геотаргетинга или домен верхнего уровня с кодом страны (например, .co.uk). Примените ту же настройку к новому сайту, если хотите продолжать таргетинг на тот же регион. Однако, если ваш перенос сайта предназначен для помощи вашему бизнесу в глобальном расширении и вы не хотите, чтобы ваш сайт ассоциировался с какой-либо страной или регионом, выберите «Не указано» в раскрывающемся списке на странице настроек сайта.

Скорость сканирования: Мы рекомендуем не ограничивать скорость сканирования Googlebot в Search Console как для старых, так и для новых URL-адресов. Мы также советуем не настраивать параметр скорости сканирования. Делайте это только в том случае, если вы знаете, что ваш сайт не может справиться с объемом сканирования Googlebot. Если вы уже ограничили скорость сканирования Googlebot для своего старого сайта, рассмотрите возможность ее снятия. У Google есть алгоритмы, которые автоматически обнаруживают, что перенос сайта был реализован, и мы изменяем поведение сканирования Googlebot так, чтобы наша индексация быстро отражала перенос сайта.

Отклоненные обратные ссылки: Если вы загрузили файл для отклонения ссылок на своем старом сайте, мы рекомендуем вам повторно загрузить его, используя аккаунт Search Console нового сайта.

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

Ручные меры за предыдущий спам. Для сайтов, которые не соответствуют нашим правилам в отношении спама, Google готов принимать ручные меры, такие как понижение их в рейтинге или даже полное удаление из результатов поиска. Проверьте страницу «Ручные меры» в Search Console, чтобы увидеть, были ли применены какие-либо ручные меры к новому сайту, и устраните любые проблемы, перечисленные там, прежде чем подавать запрос на пересмотр.

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

Используйте веб-аналитику

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

Убедитесь, что ваш сервер имеет достаточно вычислительных ресурсов

После миграции Google будет сканировать ваш новый сайт более интенсивно, чем обычно. Это связано с тем, что ваш сайт перенаправляет трафик со старого на новый сайт, и любые сканирования старого сайта будут перенаправлены на новый сайт, в дополнение к любому другому сканированию. Убедитесь, что ваш новый сайт имеет достаточную емкость для обработки увеличенного трафика от Google.

Обновите Data Highlighter

Если вы использовали Data Highlighter для сопоставления ваших старых страниц, обязательно повторите сопоставление для вашего нового сайта.

Обновите ссылки на приложения

Как только ваши страницы HTTPS будут готовы, обновите любые ссылки на приложения, предназначенные для открытия ваших веб-страниц в приложении при отображении в результатах поиска Google. Обновите эти ссылки, чтобы они указывали на новые HTTPS-URL. Редиректы не будут работать для этих ссылок; клики в мобильном браузере откроют страницу в браузере вместо приложения, если вы не обновите обработку ссылок на ваше приложение.

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

Подготовка сопоставления URL

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

Определите свои старые URL-адреса

В простейших переносах сайта вам может не понадобиться создавать список ваших старых URL-адресов. Например, вы могли бы использовать серверный редирект с подстановочным знаком, если вы меняете домен вашего сайта (например, переезд с example.com на example.net).

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

Начните с ваших важных URL-адресов. Чтобы найти их: Посмотрите в своих картах сайта, потому что вполне вероятно, что ваши самые важные URL-адреса были отправлены в Search Console таким образом

Проверьте функцию «Ссылки на ваш сайт» в Search Console на наличие страниц, которые имеют внутренние и внешние ссылки

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

Проверьте логи вашего сервера на наличие URL-адресов, которые были посещены хотя бы один раз за последнее время. Выберите период времени, который имеет смысл для вашего сайта, помня о сезонных колебаниях трафика.

Включите изображения и видео — Убедитесь, что вы включили URL-адреса встроенного контента в свои планы переноса сайта: видео, изображения, JavaScript и CSS-файлы. Эти URL-адреса должны быть перемещены так же, как и весь остальной контент на вашем веб-сайте.

Создайте сопоставление старых URL-адресов с новыми

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

Обновите все детали URL

Как только ваше сопоставление URL будет определено, вы захотите сделать три вещи, чтобы подготовить страницы к переносу.

Обновите аннотации, чтобы они указывали на новые URL-адреса в HTML или записи карты сайта для каждой страницы: Каждый целевой URL должен иметь самоссылающийся тег rel=”canonical”.

Если сайт, который вы перенесли, имеет многоязычные или многонациональные страницы, аннотированные с использованием аннотаций rel-alternate-hreflang, обязательно обновите аннотации, чтобы использовать новые URL-адреса.

Если сайт, который вы перенесли, имеет мобильный аналог, убедитесь, что вы обновили аннотации rel-alternate-media, чтобы использовать новые URL-адреса. Узнайте больше в наших рекомендациях для смартфонов.

Обновите внутренние ссылки. Измените внутренние ссылки на новом сайте со старых URL-адресов на новые URL-адреса. Вы можете использовать сопоставление, созданное ранее, чтобы помочь найти и обновить ссылки по мере необходимости.

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

Список сайтов, ссылающихся на ваши старые URL-адреса. Вы можете найти ссылки на ваш сайт в Search Console.

Подготовка к редиректам 301

Как только у вас будет сопоставление и ваш новый сайт будет готов, следующим шагом будет настройка HTTP-редиректов 301 на вашем сервере со старых URL-адресов на новые URL-адреса, как вы указали в своем сопоставлении.

Используйте HTTP-редиректы 301. Хотя Googlebot поддерживает несколько видов редиректов, мы рекомендуем вам по возможности использовать HTTP-редиректы 301.

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

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

Начало переноса сайта

Решите, как вы будете переносить свой сайт — все сразу или по разделам: Малые или средние сайты: Мы рекомендуем переносить все URL-адреса на вашем сайте одновременно, вместо того чтобы переносить по одному разделу за раз. Это помогает пользователям лучше взаимодействовать с сайтом в его новой форме и помогает нашим алгоритмам обнаруживать перенос сайта и быстрее обновлять наш индекс.

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

Обновите свои файлы robots.txt: На старом сайте удалите все директивы robots.txt. Это позволит Googlebot обнаруживать все редиректы на новый сайт и обновлять наш индекс. Имейте в виду, что сканеры не увидят содержимое старого файла robots.txt после того, как вы включили редиректы.

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

Настройте старый веб-сайт для перенаправления пользователей и Googlebot на новый сайт на основе сопоставления URL.

Отправьте «Изменение адреса» в Search Console для старого сайта. Если вы переносите свой сайт с HTTP на HTTPS, вам не нужно использовать инструмент «Изменение адреса».

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

Отправьте новую карту сайта в Search Console. Это поможет Google узнать о новых URL-адресах. На этом этапе вы можете удалить свою старую карту сайта, так как Google будет использовать новую карту сайта в будущем.

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

Обновите входящие ссылки

Сразу после начала переноса сайта постарайтесь обновить как можно больше входящих ссылок, чтобы улучшить пользовательский опыт и снизить нагрузку на сервер. К ним относятся:

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

Мониторинг трафика

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

Используйте Search Console для мониторинга трафика

Карты сайта: Отправьте две карты сайта, которые вы сохранили ранее из сопоставления. Первоначально карта сайта, содержащая новые URL-адреса, будет иметь ноль проиндексированных страниц, в то время как карта сайта старых URL-адресов будет иметь много проиндексированных страниц. Со временем количество страниц, проиндексированных из карты сайта старых URL-адресов, упадет до нуля с соответствующим увеличением индексации новых URL-адресов.

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

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

Используйте другие инструменты для мониторинга трафика

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

Если вы установили какое-либо программное обеспечение для веб-аналитики на своем сайте, или если ваша CMS предоставляет аналитику, также рекомендуется просматривать трафик таким образом, чтобы вы могли видеть прогресс трафика со старого на новый сайт. В частности, Google Analytics предлагает отчетность в реальном времени, и это удобная функция для использования во время начальной фазы переноса сайта. Вы должны ожидать, что трафик упадет на старом сайте и вырастет на новом сайте.

Устранение неполадок при переносе сайта

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

Минимизация влияния A/B-тестирования в Google Search

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

Обзор тестирования

Тестирование веб-сайта — это когда вы пробуете разные версии своего веб-сайта (или части вашего веб-сайта) и собираете данные о том, как пользователи реагируют на каждую версию.

A/B-тестирование — это когда вы тестируете две (или более) вариации изменения. Например, вы можете протестировать разные шрифты на кнопке, чтобы увидеть, сможете ли вы увеличить количество кликов по кнопке.

Многофакторное тестирование — это когда вы тестируете более одного типа изменений за раз, ища влияние каждого изменения, а также потенциальные синергии между изменениями. Например, вы можете попробовать несколько шрифтов для кнопки, но также попробовать изменить (и не изменять) шрифт остальной части страницы в то же время. Является ли новый шрифт более легким для чтения и поэтому его следует использовать везде? Или преимущество в том, что шрифт кнопки выглядит иначе, чем остальная часть страницы, помогая привлечь внимание?

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

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

Вы также можете проводить тесты, не меняя URL, динамически вставляя вариации на страницу. Вы можете использовать JavaScript, чтобы решить, какую вариацию отображать.

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

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

Лучшие практики при тестировании

Вот список лучших практик, чтобы избежать каких-либо плохих эффектов на поведение вашего сайта в Google Search во время тестирования вариаций сайта:

Не используйте клоакинг для своих тестовых страниц

Не показывайте один набор URL-адресов Googlebot, а другой набор — людям. Это называется клоакингом и противоречит нашим правилам в отношении спама, независимо от того, проводите ли вы тест или нет. Помните, что нарушение наших правил в отношении спама может привести к понижению рейтинга вашего сайта или его удалению из результатов поиска Google — вероятно, не тот результат, которого вы ожидали от своего теста.

Клоакинг учитывается независимо от того, делаете ли вы это с помощью серверной логики, robots.txt или любого другого метода. Вместо этого используйте ссылки или редиректы, как описано далее.

Если вы используете файлы cookie для управления тестом, имейте в виду, что Googlebot, как правило, не поддерживает файлы cookie. Это означает, что он увидит только ту версию контента, которая доступна пользователям с браузерами, не принимающими файлы cookie.

Используйте ссылки rel=”canonical”

Если вы проводите тест с несколькими URL-адресами, вы можете использовать атрибут ссылки rel=”canonical” на всех ваших альтернативных URL-адресах, чтобы указать, что исходный URL является предпочтительной версией. Мы рекомендуем использовать rel=”canonical” вместо метатега noindex, потому что это более точно соответствует вашему намерению в этой ситуации. Например, если вы тестируете вариации своей домашней страницы, вы не хотите, чтобы поисковые системы не индексировали вашу домашнюю страницу; вы просто хотите, чтобы они поняли, что все тестовые URL-адреса являются близкими дубликатами или вариациями исходного URL и должны быть сгруппированы вместе, с исходным URL в качестве канонического. Использование noindex вместо rel=”canonical” в такой ситуации иногда может иметь неожиданные плохие эффекты.

Используйте редиректы 302, а не редиректы 301

Если вы проводите тест, который перенаправляет пользователей с исходного URL на URL вариации, используйте редирект 302 (временный), а не редирект 301 (постоянный). Это говорит поисковым системам, что этот редирект является временным — он будет действовать только до тех пор, пока вы проводите эксперимент — и что они должны сохранить исходный URL в своем индексе, а не заменять его целью редиректа (тестовой страницей). Редиректы на основе JavaScript также подходят.

Проводите эксперимент только столько времени, сколько необходимо

Количество времени, необходимое для надежного теста, будет варьироваться в зависимости от таких факторов, как ваши коэффициенты конверсии и объем трафика на вашем веб-сайте; хороший инструмент тестирования подскажет вам, когда вы собрали достаточно данных, чтобы сделать надежный вывод. Как только вы завершите тест, обновите свой сайт желаемой вариацией(ями) контента и удалите все элементы теста как можно скорее, такие как альтернативные URL-адреса или тестовые скрипты и разметка. Если мы обнаружим сайт, проводящий эксперимент в течение неоправданно долгого времени, мы можем интерпретировать это как попытку обмануть поисковые системы и принять соответствующие меры. Это особенно верно, если вы предоставляете один вариант контента большому проценту ваших пользователей.

Дополнительная информация о тестировании

Временная приостановка или отключение веб-сайта

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

Ограничьте функциональность вашего сайта (рекомендуется)

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

Отключите функциональность корзины: Отключение функциональности корзины — это самый простой подход, который ничего не меняет для видимости вашего сайта в поиске.

Отобразите баннер или всплывающее окно: Баннер или всплывающее окно div на всех страницах, включая целевую страницу, быстро проясняет статус для пользователей. Упомяните любые известные и необычные задержки, сроки доставки, варианты самовывоза или доставки, чтобы пользователи продолжали работу с правильными ожиданиями. Чтобы предотвратить отображение контента баннера или всплывающего окна во фрагменте в результатах поиска, используйте HTML-атрибут data-nosnippet. Обязательно следуйте нашим рекомендациям по всплывающим окнам и баннерам.

Обновите свои структурированные данные: Если ваш сайт использует структурированные данные (например, Product, Book, Event), обязательно настройте их соответствующим образом (отражая текущую доступность продукта или меняя события на отмененные). Если у вашего бизнеса есть физическая витрина, обновите структурированные данные Local Business, чтобы отразить текущие часы работы.

Проверьте свой фид Merchant Center: Если вы используете Merchant Center, следуйте лучшим практикам для атрибута доступности.

Сообщите Google о своих обновлениях: Чтобы попросить Google повторно просканировать ограниченное количество страниц (например, домашнюю страницу), используйте Search Console. Для большего количества страниц (например, всех ваших страниц продуктов) используйте карты сайта.

Не рекомендуется: Отключение всего веб-сайта

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

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

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

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

Верификация Search Console не удастся, и вы потеряете весь доступ к информации о вашем бизнесе в поиске. Сводные отчеты в Search Console потеряют данные, так как страницы будут удалены из индекса.

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

Если вы решили, что вам нужно это сделать (опять же, не рекомендуется), вот несколько вариантов:

Если вам нужно срочно отключить сайт на 1-2 дня, верните информационную страницу ошибки с кодом состояния ответа HTTP 503 вместо всего контента. Обязательно следуйте лучшим практикам по отключению сайта.

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

Если вам нужно быстро скрыть свой сайт в поиске, пока вы обдумываете варианты, вы можете временно удалить веб-сайт из поиска.

Лучшие практики по отключению сайта

Предупреждение: Имейте в виду, что системы Google не могут обновлять заголовки, описания, метаданные или структурированные данные, включенные на веб-сайт, если страница возвращает код состояния ответа HTTP 503.

Хотя мы не рекомендуем отключать ваш сайт, вот несколько лучших практик, если вы решите это сделать:

Продолжайте разрешать сканирование через файл robots.txt. Не возвращайте код состояния ответа HTTP 503 для файла robots.txt, так как это блокирует все сканирование.

Подтвердите код состояния ответа HTTP 503 локально с помощью curl или аналогичного инструмента. Например:curl -I -X GET “https://www.example.com/” HTTP/1.1 503 Service Unavailable Mime-Version: 1.0 Content-Type: text/html (…)

Чтобы минимизировать нагрузку на стороне сервера и клиента страницы ошибки 503, следуйте этим лучшим практикам: Используйте HTTP-заголовок retry-after с датой или продолжительностью, приложенными с максимальными усилиями.

Дайте своим пользователям четкие указания о будущих шагах в содержании страницы ошибки. Это может включать: Ссылки на дополнительную информацию

Дата, когда вы ожидаете, что веб-сайт снова будет онлайн, или когда информация будет обновлена

Не запрещайте все сканирование в файле robots.txt. Возврат действительного файла robots.txt, который запрещает все сканирование, может удалить контент веб-сайта и, возможно, его URL-адреса из Google Search.

Не блокируйте веб-сайт, возвращая коды состояния HTTP 403, 404, 410, или с помощью метатега robots noindex или HTTP-заголовка x-robots-tag. Это удалит URL-адреса веб-сайта из Google Search.

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

Часто задаваемые вопросы

Что если я закрою сайт только на несколько недель? Что если я хочу исключить все второстепенные продукты? Могу ли я попросить Google сканировать меньше, пока мой сайт временно закрыт? Как мне быстро проиндексировать или обновить страницу? Что если я заблокирую доступ к своему сайту для определенного региона?

Связанная услуга: Маркетинговое агентство с ИИ