Подключение Google Search Console и сохранение подтверждения

В предыдущем уроке мы разделили обнаружение адреса, обход и индексирование. Для страниц A–H известны учебные настройки сайта, но состояние в Google остаётся неизвестным. Чтобы получить сведения от поисковой системы, понадобится доступ к Google Search Console — сервису отчётов и инструментов для владельца сайта. Регистрация в нём не является обязательным условием появления сайта в Google. Назначение Search Console.

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

Границы ресурса

Search Console называет наблюдаемый сайт или его часть ресурсом. Для нашего примера существенны два типа: доменный ресурс и ресурс с префиксом в URL. Доменный вариант example.com охватывает разные протоколы и поддомены; вариант https://example.com/ ограничен этим префиксом. Подтверждение доменного ресурса выполняется через DNS, тогда как для URL-префикса доступны и другие методы. Типы ресурсов Search Console.

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

Адрес	Доменный ресурс example.com	URL-префикс https://example.com/
https://example.com/	Входит	Входит
https://example.com/my/LINQ/linq_xml/level7/7_1.php	Входит	Входит
http://example.com/	Входит	Не входит
https://www.example.com/	Входит	Не входит
https://docs.example.com/	Входит	Не входит

Предположим, владелец изучает только основную библиотеку на HTTPS без www. URL-префикс соответствует этой задаче. Если нужно следить ещё и за прежними вариантами домена и протокола, удобнее общий доменный ресурс. Это выбор области отчёта, а не настройка редиректов: добавление ресурса не меняет ответы сервера и не переносит страницы с HTTP на HTTPS.

Можно сузить префикс до https://example.com/my/, однако тогда новая статья C и каталог D окажутся вне него. Для первых уроков выберем префикс корня сайта, чтобы одна область охватывала все A–H. Сохраним выбранное значение в seo-audit/access-notes.md: это обычная рабочая заметка, которую вы создаёте рядом с реестром адресов.

## Google Search Console

- Ресурс: https://example.com/
- Тип: URL-префикс
- Цель: общая диагностика страниц A–H
- Способ подтверждения: пока не выбран
- Статус доступа: пока не подтверждён

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

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

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

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

Выбирать стоит по доступу и устройству проекта. Если у вас есть исходники и публикация статических файлов, HTML-файл не требует менять общий шаблон. Если выпуск сайта умеет сохранять параметры head, метатег можно включить в этот процесс. Если вы управляете DNS и хотите доменный ресурс, используйте инструкции сервиса для соответствующей записи. Не переносите значение Google в механизм Яндекса: это самостоятельные подтверждения.

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

Подтверждение как часть исходного проекта

Пусть сервис выдал файл google1234567890abcdef.html. Это условное имя для объяснения; ваш файл имеет собственное имя и содержимое. Сохраните полученный файл в папку статических ресурсов. В учебном проекте такую папку назовём public, а результат сборки — dist:

site-project/
├── content/
│   └── статьи и оглавления
├── templates/
│   └── общие шаблоны
├── public/
│   └── google1234567890abcdef.html
└── dist/
    └── google1234567890abcdef.html

Здесь показано правило организации, а не требование переименовать папки вашего действующего сайта. В ProfessorWeb мы уже отделили содержимое от оформления; такой же принцип применим к файлам подтверждения. Найдите в своём проекте место, содержимое которого копируется в корень готового сайта без обработки, и используйте его.

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

После сборки ожидаем увидеть файл в корне результата. После размещения — открыть на собственном домене именно адрес, указанный Search Console. Имена, регистр букв и содержимое должны соответствовать выданному файлу. Страница с дизайном сайта и текстом «файл не найден» не является корректным результатом, даже если открывается без видимой ошибки браузера.

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

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

- Способ подтверждения: HTML-файл
- Источник: public/google1234567890abcdef.html
- Адрес результата: https://example.com/google1234567890abcdef.html
- Правило выпуска: копировать без изменения в корень сайта
- Статус доступа: заполнить после подтверждения в сервисе

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

Метатег и DNS как альтернативы

Для варианта с метатегом используйте точную строку из Search Console. Учебная схема выглядит так; YOUR_GOOGLE_TOKEN заменяется выданным значением:

<head>
  <meta charset="utf-8">
  <meta name="google-site-verification" content="YOUR_GOOGLE_TOKEN">
  <title>Учебная библиотека</title>
</head>

В исходном проекте этот фрагмент должен находиться в шаблоне, формирующем head главной страницы, либо в параметре, который этот шаблон использует. Изменение готового dist/index.html вручную пропадёт при пересборке. Фрагмент в тексте Markdown тоже не решает задачу: тело статьи обычно вставляется внутрь body, тогда как в примере требуется head.

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

По варианту DNS сохраняйте в рабочей заметке тип записи, имя узла и место управления зоной. Эти значения берите из инструкций сервиса и интерфейса своего DNS-провайдера. Такая запись живёт вне генератора HTML: пересборка страниц обычно её не затрагивает, а смена DNS-провайдера требует учитывать её отдельно. Не заменяйте действующие записи адреса сайта или почты записью подтверждения.

Основная идея одинакова для всех вариантов: подтверждение является постоянной зависимостью доступа. Для файла зависимость проходит через копирование ресурсов, для метатега — через шаблон, для DNS — через настройки зоны. В заметке фиксируйте выбранный способ и место, ответственное за его сохранность, вместо списка всех возможных токенов без объяснения.

Первый доступ к данным

Завершите подтверждение в сервисе после того, как выбранный способ доступен на вашем опубликованном сайте. Ожидаемый результат — возможность открыть нужный ресурс и его отчёты. В заметке запишите фактический статус, дату и аккаунт, которому принадлежат права. Если доступ ещё не подтверждён, так и укажите; это отдельная задача от индексирования страницы C.

Теперь вернёмся к реестру A–H. В строке проверки URL можно передать полный адрес B со своего домена. Полученные сведения об индексировании и отдельная проверка опубликованного URL имеют разное назначение: первую используем как данные Google об обработанной версии, вторую — для исследования текущей доступности. Подробный разбор результата будет в следующей части диагностики. Проверка URL в Search Console.

Пока не подставляйте в observations.csv ожидаемые ответы. Если ресурс подтверждён, но отчёт по B не открыт, index_state остаётся unknown. Если отчёт сообщает о конкретном состоянии, добавьте наблюдение с engine=google, check_type=indexed_report, своей датой чтения и точной формулировкой в evidence. Отсутствующие сведения тоже не нужно угадывать по HTTP-ответу из нашего сценария.

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