Как сделать региональные страницы для сайта доставки?

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

Сначала разделите филиал, зону доставки и SEO-ключ

У этих сущностей разная логика. Филиал — реальная точка бизнеса с адресом, режимом работы, персоналом или собственной операционной функцией. Зона доставки — территория, куда компания привозит заказ. А запрос с городом — всего лишь формулировка пользовательского спроса. Наличие запроса «доставка напитков + город» само по себе ещё не означает, что этому городу нужен отдельный URL.

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

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

Что выбрать: подпапки или поддомены

Для описанного сайта базовый вариант — подпапки:

site.ru/kazan/ site.ru/perm/ site.ru/ufa/

Если внутри города есть отдельные коммерческие интенты, структуру можно развивать дальше:

site.ru/kazan/dostavka-edy/ site.ru/kazan/napitki/ site.ru/kazan/pizza/

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

Подпапки проще поддерживать как один сайт: общая навигация, аналитика, шаблоны, каталог, корзина и техническая инфраструктура остаются едиными. Google в документации по мультирегиональным сайтам рассматривает и поддомены, и подпапки как допустимые варианты URL-структуры; подпапки характеризуются как более простые в настройке и менее требовательные к сопровождению. Эта документация относится прежде всего к странам и языковым регионам, поэтому превращать её в доказательство SEO-преимущества подпапок именно для городов нельзя. Здесь это архитектурная рекомендация, а не «фактор ранжирования».

Поддомены вида kazan.site.ru разумны, когда Казань фактически является самостоятельным представительством. Для Яндекса поддомен рассматривается как отдельный сайт: его можно отдельно добавить в Вебмастер и задать ему регион. При этом Яндекс требует региональный контент, местные контакты, полезную информацию для конкретного региона и связь с основным сайтом через навигацию. Если поддомены полностью или почти полностью дублируют основной сайт, Яндекс предупреждает, что один адрес может быть признан неглавным и перестать самостоятельно участвовать в поиске.

То есть поддомен не стоит заводить ради красивого вхождения города в hostname. Он нужен, когда бизнес действительно разнесён по регионам и отдельное управление региональностью в Яндексе имеет практический смысл.

Что делать с ключами, в которых есть города

Не складывать их в один SEO-абзац и тем более не делать блок вроде «доставка еды Москва, доставка еды Казань, доставка еды Пермь…». Google прямо приводит блоки текста с перечислением городов и регионов, под которые страница пытается ранжироваться, как пример keyword stuffing.

Городские запросы нужно кластеризовать по интенту и будущей посадочной:

• «доставка еды Казань», «заказать еду Казань» → /kazan/ или /kazan/dostavka-edy/;
• «доставка пиццы Казань» → /kazan/pizza/, если пицца является самостоятельной категорией и страница реально нужна пользователю;
• «доставка напитков Казань» → /kazan/napitki/, если есть отдельный ассортимент или самостоятельный интент;
• запросы по небольшим населённым пунктам, куда доставка идёт на тех же условиях и о которых нечего сообщить отдельно → общая страница зоны доставки с перечислением обслуживаемых территорий.

Название города нормально использовать в H1, Title, хлебных крошках, условиях доставки и ссылках навигации. Но целевая страница должна быть коммерческой посадочной, а не «статьёй про доставку в Казани», если пользователь хочет сделать заказ.

Когда город заслуживает отдельной страницы

У страницы должен быть ответ на простой вопрос: что пользователь из этого города узнает здесь такого, чего он не получит на общей странице?

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

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

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

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

Как не собрать дорвейную сетку

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

Проблемная схема:

/kazan/dostavka-edy/ /perm/dostavka-edy/ /ufa/dostavka-edy/

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

Такая сетка слабая не потому, что «любые дубли запрещены». Проблема в другом: отдельные URL не выполняют самостоятельной пользовательской функции. Google отдельно указывает на существенно похожие страницы, созданные ближе к выдаче, чем к понятной структуре сайта, как на один из вариантов doorway abuse.

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

Какая структура подойдёт для доставки

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

/delivery/ — общая география доставки и выбор города.

/kazan/ — городская страница: условия, зоны, доступные категории, контакты и локальные особенности.

/kazan/pizza/ — только если это самостоятельная коммерческая категория для Казани.

/perm/ — аналогичная страница другого реально обслуживаемого рынка.

Главная и /delivery/ должны содержать обычные HTML-ссылки на региональные страницы. Не стоит прятать региональные версии только за определением IP или переключателем, после которого URL не меняется. Яндекс отдельно предупреждает: если пользователю показывается разный контент только в зависимости от IP, его робот может увидеть лишь одну региональную версию, из-за чего часть содержимого останется вне индекса.

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

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

Для Google hreflang также не является инструментом назначения отдельных русскоязычных страниц Казани, Перми или Уфе: поддерживаемый дополнительный региональный код соответствует ISO 3166-1 Alpha-2, то есть стране, а не российскому городу.

Для реальных ресторанов, магазинов или филиалов можно использовать LocalBusiness и его конкретные подтипы, например Restaurant, с фактическим адресом и данными точки. Google позволяет описывать таким образом местоположение компании или каждого филиала. Для города, где физической точки нет и существует только доставка, не следует придумывать адрес или размечать фиктивный филиал.

Как внедрять без массовой генерации мусора

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

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

Если страница не имеет собственного интента, локальных данных и пользовательской функции, не надо спасать её генерацией «уникального SEO-текста». Спрос лучше объединить с более широкой страницей города или общей страницей зоны доставки.

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