Сделайте рабочий (production) сайт доступным для извлечения
Перечислите страницы, которые вы хотите, чтобы находили: обычно это главная страница, основные страницы продуктов или услуг, ключевые категории, страницы поддержки и оригинальные статьи. Зафиксируйте каждый окончательный HTTPS-URL и укажите, предназначен ли он для поиска. Тестируйте публичный рабочий адрес в браузере без входа в систему; окружения стейджинга, превью и представления для залогиненных пользователей могут вести себя иначе.
Проверьте наличие парольных заграждений, глобальных директив noindex, правил robots, ошибок, цепочек перенаправлений и отсутствующих рендер-критичных ресурсов. robots.txt управляет доступом краулеров; Google подчёркивает, что это не способ скрыть страницу из поиска. Используйте контроль доступа для приватного контента и noindex для публичных страниц, которые вы сознательно исключаете из поиска.
Разделите индексируемые публичные страницы, намеренные исключения и приватные области перед тестированием.
Загрузите предпочтительный URL и соответствующие варианты по HTTP, хосту, слешу и legacy-варианты.
Выберите один предпочтительный URL для каждого элемента контента
Канонический URL — это представительский адрес для дублированного или очень похожего контента. Решите, какой хост использовать, каким будет соглашение по слешам и как обрабатывать параметры, печатные страницы и устаревшие пути. Навигация, XML-карта сайта, rel=canonical и перенаправления должны указывать на один и тот же адрес.
При удалении или объединении дубликата используйте постоянное серверное перенаправление. На индексируемых HTML-страницах используйте абсолютную ссылку rel=canonical в head страницы, включая самоссылку на предпочтительной странице. Google описывает перенаправления и канонические аннотации как сильные сигналы, включение в карту сайта как более слабый сигнал и всё равно может сделать собственный выбор канонического URL.
Для каждого значимого варианта зафиксируйте его источник, назначение, канонический URL и причину.
Не указывайте один URL в карте сайта, объявляя или ссылаясь на другой как на канонический.
Перенаправляйте HTTP-варианты на рабочий предпочтительный HTTPS-адрес.
Сделайте приоритетные страницы понятными и полезными
Напишите уникальный, краткий заголовок страницы, который точно определяет предложение или ответ. Добавьте короткое, специфичное для страницы meta description как кандидат на резюме, а не как обещание того, что Google покажет. Google может сгенерировать заголовок из нескольких сигналов, а сниппет — из содержимого страницы или иногда из описания. Разместите основное объяснение и следующий шаг в видимом тексте.
Используйте описательные заголовки и естественный язык, который отвечает задаче посетителя. Избегайте копированного текста и близко-похожих страниц с минимальной уникальной ценностью. Предоставляйте описательный alt-текст для значимых изображений. Не тратьте усилия при запуске на meta keywords: web.dev сообщает, что поисковые системы больше не считают его полезным.
Читатель должен иметь возможность отличить страницы по их заголовкам без повторяющихся терминов.
Страница отвечает на свой центральный вопрос прежде, чем просить о покупке или регистрации.
Свяжите сайт полезными внутренними ссылками
Внутренние ссылки — это ссылки между страницами одного и того же сайта. Они помогают посетителям ориентироваться и помогают Google находить контент. Ссылайтесь с главной страницы и релевантных хабов на приоритетные страницы, используя анкерный текст, который идентифицирует назначение. Добавляйте контекстные ссылки, когда они отвечают на следующий вопрос посетителя; длинный список в футере не заменит понятную структуру.
Используйте канонические URL в навигации, хлебных крошках, модулях «связанный контент» и призывах к действию. На небольшом сайте кликните по каждому основному маршруту. На большем сайте используйте проверенный командой инструмент краулинга для поиска осиротевших приоритетных страниц, битых ссылок и неожиданных кодов ответа.
Каждая приоритетная страница должна иметь полезный путь из меню, хаба или связанной страницы.
Проверьте мобильные меню, формы, аккордеоны и оверлеи согласия так же, как и desktop-ссылки.
Опубликуйте чистую XML-карту сайта
XML-карта сайта сообщает поисковым системам, какие страницы и файлы вы считаете важными. Она может поддержать обнаружение для нового сайта, но не гарантирует сканирование или индексацию. Если CMS генерирует карту, проверьте её. Включайте предпочтительные публичные URL, предназначенные для поиска; исключайте перенаправления, ошибки, тестовые страницы и URL, заблокированные от индексации.
Держите карту сайта в стабильном месте и при необходимости отправьте её в Search Console. Она дополняет, а не заменяет внутренние ссылки, качество контента и доступ для краулинга. Используйте специализированные расширения карт сайта только если они соответствуют живой реализации.
Сопоставьте URL из карты сайта с инвентарём страниц и картой каноников.
Убедитесь, что новые предпочитаемые страницы появились, а устаревшие URL удалены.
Измеряйте обнаружение и диагностируйте целевые URL
Подтвердите право собственности на рабочее свойство в Google Search Console. Отправьте карту сайта, если используете её. Просмотрите представительную выборку: главную страницу, каждое важное шаблонное представление, недавно изменённую страницу и URL высокого значения из миграции. URL Inspection (Проверка URL) предоставляет актуальную информацию об индексации и может протестировать живой URL; используйте её для исследования симптома, а не для привычного запроса каждого URL.
Зафиксируйте дату запуска, соглашения по URL, адрес карты сайта, приоритетные страницы и исключения. Просмотрите отчёт Search Performance по показам, кликам, запросам, страницам и странам. Search Console специфичен для Google, и данные могут появляться с задержкой, поэтому это доказательство диагностики, а не мгновенное подтверждение того, что все поисковые системы обработали запуск.
Сохраняйте тестированные URL, наблюдаемый результат, дату и ответственного для последующего сравнения.
Проверяйте исключения индексации, проблемы безопасности и Core Web Vitals вместе с тестами на уровне страниц.
Сделайте SEO частью релиза и процесса исправления
Включите инвентарь страниц, перенаправления, rel=canonical, карту сайта и представительные проверки живых URL в запись о запуске. Status Is UP рассматривает это как проактивную оптимизацию доступности и устранение дефектов: выявляйте проблемы доставки или конфигурации до релиза и выполняйте контролируемое исправление, когда что-то введено. Доступность не является гарантом ранжирования.
Назначьте человека, который может одобрить целенаправленную откатку, если релиз нарушит публичный маршрут, head страницы, навигацию или генерацию карты сайта. Повторно протестируйте затронутые предпочтительные URL после исправления. Предпусковая проверка публичных маршрутов снижает число избегаемых сбоев доставки, но не может предсказать сканирование, индексацию или ранжирование поисковой системой.
Тестируйте представительные публичные маршруты и ресурсы после деплоя, а не только на стейджинге.
Документируйте, кто может отменить вредоносное изменение маршрутизации, шаблона, robots или карты сайта.