Верификационный файл не должен выполнять переадресацию как исправить

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

HTML-файл

Этот способ можно использовать только при наличии веб-сервера у домена.

Для подтверждения необходимо:

1. Создать файл с персональным именем и содержимым, которые описаны на вкладке;

   

2. Загрузить созданный файл в корневой каталог вашего веб-сервера; 
3. Убедиться, что загруженный файл доступен. Проверить это можно перейдя по ссылке, указанной на вкладке HTML- файл.  
4. Вернуться на вкладку «HTML-файл» на странице подтверждения домена и нажать «Подтвердить».
   

Верификационный файл не должен содержать ничего, кроме кода подтверждения.

Meta-тег

 Данный способ также можно использовать только при наличии собственного сайта.

Для подтверждения необходимо:

1. Добавить тег с персональным кодом, написанным на вкладке, в раздел head главной страницы сайта;

    

2. Вернуться на вкладку «Meta-тег» на странице подтверждения домена и нажать «Подтвердить».

DNS-проверка

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

Для подтверждения своих прав на домен:

1. Перейдите на сайт провайдера, у которого находится DNS-зона управления вашим доменом;
2. Введите логин и пароль для входа в «Панель управления»;
3. Перейдите в раздел управления DNS-зонами необходимого домена;
4. Добавьте новую TXT-запись с данными, указанными на вкладке «DNS-проверка» на странице подтверждения домена: 

5. Вернитесь на вкладку «DNS-проверка» на странице подтверждения домена  и нажмите «Подтвердить».

DNS-перенос

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

Для подтверждения своих прав на домен:

1. Перейдите на сайт регистратора, на котором расположен ваш домен;
2. Введите логин и пароль для входа в «Панель управления»;
3. Перейдите в раздел управления DNS-зонами необходимого домена;
4. На открывшейся странице замените текущие значения напротив NS1 (первичный DNS-сервер) и NS2 (вторичный DNS-сервер) на те, которые указаны на вкладке «Перенос DNS» на странице подтверждения домена: 

1. Вернитесь на вкладку «DNS-проверка» на странице подтверждения домена  и нажмите «Подтвердить».

Следующий шаг — настройка MX-записи

Обновлено: 09.02.2023

Если не удается подтвердить права на сайт, посмотрите инструкции.

Если у вас остались вопросы, уточните тему обращения, чтобы вопрос попал к нужному специалисту.

Сайт не добавляется из-за настроек сервера Другой вопрос о добавлении сайта При подтверждении прав возникла ошибка У меня сбросились права Как посмотреть информацию без подтверждения прав Пожелания по добавлению сайта и подтверждению прав

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

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

Информация в DNS еще не успела обновиться (это может занять некоторое время). Попробуйте подтвердить права на следующий день.
Сайт работает по IPv4 и IPv6. Убедитесь, что по всем IP-адресам сайт отвечает корректно.

Если вы не знаете, как сделать txt-запись в DNS, обратитесь в службу поддержки сервиса, на DNS которого делегирован ваш сайт. Например, это может быть регистратор доменных имен.

Содержимое полученного HTML-файла отличается от требуемого

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

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

Если сайт работает по IPv4 и IPv6. Убедитесь, что по всем IP-адресам сайт отвечает корректно.

Робот Вебмастера не смог просмотреть главную страницу вашего сайта. Это могло произойти по следующим причинам:

Главная страница вашего сайта недоступна. Проверьте, открывается ли она в браузере.
Сайт работает по IPv4 и IPv6. Убедитесь, что по всем IP-адресам сайт отвечает корректно.

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

Метатег, который необходим для подтверждения прав на управление сайтом, должен располагаться в HTML-коде главной страницы сайта, в элементе head .

Если вы добавите метатег в другое место главной страницы, то права подтвердить не удастся.

Сайт работает по IPv4 и IPv6. Убедитесь, что по всем IP-адресам сайт отвечает корректно.
При проверке прав робот получил ответ, отличный от 200 OK

При обращении основного робота Яндекса или робота Вебмастера к документам на вашем сайте сервер отвечает кодом, отличным от 200 OK. Поэтому права не могут быть подтверждены.

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

Если сайт работает по IPv4 и IPv6. Убедитесь, что по всем IP-адресам сайт отвечает корректно.

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

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

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

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

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

На хостинге RU-CENTER в настоящее время используется веб-сервер Apache версии 2.4.

Директивы файла .htaccess действуют для каталога, в котором размещён такой файл, и для всех его подкаталогов. Если вы желаете с помощью .htaccess изменить настройки для сайта в целом, его следует размещать в корневом каталоге сайта

Пожалуйста, будьте внимательны при редактировании файла .htaccess! При сохранении такого файла в кодировке UTF-8 в нём не должно присутствовать BOM-сигнатуры. Для редактирования файла .htaccess и других конфигурационных файлов мы рекомендуем использовать не «Блокнот» Windows, а специальные текстовые редакторы, например Notepad++.

Примеры использования файла .htaccess

1. Перенаправление доменов c синонима сайта на основной домен с кодом 301

Эти правила рекомендуется размещать в самом начале файла .htaccess.

2. Постоянное перенаправление с кодом 301

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

Подобное правило не сработает для перенаправления с адресов, содержащих Query String (символы после ?). Для запросов, содержащих QUERY_STRING, можно использовать сочетание RewriteCond и RewriteRule.

3. Переопределение страниц ошибок

При помощи файла .htaccess вы можете установить свои страницы ошибок:

Соответствующие файлы страниц ошибок (401.html, 404.html и др.) необходимо разместить в каталоге

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

User-agent: *
Disallow: /errors

/ваш_домен/docs/errors/.htaccess, в котором прописать

4. Постраничное перенаправление запросов на другой домен c кодом 301

5. Ограничение доступа к сайту по IP

Запретить доступ к сайту с IP-адресов 123.4.5.6 и 123.5.4.3

Order Allow,Deny
Allow from all
Deny from 123.4.5.6 123.5.4.3

Запретить доступ к сайту со всех адресов кроме 123.4.5.6 и 123.5.4.3:

Order Deny,Allow
Deny from all
Allow from 123.4.5.6 123.5.4.3

Запретить доступ к сайту для всех:

6. Переопределение главной страницы сайта (индексного файла каталога)

Сделать главной страницей файл menu.html:

7. Включение обработки PHP в .html-файлах

8. Запрет выдачи листинга каталога

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

9. Включить выполнение CGI-скриптов в папке docs для файлов с расширениями .cgi, .pl. .py

В папке c CGI-скриптами необходимо разместить файл .htaccess с содержимым:

AddHandler cgi-script .cgi .pl .py
Options +ExecCGI

Скрипт должен иметь атрибут исполнения (+x, права доступа, начинающиеся с 7, например, 755).

Атрибуты (права доступа) можно изменить с помощью файлового менеджера панели управления, при помощи вашего FTP-клиента или по SSH . Также в разделе Веб-сервер → Управление модулями должен быть включен модуль CGI.

10. Блокировка переходов со сторонних ресурсов

Если требуется запретить переходы с нескольких доменов, то используйте следующие директивы

В файле .htaccess использование кириллицы не допускается. При составлении правил перенаправления для кириллических доменов необходимо указывать имя домена в punycode. Узнать имя домена в punycode можно с помощью сервиса Whois.

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

Для работы перенаправления на сайте должен быть установлен действительный SSL-сертификат.

3. Диагностика ошибок

Если после редактирования или размещения .htaccess при обращении к сайту вы получили ошибку 500, то, скорее всего, в файле .htaccess допущена ошибка. Посмотреть её причины вы можете в лог-файле /var/log/ваш_домен.error_log.

FBL (Feedback Loop) — это стандарт выдачи информации о жалобах на спам отправителю писем от провайдера услуг электронной почты.

Отправитель, обрабатывая FBL-отчеты, может:

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

3. Подтвердите домен одним из предложенных способов: HTML-файл, Meta-тег, DNS-проверка.

Ниже приведены инструкции для подтверждения домена, размещенного на NS-серверах Getcourse. Если ваш домен размещен на сторонних серверах — рекомендуем обратиться в тех.поддержку вашего хостера.

Как подтвердить владение доменом на сервисе Postmaster для Mail

Как подтвердить домен с помощью HTML-файла?

Как подтвердить владение доменом с помощью Мета-тэга?

Как подтвердить владение доменом с помощью DNS-проверки, если домен делегирован на NS-сервер GetCourse?

5. Настройте переадресацию отчетов из доменного ящика fbl@ на системный адрес для fbl-отчетов.

Для автоматических отписок получателей с адресами почтовых провайдеров Yandex и Gmail используется другая технология — List-Unsubscribe. При получении письма у такого пользователя есть возможность нажать «Отписаться» прямо в панели почтовой службы.

Пользователи, нажавшие «Отписаться» в Yandex или Gmail, автоматически отписываются и в GetCourse. Поэтому дополнительно настраивать FBL в этих сервисах не нужно.

Отписка из почтового ящика Яндекса по технологии List-Unsubscribe

Как смотреть статистику в Postmaster?

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

В разделе «Письма» вы можете посмотреть детализированную статистику по каждому типу писем.

На вкладке «Статистика» отображается статистическая информация за выбранный период по следующим параметрам:

Жалобы — количество писем, на которые пожаловались пользователи (нажали на кнопку «Спам»).
Репутация % — средний процент жалоб за последние 30 дней (чем меньше величина, тем лучше).
Тенденция — изменение процента жалоб за последние 7 дней по отношению к проценту за последние 30 дней.
Прочитанные — количество открытых писем за выбранный период (письмо может быть открыто несколько раз).
Удаленные прочитанные — количество удаленных открытых писем за выбранный период;
Удаленные непрочитанные — количество удаленных непрочитанных писем за выбранный период.

Доставлено % — процентное соотношение следующего типа писем:

Что такое переадресация 301

Permanent Redirect 301 применяется с целью организации постоянной переадресации с неактуального доменного адреса или url отдельной страницы на рабочую версию. Редирект может понадобиться в связи с глобальным переносом сайта на другой домен, техническими изменениями в написании адреса, удалением страниц, необходимостью внутренней и внешней перелинковки. Один из вариантов использования перманентной переадресации – редирект с нескольких доменных имен, созданных в разных зонах, на один актуальный адрес. Грамотное использование редиректа позволяет перемещать контент без потерь в поисковой индексации, сохранить и даже увеличить прежний вес и позицию в выдаче.

с помощью HTML и PHP;

через панель управления или плагины соответствующей CMS;

при помощи специальных скриптов (программ);

на уровне хостинг-провайдера;

внесением соответствующих записей в файлы .htaccess для сервера Apache или web.config для IIS.

Последний способ является наиболее простым и надежным. О нем чуть позже поговорим подробнее.

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

• Редирект 302. Применяется в случае временной переадресации с одного url на другой. При его использовании поисковая система индексирует все доступные версии сайта или страницы. Объединения ссылочного веса и внутренних метрик на приоритетном ресурсе не происходит.
• 307 Temporary Redirect рекомендуется применять в исключительных случаях. Например, при техническом обслуживании сайта, когда он недоступен некоторое время.
• Обновления Meta Refresh выполняют переадресацию не на уровне сервера, а непосредственно на сайте. Пользователь сталкивается с временной задержкой (обычно около пяти секунд), после чего для перехода на нужную страницу должен принудительно запустить определенную команду. Этот метод часто приводит к падению посетительского интереса и проседанию поисковых индексов.
• Редирект rel=«canonical». Позволяет сохранить доступ посетителям ресурса к контенту дублирующихся страниц. При этом для поисковиков наличие команды canonical на одной из страниц говорит о том, что только она подлежит индексации в поиске.

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

В каких случаях используется постоянный редирект 301

Для аккумуляции трафика с адресов, купленных в разных доменных зонах, на один приоритетный ресурс.

Исключение дублирующихся страниц из индекса.

Для быстрого перехода пользователя на мобильную версию ресурса со смартфонов и планшетных устройств.

Создание постоянной переадресации 301 через настройки и плагины CMS

В большинстве популярных конструкторов сайтов и CMS (OpenCart, Joomla!, Битрикс, Wix, Тильда) предусмотрена настройка редиректов с помощью встроенных инструментов. Если сайт создан с помощью WordPress, для настройки переадресации можно воспользоваться следующими плагинами:

Redirection — самый популярный плагин для настройки редиректов. Кроме основной функции обладает следующими возможностями: сбором статистики переадресаций, отслеживанием ошибок 404, поддержкой регулярных выражений.

Safe Redirect Manager — простой плагин, который также поддерживает регулярные выражения, практически не влияет на производительность сайта.

Quick Page/Post Redirect Plugin — еще один удобный инструмент оптимизации. Один из недостатков — отсутствие поддержки регулярных выражений. К ссылкам можно добавлять атрибут «nofollow».

Simple 301 Redirects. Данный модуль обладает одним недостатком – url для переадресации необходимо прописывать вручную.

Настроить Permanent Redirect 301 в Вордпресс можно и через редактирование файла .htaccess в разделе управления хостингом. Чтобы подключиться к нему, потребуется использовать FTP-клиент. Сама кодировка производится по общим правилам настройки переадресации в .htaccess.

Чтобы настроить 301 редирект в CMS OpenCart в файле .htaccess необходимо прописать:

Для Битрикс кодировка будет выглядеть следующим образом:

В Joomla настройки переадресации производятся через панель администратора в разделе «Компоненты» => «Перенаправление». Здесь можно не только установить правила редиректа, но и отслеживать страницы с битыми ссылками и перенаправлять их на корректные адреса.

С конструкторами сайтов все не так однозначно. Например, один из наиболее популярных CMS-конструкторов WIX не предоставляет возможности создания файла .htaccess.

Но настроить редирект 301 довольно просто в базовом редакторе.

Настройка 301 редирект в .htaccess

Файл с расширением .htaccess – это дополнительный конфигурационный файл web-сервера Apache. Его используют для настройки веб-сервера, а также для обработки различных URL-адресов.

Для настройки 301 редиректа в файле .htaccess чаще всего применяют одну из трех директив: Redirect, RedirectMatch или RewriteRule. Директивы относятся только к папке, где размещен .htaccess, а оттуда распространяются на дочерние папки.

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

Для создания 301 редиректа перейдите в панель управления вашего сайта.

Проверьте наличие .htaccess файла в корневом каталоге сайта (public_html, если используете WordPress). Если файл отсутствует, создайте его.

Рекомендуем все условия редирект записывать в блоке IfModule, дабы избежать ошибок при выполнении файла htaccess.

Перед тем как начать прописывать правила перенаправления, необходимо включить механизм преобразований (RewriteEngine) при помощи команды RewriteEngine On.

Хостинги применяют по умолчанию 302 или любой другой 3xx редирект. В связи с этим в правилах используются флаги. Рекомендуем дописывать в своих правилах [R=301,L].

Разберем наиболее распространенные варианты создания 301 редиректа через .htaccess.

Склейка зеркал сайта (www / без www)

В поисковой системе сайт по одному адресу будет проиндексирован, а по второму адресу зафиксирован как дубль, что может повлиять на продвижение ресурса. Для избегания дублей необходимо сделать так называемую «склейку» сайта, то есть прописать 301 редирект в .htaccess.

Если изначально в индекс поисковой системы попала версия «с www», в файл .htaccess добавляется редирект на «без www»:

Если произошла обратная ситуация и необходима переадресация с без «www» на «www», то в файл прописывается:

Если данная конструкция не сработает, попробуйте другой вариант:

Если редирект не работает и в этом случае, попробуйте такой вариант:

Постранично

Для одной страницы

Изменение домена

В том случае. если необходимо перейти на другой домен, при этом сохранив SEO-позиции, в файл .htaccess прописывают следующее:

Редирект на страницу с другим url (без параметров)

Иногда возникает ситуация, когда необходимо изменить url страницы, то есть перенести данные с одной страницы на другую страницу, при этом не потеряв вес страниц. В этом случае в файл .htaccess прописывают следующее:

Редирект для url (с параметрами)

Редирект с index.php на главную страницу

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

Редирект со страниц со слешем на без слеша (для всего сайта)

Для избегания дублей в файле .htaccess используют следующую конструкцию:

Или более короткий вариант:

Редирект со страниц без слеша на слеш (для всего сайта)

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

301 редирект с 404 Not Found

301 редирект для страниц 404 Not Found сделать совсем не сложно. Например, этот код перенаправит со всех 404-страниц на главную:

Однако делать такие редиректы в массовом порядке не рекомендуется, так как это может испортить SEO-статистику всего ресурса.

Финальный вид файла .htaccess

Пример файла htaccess, после добавления в него редиректов:

Синтаксис для регулярных выражений в .htaccess

точка заменяет произвольный символ

обозначает перечень знаков, совпадающих с буквами a, b, или с

список символов вне указанного диапазона (кроме a, b, с)

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

команда найдет идущие подряд символы из заданного набора

приводит к противоположному эффекту

заменяет любой набор символов

ищет все подстроки между кавычками

начало строки (когда используется в начале выражения)

означает конец строки

цифра, буква или подчеркивание _

заменяет любую цифру

может заменить любой знак, кроме цифры

для замены любой цифры

для всех букв от a до z в нижнем регистре

для каждой буквы от A до Z в верхнем регистре

любая буква от a до Z во всех регистрах

Важно учитывать, что настройка редиректа путем редактирования файла .htaccess доступна исключительно для веб-серверов Apache.

Другие способы создания переадресации 301

Через PHP

Данный вариант подойдет тем, кто хорошо разбирается в web-программировании и PHP. Необходимо открыть файл index.php в корне CMS-движка и прописать там:

(в первой строке укажите старый url, а во второй — новый)

Второй способ — перенаправление при помощи отправки заголовков (скрипта):

ASP-редирект

Найдите в корне своего сайта файл web.config и вставьте в секцию синтаксис:

ColdFusion редирект

JSP (Java) редирект

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

CGI-скрипт на PERL

Ruby on Rails

Редирект в Nginx

HTML-редирект

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

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

Редирект 301 в панелях управления сервера

Большинство панелей управления сервера предоставляют возможность настройки переадресации с кодом 301. Рассмотрим варианты решения этой задачи на примере двух популярных ПУ для VDS.

Cpanel

Нужно перейти в блок «Домены» => «Перенаправления». В появившемся окне выполнить следующее:

В строке «Тип» выбрать «Постоянный 301».

В блоке «Перенаправление www» поставить галочку напротив «Перенаправлять только с www».

Сохранить изменения кликом на «Добавить».

ISPmanager

Автоматическое создание переадресации

При отсутствии знаний и опыта самостоятельной настройки редиректа можно воспользоваться сервисами автоматической генерации:

Generate .htaccess— для страниц, разделов сайтов, доменов.

Проверка корректности настроек 301 редиректа

Самый простой способ проверки переадресации – ручное тестирование. Для этого необходимо вставить в адресную строку браузера url сайта или страницы, с которой настроено перенаправление. Если при открытии будет доступен ресурс, на который настроен редирект, то переадресация выполняется правильно.

Для автоматической проверки можно воспользоваться специальными сервисами:

программой Screaming Frog Seo Spider, способной просканировать весь сайт.

Существует ряд ошибок, которые следует избегать при настройке редирект 301:

использование перенаправлений между страницами сайта без изменения их url в ссылках;

установка временной переадресации вместо постоянной;

неправильный выбор типа редиректа;

перенаправление файла robots.txt;

непонимание разницы между rel=canonical и кодом 301;

редирект на нерелевантный контент;

переадресация, которая не приводит к 200-й странице.

Стоит отметить проблему создания цепочки ссылок, которая может привести к появлению циклического редиректа — ошибки с кодом «ERR_TOO_MANY_REDIRECTS». Наиболее распространенные причины возникновения такого бага – неправильная настройка в процессе создания переадресации, вирусная атака, слишком длинная цепочка редиректов. Не рекомендуется настраивать редирект, содержащий более пяти адресов. Оптимальной является прямая переадресация со старого на новый url.

Заключение

Использование редиректа 301– очень важный способ поисковой и пользовательской оптимизации веб-ресурса. Использовать его следует с осторожностью. Неправильная настройка может привести к сбоям в работе сайта и потере поисковых позиций.

Читайте также:

  

• Как добавить вк в исключения антивируса

  

• Настройка hdr в assassins creed odyssey ps4

  

• Xbox one не входит в учетную запись

  

• Как отправить форму 13014 с эцп в налоговую

  

• Гаснет экран ноутбука но сам работает

Как подтвердить право собственности на сайт

Для чего нужно подтверждать право собственности на сайт?

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

Для чего нужны разные уровни доступа?

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

Как подтвердить право собственности на сайт

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

Использование нескольких способов подтверждения

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

Чтобы добавить ещё один способ, перейдите на страницу Настройки своего ресурса и нажмите Подтверждение права собственности.

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

Как подтвердить право собственности на дочерние ресурсы

Когда вы подтвердите право собственности на родительский ресурс, процедура будет автоматически выполнена тем же способом для всех добавленных вами дочерних ресурсов. Например, если вы подтвердили право собственности на сайт example.com путем загрузки HTML-файла, то все созданные вами дочерние ресурсы этого сайта, например m.example.com или https://example.com/some/path, будут также автоматически подтверждены при помощи загрузки HTML-файла.

Каков срок действия подтверждения?

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

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

Для проверки права собственности на сайт Google использует агент пользователя Google Site Verifier.

Когда начнут появляться данные?

Сбор данных начинается сразу после добавления ресурса в аккаунт Search Console и ещё до подтверждения права собственности. При этом иногда данные о ресурсе начинают поступать лишь спустя несколько дней.

У этого сайта больше нет ни одного подтвержденного владельца.

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

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

Как выбрать способ подтверждения

Search Console поддерживает несколько способов подтверждения. Вы можете выбрать наиболее подходящий из таблицы ниже.

Способ	Примечания
Размещение HTML-файла на сервере	Этот способ относительно прост, но использовать его можно только в том случае, если у вас есть возможность загрузить файл и опубликовать его по определенному URL. Он не всегда подходит для платформ веб-хостинга.
HTML-тег	Этот способ относительно прост, но необходимо, чтобы у вас была возможность редактировать исходный HTML-код главной страницы сайта. При использовании платформы веб-хостинга подтвердить право собственности таким способом может не получиться.
Код отслеживания Google Аналитики	Это простой способ, который можно использовать, если на странице уже внедрен код отслеживания, связанный с доступным вам аккаунтом Google Аналитики. Если на странице нет кода отслеживания, его нужно добавить (для этого необходимо иметь или создать аккаунт Google Аналитики).
Google Менеджер тегов	Это простой способ, который можно использовать, если на странице уже есть фрагмент кода, связанный с доступным вам аккаунтом Google Менеджера тегов. Если такого фрагмента кода нет, добавьте его (для этого необходимо иметь или создать аккаунт Менеджера тегов).
Аккаунт Google Сайтов, Blogger или Google Domains	Используйте рекомендуемый способ для каждой из этих платформ.
Провайдер доменных имен	Этот способ более сложен, однако при работе с доменными ресурсами подходит только он. Процедура подтверждения значительно упрощается, если ваш провайдер упомянут в списках мастера подтверждения. Преимущество доменных ресурсов состоит в том, что они содержат данные по всем протоколам (HTTP и HTTPS) и вариантам субдоменных имен вашего сайта.

Подробные сведения о способах подтверждения

Сайты на платформах веб-хостинга, таких как WordPress, Shopify, Wix

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

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

1. В документации своей платформы веб-хостинга найдите сведения о подтверждении прав собственности в Search Console. Для этого можно использовать такие поисковые запросы, как wix подтверждение для search console, weebly подтверждение для search console или shopify search console.
2. Найдите плагины для вашей платформы, с помощью которых можно подтвердить право собственности на ресурс. Пример такого плагина – Site Kit для WordPress. Он также позволяет просматривать данные из Search Console в упрощенном виде. Обратите внимание, что Site Kit – это единственный плагин, официально спонсируемый компанией Google. Если вы решили установить другой, сначала изучите информацию о нем.

Размещение HTML-файла на сервере

Учебный курс по Google Search Console: подтверждение права собственности на сайт путем загрузки HTML-файла

Общие сведения

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

⚠️ Требования

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

Инструкции

Чтобы подтвердить право собственности с помощью HTML-файла, выполните следующие действия:

1. Если сайт размещен на платформе веб-хостинга, изучите ее документацию, чтобы узнать, как подтвердить право собственности в Search Console. Если вы не нашли никакой информации, выполните действия, описанные ниже.
2. Изучите требования, которые относятся к этому способу подтверждения.
3. На странице подтверждения права собственности на ваш ресурс выберите способ HTML-файл.
4. Скачайте файл, который будет использоваться для подтверждения. Это уникальный файл, который связан с вашим аккаунтом Gmail и недоступен другим лицам.
5. Загрузите файл на свой сайт так, чтобы он был доступен по адресу, указанному в инструкциях на странице, с которой вы скачали этот файл. Обычно добавлять его нужно в корневой каталог ресурса. Например, если URL вашего ресурса – https://example.com, а имя файла для подтверждения – 1234.txt, то после загрузки он должен быть доступен по адресу https://example.com/1234.txt. При поиске этого файла Search Console игнорирует переадресацию. При необходимости можно добавлять новые строки в конце текста файла, но не меняйте название и остальные элементы.
6. Убедитесь, что файл доступен. Для этого откройте его в браузере по адресу, указанному в мастере подтверждения Search Console. Если файл недоступен в вашем браузере, Google также не сможет найти его. Совет. Используйте окно браузера в режиме инкогнито: это поможет вам убедиться в том, что для доступа к файлу не нужно входить в аккаунт.
7. Завершите процедуру, нажав Подтвердить.
8. Если возникли проблемы, то попробуйте устранить их, пользуясь инструкциями из раздела Возможные ошибки ниже.

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

При подтверждении права собственности путем размещения HTML-файла могут возникнуть следующие ошибки:

• Не удалось найти файл подтверждения.
  Search Console не удалось найти файл подтверждения в корневом каталоге вашего ресурса. Загрузите этот файл на сайт, не внося в него никаких изменений. В противном случае мы не сможем подтвердить ваше право собственности на сайт. Чтобы проверить наличие файла, попробуйте перейти к нему в браузере.
• Неверное содержание в файле подтверждения.
  В файл подтверждения, полученный от Search Console, не следует вносить изменения. Если название файла или его содержание не совпадает с данными, которые Search Console предоставляет вошедшему в систему пользователю, мы не можем подтвердить право собственности на сайт. Загрузите в указанный каталог именно тот файл, который вы получили от Search Console.
• Файл подтверждения взломан.
  Если вам не удается подтвердить право собственности, причина проблемы может заключаться в том, что сайт взломан. Подробнее о том, как выявить взлом и устранить связанные с ним проблемы…
• Ваш файл подтверждения выполняет переадресацию на запрещенную страницу.
  Search Console при обработке файлов подтверждения проигнорирует переадресацию на другие домены, однако будет выполнять ее в том же домене. Перейдите к своему файлу и посмотрите, требуется ли при этом переадресация на другой домен. Если ваш сайт выполняет переадресацию трафика на другой сайт, рекомендуется использовать подтверждение с помощью HTML-тега. Примеры поддерживаемых и неподдерживаемых переадресаций:
  • С http://example.com на http://www.example.com – поддерживается.
  • С http://example.com на https://example.com – поддерживается, поскольку это перенаправление на другой протокол (HTTP/HTTPS).
  • С example.com на foo.com – не поддерживается.
  • С m.example.com на example.com – поддерживается.
  • С example.com на m.example.com – поддерживается.
• Другие распространенные проблемы с подтверждением, которые перечислены ниже.

HTML-тег

Учебный курс по Google Search Console: подтверждение права собственности на сайт с помощью HTML-тега

Общие сведения

Ещё один способ подтвердить право собственности на сайт – добавить наш тег <meta> в HTML-код определенной страницы. Мы проверим наличие тега на ней. Если найти этот тег не удастся, мы сообщим вам об ошибке. Каждый такой тег связан с конкретным пользователем. Search Console периодически проверяет наличие этого тега.

⚠️ Требования

• Не следует требовать от пользователей аутентификации на главной странице сайта: такая страница должна быть доступна без входа в аккаунт.
• У вас должна быть возможность напрямую изменять исходный HTML-код главной страницы сайта, чтобы добавить тег в ее раздел <head>. Если это не так, то примените другой способ. Если сайт размещен на платформе веб-хостинга, изучите ее документацию, чтобы узнать, можно ли это сделать.
• Размер страницы с добавленным тегом не должен превышать 2 МБ. При этом внешние ресурсы, например скрипты, на размер не влияют. Это ограничение коснется очень малого количества сайтов.
• Этот способ подтверждения подходит для ресурсов с префиксом в URL, но не для доменных ресурсов.

Инструкции

Чтобы подтвердить право собственности с помощью HTML-тега, выполните следующие действия:

1. Если сайт размещен на платформе веб-хостинга, изучите ее документацию, чтобы узнать, как подтвердить право собственности в Search Console. Если вы не нашли никакой информации, выполните действия, описанные ниже.
2. Изучите требования, которые относятся к этому способу подтверждения.
3. На странице подтверждения права собственности на ваш ресурс выберите способ HTML-тег.
4. Скопируйте тег из мастера подтверждения Search Console в раздел <head> HTML-кода вашей главной страницы, не входя в аккаунт (см. примечание). Пример:
   <head>
<title>Example.com homepage</title>
<meta name="google-site-verification" content="......." />
</head>
   Это уникальный тег, который связан с вашим аккаунтом Gmail и не может использоваться другими лицами.
5. Сохраните страницу. Проверьте, удалось ли добавить тег: откройте страницу и найдите тег в ее исходном коде. Для этого нажмите Ctrl + F и в строке поиска введите «google-site-verification».
6. Завершите процедуру, нажав Подтвердить.
7. Если возникли проблемы, то попробуйте устранить их, пользуясь инструкциями из раздела Возможные ошибки ниже.

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

При подтверждении права собственности путем добавления HTML-тега могут возникнуть следующие ошибки:

• Метатег не найден или размещен не там, где нужно. Метатег подтверждения должен находиться в разделе <head> страницы. Если появляется сообщение о подобной ошибке, вот что следует проверить:

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

  • В нужном ли месте страницы находится метатег? Предполагается, что он размещен в разделе <head>. Пример правильного расположения метатега приведен ниже.

    <html>
      <head>
        <title>Название страницы</title>
        <meta name="google-site-verification" content="строка с кодом подтверждения">
      </head>
    <body>
    ...
    

  • Если вы изменяете страницу при помощи веб-редактора или редактора WYSIWYG, убедитесь в том, что вы работаете с HTML-кодом опубликованной на сайте страницы, а не с сохраненной на компьютере копией.
• Неправильный метатег.
  Мы нашли метатег для подтверждения, но он неправильный. Во избежание ошибок скопируйте метатег со страницы подтверждения в Search Console. Такая ошибка может возникнуть, если тег на этой странице уже был ранее размещен другим пользователем. Убедитесь, что вы скопировали тег из мастера подтверждения Search Console в HTML-код страницы без ошибок.
• Неверный формат метатега.
  Мы нашли метатег на вашей странице, но в нем есть синтаксическая ошибка. Скопируйте метатег из Search Console и добавьте его в исходный HTML-код страницы. Учтите, что при посещении страницы тег не отображается в браузере. Вы увидите его только при просмотре HTML-кода, на основе которого создается страница.
• Другие распространенные проблемы с подтверждением, которые перечислены ниже.

Провайдер доменных имен

Учебный курс по Google Search Console: подтверждение права собственности на сайт с помощью записи DNS

Общие сведения

Вы можете подтвердить право собственности, добавив запись DNS в список записей вашего провайдера доменных имен. Это требуется сделать только для доменного ресурса, такого как example.com, но не для ресурсов с префиксом в URL, например https://example.com. Если использовать этот способ для ресурса с префиксом в URL, то также будет автоматически подтверждено право собственности на доменный ресурс.

Для некоторых доменов Google может добавить нужную запись вместо вас. В остальных случаях вам понадобится сделать это самостоятельно.

Подтверждать право собственности можно на корневые домены, такие как example.com, и на субдомены, например m.example.com. В первом случае автоматически подтверждается право собственности и на все субдомены корневого домена, а во втором случае подтверждение не распространяется на родительский домен. Например, доказав, что вы владелец домена m.example.com, вы также подтвердите право собственности на pets.m.example.com, но не на example.com.

⚠️ Требования

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

Инструкции

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

1. Если сайт размещен на платформе веб-хостинга, изучите ее документацию, чтобы узнать, как подтвердить права на сайт в Search Console. Рекомендуем также ознакомиться с информацией о том, как узнать, кто ваш поставщик услуг DNS. Если вы таких инструкций не нашли, выполните действия, описанные ниже.
2. На странице подтверждения права собственности на ваш ресурс выберите способ Провайдер доменных имен. Если вы создадите доменный ресурс, такой способ будет выбран автоматически.
3. • Если в Search Console создана запись TXT, добавьте запись DNS в формате TXT вручную по инструкциям из соответствующего раздела ниже.
   • Если в списке Search Console указан ваш провайдер доменных имен, выберите его, нажмите Начать подтверждение и следуйте инструкциям на экране. Вам понадобится войти в систему провайдера, и сразу после этого право собственности будет подтверждено.
   • Если в списке Search Console указан другой провайдер доменных имен, выберите вариант любой и добавьте запись DNS вручную по инструкциям из соответствующего раздела ниже.

     Как добавить запись DNS вручную

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

     1. Определите, какой формат записи DNS нужно использовать. TXT или CNAME (это зависит от конфигурации вашего сайта). Ниже описывается, как правильно выбрать формат.
        1. Откройте Набор инструментов администратора Google и выберите вкладку CNAME.
        2. Введите доменное имя своего ресурса. Это часть URL после префикса https://. Например, доменное имя ресурса https://www.example.com/ – www.example.com.
        3. Посмотрите на полученный результат. Нажмите на вкладку CNAME.
     2. Следуйте приведенным ниже инструкциям для записей в формате TXT или CNAME.

     Инструкции для записей DNS в формате TXT

     1. Создайте уникальную запись TXT для подтверждения в Search Console. Когда потребуется подтвердить доменный ресурс в Search Console, в разделе Выберите тип записи всплывающего окна подтверждения нужно выбрать TXT. Search Console сгенерирует запись TXT, которая понадобится вам на следующем шаге.
     2. Внесите полученную запись DNS в систему регистратора доменов. Чтобы добавить запись TXT, созданную в Search Console, к записям вашего провайдера доменных имен, выполните следующие действия:
        1. Откройте профиль своего провайдера в Справочном центре Google Workspace.
        2. Пропустите на открывшейся странице шаг 1 (получение уникального кода подтверждения от Google Workspace), поскольку у вас уже есть запись TXT из Search Console.
        3. Войдите в систему регистратора доменов (обычно это шаг 2 в Справочном центре Google Workspace).
        4. Добавьте запись TXT из Search Console к записям DNS своего домена (обычно это шаг 3 в Справочном центре Google Workspace).
           • Поле Host/Name (Хост/имя) оставьте пустым или введите в нем символ @ (необходимую информацию можно найти в документации вашего поставщика услуг DNS).
           • В поле Value (значение) введите запись TXT из Search Console.
        5. Пропустите в Справочном центре Google Workspace шаг 4 (подтверждение права собственности) и перейдите к шагу 4 ниже на этой странице.

     Инструкции для записей DNS в формате CNAME

     1. Создайте уникальную запись CNAME. Во время подтверждения права собственности на свой доменный ресурс в разделе Выберите тип записи всплывающего окна подтверждения Search Console нужно выбрать CNAME. Вы получите два значения, которые нужно будет использовать на следующем шаге. В зависимости от ситуации первое значение – name, label или host, а второе – destination или target.
     2. Передайте значения записи DNS своему провайдеру доменных имен.
        1. Откройте профиль своего провайдера в Справочном центре Google Workspace.
        2. Пропустите на открывшейся странице шаг 1 (получение уникального кода подтверждения от Google Workspace), поскольку у вас уже есть запись CNAME из Search Console.
        3. Войдите в систему регистратора доменов (обычно это шаг 2 в Справочном центре Google Workspace).
        4. Добавьте запись CNAME к записям DNS своего домена (обычно это шаг 3 в Справочном центре Google Workspace), используя значения, полученные в Search Console. Укажите оба значения в нужных полях на сайте вашего поставщика услуг DNS. Вы можете оставить значение TTL, предложенное поставщиком.
        5. Пропустите в Справочном центре Google Workspace шаг 4 (подтверждение права собственности) и перейдите к шагу 4 ниже на этой странице.

4. Завершите процедуру, нажав Подтвердить в Search Console. Внимание! Если запись была добавлена вручную, вашему провайдеру может понадобиться два-три дня на то, чтобы активировать ее. Поэтому, если вы следовали приведенным выше инструкциям, а право собственности не подтвердилось, подождите пару дней и повторите попытку. О причинах проблем и о том, как посмотреть, активировал ли провайдер доменных имен вашу запись, говорится в разделе Устранение неполадок и возможные ошибки ниже.

Внимание! Чтобы подтверждение оставалось в силе, не удаляйте запись DNS у своего провайдера даже после успешного завершения процедуры.

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

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

1. Откройте Набор инструментов администратора Google.
2. В текстовом поле вверху введите свое доменное имя без префикса протокола и без косых черт (например, для доменного имени https://example.com введите example.com).
3. Нажмите TXT или CNAME в зависимости от того, какую запись вы используете для подтверждения домена (чаще всего это формат TXT).
4. Все записи DNS выбранного типа, имеющиеся у вашего поставщика, будут перечислены в нижней части страницы с обозначением типа (CNAME и TXT – основные).
5. Найдите в списке запись DNS, созданную для вас в Search Console.
   • Запись подтверждения из Search Console в формате TXT выглядит примерно так: google-site-verification=<<число>>.
   • Запись в формате CNAME представляет собой пару «имя-значение», где в имени указан домен вашего ресурса, а значение содержит строку dv.googlehosted.com.

   Запись должна в точности соответствовать той, которая была создана в Search Console. Чтобы свериться с Search Console, снова начните подтверждать право собственности вручную и дойдите до шага, на котором генерируется запись.

6. Учтите, что ваша запись может появиться в списке не сразу, а через пару дней.

Чтобы найти свою запись DNS после подтверждения прав на ресурс, выполните следующие действия:

1. Откройте Google Search Console.
2. Выберите нужный ресурс, чтобы появился список способов подтверждения прав на него.
3. Нажмите Сведения рядом с пунктом Запись DNS TXT или Запись DNS CNAME.
4. Вы также можете посмотреть все записи, действующие у вашего провайдера доменных имен, используя Набор инструментов администратора Google, как описано выше.

При подтверждении права собственности с помощью записи DNS могут произойти следующие ошибки:

• TXT-запись подтверждения для записи DNS не найдена.
  Вашу запись не удалось найти. Иногда она становится доступна Google только через несколько минут или даже суток. Повторите попытку через день или два.
• Для записи подтверждения не нашлось соответствий.
  Ни одна из записей подтверждения в системе вашего поставщика услуг DNS не совпала со значением, полученным вами в Search Console. Убедитесь, что добавили именно значение со страницы, которая относится к подтверждению. Если используется запись TXT, то оставьте поле для ввода пары «имя-значение» пустым и введите строку TXT в поле для записи DNS. Если используется запись CNAME, то введите в этом поле пару «имя-значение», полученную в Search Console.
• Другие распространенные проблемы с подтверждением, которые перечислены ниже.

Код отслеживания Google Аналитики

Учебный курс по Google Search Console: подтверждение права собственности на сайт с помощью Google Аналитики

Общие сведения

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

⚠️ Требования

• Главная страница вашего сайта должна открываться без аутентификации. Другими словами, она должна быть доступна не вошедшим в аккаунт пользователям. Кроме того, страницы, которые требуют ввести пароль, нечасто появляются в результатах поиска, поэтому данных об их поисковом трафике будет собрано немного.
• У вас должны быть права на редактирование в аккаунте Google Аналитики, с которым связана страница. В Google Аналитике 4 код подтверждения связан с потоком. В более ранних версиях сервиса код подтверждения связан с веб-ресурсом.
• Необходимо использовать один аккаунт Google как для Search Console, так и для Google Аналитики.
• На вашу главную страницу (см. примечание) должен быть добавлен фрагмент analytics.js или gtag.js (не забывайте, что для доступа к ней не должен выполняться вход). Код отслеживания должен находиться в разделе <head>, но не в разделе <body> страницы. Чтобы убедиться в его наличии, откройте страницу в браузере, затем перейдите к ее исходному коду и найдите нужный фрагмент.
• Используйте код Google Аналитики только в исходном виде. Если его изменить, он не будет распознан.
• Размер страницы с добавленным тегом не должен превышать 2 МБ. При этом внешние ресурсы, например скрипты, на размер не влияют. Это ограничение коснется очень малого количества сайтов.
• Этот способ подтверждения подходит для ресурсов с префиксом в URL, но не для доменных ресурсов.

Инструкции

Чтобы подтвердить право собственности на ресурс с помощью своего тега Google Аналитики, выполните следующие действия:

1. Изучите требования, которые относятся к этому способу подтверждения.
2. Откройте Search Console, используя аккаунт Google, у которого есть права на редактирование в Google Аналитике, а затем добавьте или выберите нужный ресурс.
3. На странице подтверждения выберите вариант Google Аналитика и нажмите Подтвердить.
4. Если возникли проблемы, то попробуйте устранить их, пользуясь инструкциями из раздела Возможные ошибки ниже.

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

При подтверждении права собственности с помощью кода отслеживания Google Аналитики могут возникнуть следующие ошибки:

• Мы не нашли код отслеживания Google Аналитики на главной странице вашего сайта.
  Код отслеживания Google Аналитики отсутствует на главной странице ресурса.
  • Проверьте, размещен ли фрагмент кода Аналитики в том разделе главной страницы, где он должен быть. Есть ли ваш код на главной странице? (Она должна быть доступна без пароля.)
  • Откройте исходный код страницы и поищите там код отслеживания Google Аналитики. Если он отсутствует, то на вашем сайте не используется (или неверно настроена) Google Аналитика.
• Код отслеживания Google Аналитики на вашем сайте содержит ошибки.
  На странице обнаружен код отслеживания Google Аналитики, но в нем есть ошибки. Добавьте в точности тот код отслеживания, который был вам предоставлен.
• На сайте используется старая версия кода отслеживания Google Аналитики.
  На главную страницу добавлен старый код отслеживания Google Аналитики. Search Console поддерживает только самую новую версию. В старом коде есть строка _gat. или _getTracker|urchin.js.
• Мы обнаружили на вашем сайте код Google Менеджера тегов.
  На вашей странице присутствует код Google Менеджера тегов, а не код Google Аналитики. Подтвердите свой ресурс с помощью Google Аналитики.
• Мы обнаружили на вашем сайте код стороннего менеджера тегов.
  Убедитесь, что вы добавили на страницу код Google Аналитики.
• На вашем сайте неправильно размещен код отслеживания Google Аналитики.
  Фрагмент кода необходимо добавить в раздел <head> главной страницы. Чтобы проверить это, откройте обработанный исходный код страницы.
• Вы ещё не создали аккаунт в Google Аналитике.
  У вас должен быть действующий аккаунт Google Аналитики, связанный с сайтом, и право на внесение изменений в этом аккаунте. При этом войти в Search Console надо с помощью аккаунта Google, который используется для доступа к этому аккаунту Google Аналитики.
• Вы ещё не создали ни одного профиля сайта в Google Аналитике.
  У вас есть ресурс Google Аналитики без представлений. Создайте представление, чтобы можно было использовать Google Аналитику для подтверждения права собственности на сайт.
• Чтобы использовать такой способ подтверждения, необходимы права на редактирование этого веб-ресурса Аналитики.
  У вас должны быть права на внесение изменений в настройки ресурса Google Аналитики, который связан с этим сайтом. Выберите для входа в Search Console аккаунт с такими правами.
• Другие распространенные проблемы с подтверждением, которые перечислены ниже.

Фрагмент-контейнер Google Менеджера тегов

Учебный курс по Google Search Console: подтверждение права собственности на сайт с помощью Google Менеджера тегов

Общие сведения

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

⚠️ Требования

• Главная страница вашего сайта должна открываться без аутентификации. Другими словами, она должна быть доступна не вошедшим в аккаунт пользователям. Кроме того, страницы, которые требуют ввести пароль, нечасто появляются в результатах поиска, поэтому данных об их поисковом трафике будет собрано немного.
• У вас должны быть права на публикацию или администрирование для контейнера Google Менеджера тегов на странице.
• И в Search Console, и в Google Менеджере тегов необходимо использовать один и тот же аккаунт Google.
• На вашу главную страницу (см. примечание) должен быть добавлен код Менеджера тегов так, чтобы его часть <noscript> находилась в самом начале раздела <body> страницы. В противном случае выполнить подтверждение не удастся. Между тегом <body> и кодом Менеджера тегов можно вставлять только комментарии HTML. Не размещайте там уровни данных или любой другой код. Чтобы убедиться в наличии кода Менеджера тегов, откройте страницу в браузере, затем перейдите к ее исходному коду и найдите нужный фрагмент.
• Используйте код только в исходном виде. Если его изменить, он не будет распознан.
• Размер страницы с добавленным тегом не должен превышать 2 МБ. При этом внешние ресурсы, например скрипты, на размер не влияют. Это ограничение коснется очень малого количества сайтов.
• Этот способ подтверждения подходит для ресурсов с префиксом в URL, но не для доменных ресурсов.

Инструкции

Чтобы подтвердить право собственности на ресурс с помощью кода Google Менеджера тегов, выполните следующие действия:

1. Откройте Search Console, используя аккаунт Google, у которого есть права на редактирование в Google Менеджере тегов.
2. Изучите требования, которые относятся к этому способу подтверждения.
3. Выберите вариант Google Менеджер тегов на странице подтверждения вашего сайта и следуйте инструкциям.
4. Если возникли проблемы, то попробуйте устранить их, пользуясь инструкциями из раздела Возможные ошибки ниже.

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

При подтверждении права собственности с помощью Google Менеджера тегов могут произойти следующие ошибки:

• Не удалось обнаружить идентификатор контейнера Google Менеджера тегов на главной странице вашего сайта.
  Search Console не удалось найти код Google Менеджера тегов на главной странице вашего сайта.
  • Проверьте, размещен ли фрагмент кода в нужном разделе главной страницы. Есть ли ваш код на главной странице? (Она должна быть доступна без пароля.)
  • Откройте исходный код главной страницы и поищите слова «Google Tag Manager» или код Google Менеджера тегов. Если код отсутствует, то на вашем сайте не используется (или неверно настроен) Google Менеджер тегов.
• Чтобы использовать такой способ подтверждения, необходимы права администратора или права на публикацию этого контейнера Менеджера тегов.
  
  Этот способ подтверждения доступен только пользователям с правами администратора или правами на публикацию контейнера Менеджера тегов.
• Идентификатор контейнера, используемый на вашем сайте, не связан с вашим аккаунтом Менеджера тегов.
  На главной странице обнаружен код Менеджера тегов, но вы не вошли в аккаунт Search Console, у которого есть необходимые разрешения для нужного контейнера. Убедитесь, что в Search Console используется аккаунт Google, у которого есть все необходимые разрешения для работы с контейнером Менеджера тегов.
• Вы ещё не создали ни одного контейнера в Google Менеджере тегов.
  Вы не создали ни одного контейнера в том аккаунте, который сейчас используете. Убедитесь, что вы создали контейнер Менеджера тегов и вошли в Search Console с аккаунтом Google, у которого есть все необходимые разрешения для работы с этим контейнером.
• Не удалось обнаружить идентификатор контейнера Google Менеджера тегов на главной странице вашего сайта.
  Тег отсутствует на главной странице или находится в неправильном месте. Он должен располагаться в разделе <head>. Убедитесь, что вы разместили тег на нужной странице и в нужном разделе, как описано в документации Менеджера тегов.
• Другие распространенные проблемы с подтверждением, которые перечислены ниже.

Google Domains

Ресурсы, зарегистрированные в Google Domains, подтверждаются автоматически, как только вы добавляете их в Search Console (если в этих сервисах вы используете один и тот же аккаунт Google).

Где должен быть размещен тег отслеживания?

Если для подтверждения права собственности используется тег (Google Аналитики, Менеджера тегов или HTML-тег <meta>), то Search Console будет искать его на странице, на которую перенаправляются пользователи, не выполнившие вход, после ввода URL вашего ресурса в браузере.

Пример

URL вашего сайта – https://example.com, а любой пользователь, не выполнивший вход в аккаунт, после ввода этого URL в браузере попадает на страницу https://example.com/home. Это означает, что Search Console будет искать тег по адресу https://example.com/home.

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

Типичные ошибки при подтверждении

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

• Неверный тег, фрагмент кода или файл.
  Используйте в точности тот тег, фрагмент кода или файл, который вы получили в начале процедуры подтверждения.
• Истекло время ожидания подключения к серверу.
  Не удалось проверить ваш файл, так как время ожидания сервера истекло. Это может быть вызвано тем, что сервер отключен, занят или реагирует с задержкой. Проверьте, корректно ли он работает, и повторите попытку.
• При поиске доменного имени вашего сайта произошла ошибка.
  Мы попытались прочитать ваш файл подтверждения, но не смогли получить доступ к вашему домену из-за ошибки DNS. Возможно, ваш сервер неработоспособен или возникли проблемы с DNS-переадресацией. Убедитесь, что имя вашего домена правильно преобразуется в IP-адрес, и повторите попытку.
• Переадресация запроса на скачивание выполнена слишком много раз.
  Проверьте URL на наличие бесконечного цикла или аналогичных проблем.
• Сервер вернул недопустимый ответ.
  Это происходит, если на сайте используется аутентификация с помощью пароля или сайт недоступен по другим причинам.
• Нам не удалось связаться с вашим сервером.
  Убедитесь, что сервер работает, а имя вашего домена обрабатывается правильно. Повторите попытку подключения.
• Произошла внутренняя ошибка.
  Если это происходит систематически, посетите Справочный форум для веб-мастеров, чтобы узнать последние новости и найти возможные решения.
• Время ожидания истекло.
  Либо ваш сайт, либо DNS-сервер перестал отвечать на наши запросы (конкретные обстоятельства зависят от выбранного способа подтверждения). Убедитесь, что сайт доступен, и повторите попытку.
• Не удалось найти ваш домен.
  Мы пытались найти домен, соответствующий предоставленному вами URL сайта, но в системе поставщика услуг DNS он отсутствует. Проверьте, не ошиблись ли вы при вводе URL.

Эта информация оказалась полезной?

Как можно улучшить эту статью?

Категория ~
Что делать (ошибки и проблемы)

– Автор:

Игорь (Администратор)

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

Что такое ошибка ERR_TOO_MANY_REDIRECTS?

Если говорить техническим языком, то ошибка ERR_TOO_MANY_REDIRECTS возникает из-за непрекращающихся редиректов (что это и подробности?) от одной страницы к другой. Чаще всего, это циклическая переадресация, например, как в случае переадресации с WWW в домен без WWW и обратно, или же с http в https и обратно. В стиле «www,site > site > www,site > site > …».

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

1. Браузер пытается открыть страницу page1.

2. Сайт в ответ присылает браузеру, что нужно открыть страницу page2 (перенесли, или структура сайта поменялась, или как ранее упоминал переадресация с http в https).

3. Браузер пытается открыть страницу page2.

4. Сайт в ответ пишет браузеру, что ему нужно открыть страницу page3 или, как в случае с циклической переадресацией, опять же страницу page1.

5. Браузер пытается открыть страницу page3 или page1 (и во втором случае повторяется аналогичная ситуация, как в шаге 2).

….

N. Браузер достиг некоторого максимального счетчика переадресации (или же обнаружил цикл) и отобразил ошибку ERR_TOO_MANY_REDIRECTS пользователю.

При этом чаще всего самих страниц немного, просто они заставляют браузер постоянно открывать друг друга, не предоставляя пользователю никакого контента (что это?). Утрируя, это как в ситуации «Вася сказал идти к Коле, Коля сказал идти к Пете, Петя сказал идти к Васе, а Вася снова сказал идти к Коле и так до бесконечности».

Как исправить ошибку пользователю?

Стоит понимать, что не обязательно ошибка ERR_TOO_MANY_REDIRECTS возникает только из-за сайта (или пользователь никак не может на нее повлиять). Поэтому стоит попробовать следующее:

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

Примечание: Кстати, так же советую ознакомиться с обзором зачем пользователю несколько браузеров.

2. Почистите cookies браузера. У браузеров предусмотрен специальный механизм под названием cookies (что это и особенности?), позволяющий сайтам хранить частички информации. Обычно, в них хранятся какие-то небольшие персонализированные настройки или же маркеры безопасности (чтобы пользователю не приходилось каждый раз вводить пароль и логин). И иногда из-за некорректно сохраненных данных (или по иным причинам, связанным с информацией в куки) может возникать ошибка «Сайт выполнил переадресацию слишком много раз». Поэтому стоит их почистить для конкретного сайта.

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

4. Различные расширения браузера. Если у вас в браузере установлены расширения, то стоит проверить, что они никак не влияют (отключить и посмотреть, откроется ли сайт). Например, расширения для социальных сетей.

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

Как исправить ошибку автору сайта?

Если же вы автор сайта и хотите узнать как вы можете исправить ошибку ERR_TOO_MANY_REDIRECTS, то вам стоит обратить внимание на следующие места:

1. Файл htaccess. Одни из частых ситуаций: правила редиректов противоречат друг другу, некорректно составленные условия, большое количество перенаправлений и тому подобное.

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

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

4. Существующие сервисы для проверки цепочки редиректов. Например, Redirect Checker. Конкретный список не указываю, так как их легко найти в интернете (и могут меняться время от времени). Сервисы обычно предоставляют цепочку редиректов, из которой можно понять в каком месте возникла проблема.

Примечание: Хотя вы самостоятельно можете отследить проблему с редиректами. Для этого достаточно в браузере для страницы открыть вкладку с сетевыми запросами и указать галочку «Preserve log».

5. Если вы использует CDN сервисы, то в них так же стоит почистить кэш. CDN сервисы, такие как Cloudflare, снимают часть нагрузки с реального сайта, однако это так же означает дополнительную прослойку, в которой могут быть ошибки (например, в сохраненном кэше). Кстати, кроме очистки кэша, так же советую внимательно изучить настройки (бывает полезным).

Понравилась заметка? Тогда время подписываться в социальных сетях и делать репосты!

Три способа решения ошибки «Сайт выполнил переадресацию слишком много раз»

12.12.2022

Не можете зайти на сайт, потому что браузер выдает сообщение «Страница недоступна. Сайт выполнил переадресацию слишком много раз. Удалите файлы Cookie. ERR_TOO_MANY_REDIRECTS»? Как поступать в такой ситуации и всё-таки открыть нужный сайт?

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

Решение 1. Чистим куки

Для начала воспользуемся подсказкой самого браузера и удалим файлы cookie. Но почистим куки не для всех сайтов одним махом, потому что это всё равно что из пушки палить по воробьям, а прицельно только для проблемного сайта. Покажу на примере Google Chrome.

Открываем Настройки браузера -> Конфиденциальность и безопасность -> Файлы cookie и другие данные сайтов.

На открывшейся страничке выбираем  пункт «Посмотреть все разрешения и данные сайтов».

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

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

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

Решение 2. Используем другой браузер

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

Откройте сайт в любом другом установленном у вас браузере. В 90% случаев он откроется нормально – проверено лично!

Иногда ошибка «Сайт выполнил переадресацию слишком много раз» возникает из-за того, что администратор сайта, на который вы пытаетесь попасть, внес какие-то изменения в конфигурацию сервера (неверное настроил редиректы, криво установил SSL-сертификат и пр.), что обычно приводит к циклическим переадресациям в браузере при попытке попасть на страницу и её недоступности как следствие этого.

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

Если Решение №2 не помогло, и сайт по-прежнему не открывается ни в одном из браузеров, то проблема не на вашей стороне и решить самостоятельно её не получится. В этом случае выходом из ситуации будет сообщить админу или техподдержке сайта о том, что их ресурс недоступен. Также не забудьте сообщить им характер ошибки: ERR_TOO_MANY_REDIRECTS. Администрация внесет нужные правки в конфигурацию сервера, и сайт снова станет доступен.

Расшифровку других ошибок, которые часто выдают сайты при попытке попасть на них через браузер, вы найдете тут: https://webtous.ru/poleznye-sovety/rasprostranennye-oshibki-sajtov-i-ix-znachenie.html

Похожие публикации:

• Почему не работает Java и как его включить в браузере?
• Как быстро найти любой файл на компьютере, съемном диске, флешке
• Как поменять раскладку клавиатуры нажатием всего одной клавиши
• Как найти похожую картинку, фотографию, изображение в интернет
• Remix OS — андроид система для ПК. Где скачать и как установить

Понравилось? Поделитесь с друзьями!

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