Как перелинковать сайт с несколькими адресами: чеклист из 10 шагов и 5 типичных ошибок

Коротко: для сайта с несколькими филиалами нужна модель перелинковки hub-and-spoke: одна хаб-страница со всеми точками, уникальные страницы локаций и горизонтальные ссылки только между ближайшими 2–3 точками. Анкоры ссылок должны содержать «услуга + локация», а не «подробнее». Каждая точка — отдельный блок Schema.org LocalBusiness с уникальным контентом.

У бизнеса три точки в Москве, пять в Подмосковье и планы на Санкт-Петербург. На сайте — страница для каждой локации, страницы услуг, общая «О компании» и блог. Вопрос: как связать всё это ссылками так, чтобы Яндекс понимал, какая страница отвечает за какой район, а не считал их дублями друг друга? В этой статье — структура внутренней перелинковки для мультилокационных сайтов, которую мы в Pulse Digital выстраиваем на проектах с несколькими адресами.

Типичная ошибка: «все точки ссылаются на все»

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

Что происходит при таком подходе:

• Каждая страница сайта передаёт ссылочный вес равномерно на все локации. Если на сайте 100 страниц и 8 локаций в футере — каждая локация получает одинаковый вес со всех 100 страниц. Яндекс не понимает, какая локация приоритетна для какого запроса.
• Анкоры ссылок одинаковые: «ул. Ленина, 15», «ул. Мира, 42» — они не содержат семантики услуги и региона, по которой страница должна ранжироваться.
• Контент на страницах локаций часто идентичен, а ссылочная структура это усугубляет: для Яндекса они выглядят как дубли с разными адресами. О том, как Яндекс обрабатывает дубли и что делать с canonical, мы разбирали в отдельной статье про дубли, GET-параметры и canonical.

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

Главное: модель «все ссылаются на все» размывает ссылочный вес и мешает Яндексу определить приоритет каждой локации.

Правильная структура: hub-and-spoke

Вместо модели «все ссылаются на все» нужна модель hub-and-spoke (хаб и спицы). Яндекс рекомендует выстраивать чёткую иерархию разделов для лучшего понимания структуры сайта. Вот как это выглядит:

                    Главная
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
      /uslugi/    /lokacii/    /blog/
          │           │
    ┌─────┼─────┐     │
    ▼     ▼     ▼     │
 /uslugi/ /uslugi/ /uslugi/    │
 remont   montazh  obsluzhivanie │
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
     /lokacii/   /lokacii/   /lokacii/
     metro-      taganka/    maryino/
     sokol/
          │
          ▼
     Уникальный контент:
     адрес, часы, карта,
     отзывы, услуги этой точки

Принципы структуры

• Хаб локаций (/lokacii/ или /contacts/) — агрегирующая страница, на которой перечислены все точки с краткой информацией. Она ссылается «вниз» на каждую отдельную локацию.
• Страница локации (/lokacii/metro-sokol/) — ссылается «вверх» на хаб и «горизонтально» только на ближайшие 2–3 точки (не на все).
• Страницы услуг (/uslugi/remont/) — ссылаются на хаб локаций и, при наличии, на региональные версии услуги (/msk/seo-prodvizhenie — пример такой региональной страницы).
• Блог и информационные страницы — ссылаются на хаб локаций или на конкретную локацию, если статья привязана к конкретному событию или объекту.

Ключевое правило: горизонтальные ссылки между локациями — только для географически близких точек, а не для всех. Это говорит поисковику: «Эти точки связаны географически», а не «это одно и то же».

Главное: модель hub-and-spoke создаёт чёткую иерархию (хаб → локации) и ограничивает горизонтальные ссылки 2–3 ближайшими точками.

Правила анкоров: что писать в ссылках

Анкор (текст ссылки) — один из сильнейших сигналов для Яндекса о содержании целевой страницы. Для мультилокационных сайтов анкоры требуют особого внимания.

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

Неправильно:

• «Наш адрес»
• «ул. Ленина, 15»
• «Подробнее»
• «Точка на карте»

Правильно:

• «Ремонт техники у метро Сокол»
• «Пункт приёма на Таганке»
• «Наш филиал в Марьино — часы работы и адрес»

Анкор должен содержать услугу + локацию. Это помогает Яндексу связать страницу с геозависимым запросом. Сравните: пользователь ищет «ремонт техники Сокол» — и поисковик видит, что на целевую страницу ведут ссылки с анкорами, содержащими именно эти слова.

Анкоры для ссылок на страницы услуг

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

• «Наши услуги по ремонту в этом филиале» → ведёт на /uslugi/remont/
• «SEO-продвижение для бизнеса в вашем районе» → ведёт на /services/seo-prodvizhenie

Анкоры для ссылок на контактную информацию

• «Как добраться до нашей точки у метро Сокол» → ведёт на страницу локации
• «Все наши точки на карте Москвы» → ведёт на хаб /lokacii/

Главное: в анкорах ссылок всегда указывайте связку «услуга + локация» — это ключевой сигнал релевантности для геозависимых запросов.

Блоки «Ближайшие точки»: как реализовать без размытия

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

Правила реализации

1. Не более 2–3 ближайших точек. Показывайте только те, которые географически близки. Если у вас точки в разных концах Москвы — они не «ближайшие» друг к другу.

2. Не дублируйте полный блок контактов. Ссылка с кратким описанием: «Также рядом: наш филиал у метро Кантемировская — 15 минут на автобусе». Полные адреса, телефоны и карта — только на целевой странице.

3. Используйте геоданные для автоматического подбора. Если точек больше 5–7, ручная привязка «ближайших» станет неподъёмной при добавлении новых локаций. Рассчитывайте расстояние по координатам и показывайте ближайшие автоматически.

4. Различайте контент блока на каждой странице. Страница точки на Соколе показывает «рядом: Аэропорт и Динамо». Страница точки на Таганке — «рядом: Марксистская и Павелецкая». Это не должен быть одинаковый блок на всех страницах.

5. Уникальный текст-связка. Вместо просто списка адресов добавьте фразу с локальной привязкой: «Если вам удобнее район Аэропорт — у нас есть филиал в 10 минутах от метро».

Главное: блок «Ближайшие точки» показывает не более 2–3 географически близких филиалов с уникальным текстом, а не одинаковый список всех адресов.

Schema.org LocalBusiness для каждой локации

Микроразметка Schema.org — обязательный элемент для мультилокационных сайтов. Без неё Яндекс и Google вынуждены «угадывать» связь между адресами и бизнесом. С ней — получают структурированные данные. Яндекс описывает поддерживаемые типы разметки в документации по Schema.org.

Структура разметки

Для каждой страницы локации добавьте отдельный блок LocalBusiness (или более специфичный тип — Store, AutoRepair, Restaurant и т.д.):

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Компания — филиал Сокол",
  "image": "https://site.ru/images/sokol-photo.jpg",
  "@id": "https://site.ru/lokacii/metro-sokol/",
  "url": "https://site.ru/lokacii/metro-sokol/",
  "telephone": "+7-495-XXX-XX-XX",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ул. Часовая, 8",
    "addressLocality": "Москва",
    "addressRegion": "Москва",
    "postalCode": "125315",
    "addressCountry": "RU"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 55.7975,
    "longitude": 37.5145
  },
  "openingHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "09:00",
    "closes": "20:00"
  },
  "parentOrganization": {
    "@type": "Organization",
    "name": "Компания",
    "@id": "https://site.ru/"
  }
}

Ключевые моменты

• Каждая точка — отдельный блок с уникальным @id, name, address, telephone.
• Указывайте parentOrganization для связи филиалов с головной организацией.
• name должен содержать географический идентификатор: «Компания — Таганка», а не просто «Компания».
• Не дублируйте один блок LocalBusiness на всех страницах локаций — это типичная ошибка, при которой Яндекс видит одну и ту же организацию по одному адресу.

Главное: каждая локация получает отдельный блок Schema.org LocalBusiness с уникальным @id, адресом и привязкой к parentOrganization.

NAP-консистентность: единообразие данных

NAP — Name, Address, Phone. Это базовый набор данных, который должен быть идентичным везде, где упоминается конкретная точка: на странице локации, в футере (если он показывает ближайшую точку), в Schema.org, в Яндекс.Справочнике, в 2ГИС, на картах.

Что проверять

• Название организации пишется одинаково: если в Справочнике «ООО Ремтех», на сайте не должно быть «РемТех» или «Ремонтные Технологии».
• Адрес указан в одном формате. «ул. Ленина, д. 15, стр. 2» и «Ленина 15с2» — для поисковика это могут быть разные адреса.
• Телефон с кодом города или в формате +7. Не смешивайте 8-XXX и +7-XXX на разных страницах для одной точки.

NAP на страницах сайта

На странице каждой локации NAP должен присутствовать в виде текста (не только в виде картинки или скрипта карты). Поисковые роботы извлекают текстовые данные и сопоставляют их с информацией из внешних источников — Яндекс.Справочник, 2ГИС, Google Business Profile. Совпадение повышает доверие к локальной релевантности. Если ваш бизнес работает в одном городе и важно показывать цены на сайте — добавьте прайс-лист на каждую страницу локации с актуальными ценами для этой точки.

Типичные ошибки, которые мы находим на аудитах

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

1. Идентичный контент на всех страницах локаций

Самая частая проблема. Страницы /lokacii/sokol/, /lokacii/taganka/, /lokacii/maryino/ отличаются только адресом и картой. Весь остальной текст — копипаст. Яндекс склеивает такие страницы как дубли, оставляя в индексе одну.

Решение: каждая страница локации должна содержать уникальный контент:

• Описание района и ориентиров («Наш пункт находится в 5 минутах пешком от метро Сокол, рядом с ТЦ Метрополис»)
• Фотографии конкретной точки (фасад, интерьер, вывеска)
• Отзывы клиентов этой точки
• Информация о парковке, подъездных путях
• Специфика точки (если есть: «В этом филиале доступна услуга срочного ремонта»)

2. Ссылки из каждой страницы на каждую локацию

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

Решение:

• В футере — ссылка на хаб /lokacii/ с анкором «Все наши точки»
• На страницах локаций — блок «Ближайшие точки» с 2–3 ссылками
• На страницах услуг — ссылка на хаб или на наиболее релевантную локацию

3. Сломанные хлебные крошки

Хлебные крошки (breadcrumbs) — важный элемент навигации и перелинковки. На мультилокационных сайтах мы часто видим:

• Крошки на странице локации: Главная → Контакты → Сокол. Ошибка: «Контакты» — это не хаб локаций.
• Крошки отсутствуют вовсе на страницах локаций.
• Крошки не размечены Schema.org (BreadcrumbList).

Правильная цепочка: Главная → Наши точки → Филиал у метро Сокол.

Каждый элемент — кликабельная ссылка, размеченная BreadcrumbList. Это подсказывает Яндексу иерархию: головная страница → список всех точек → конкретная точка.

4. Региональные страницы услуг без привязки к локациям

Если на сайте есть страницы вроде /msk/seo-prodvizhenie — региональная версия услуги для Москвы — они должны ссылаться на точки в этом регионе. Мы нередко видим ситуацию, когда региональные страницы существуют изолированно: ни одна локация на них не ссылается, и сами они не связаны с конкретными точками.

Решение: со страницы /msk/seo-prodvizhenie поставить ссылку на хаб московских локаций или на конкретные точки в Москве. Со страниц московских локаций — обратную ссылку на региональную услугу. Это создаёт тематический кластер «услуга + город + точки».

5. Отсутствие связи блога с локациями

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

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

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

Как выстроить перелинковку с нуля: чеклист

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

1. Создайте хаб-страницу /lokacii/ с картой, списком всех точек и краткой информацией по каждой.

2. Создайте уникальную страницу для каждой локации с оригинальным контентом, фотографиями, отзывами и NAP-данными.

3. Настройте хлебные крошки: Главная → Наши точки → [Название точки]. Разметьте BreadcrumbList.

4. Добавьте Schema.org LocalBusiness на каждую страницу локации. Проверьте через валидатор.

5. Настройте блок «Ближайшие точки» с 2–3 ссылками, подобранными по географической близости.

6. Пропишите анкоры со связкой «услуга + локация» для всех ссылок на страницы точек.

7. Свяжите страницы услуг с хабом локаций. Если есть региональные страницы (/msk/...) — свяжите их с локациями в этом регионе.

8. Проверьте NAP-консистентность между сайтом, Яндекс.Справочником и другими площадками.

9. Удалите из футера прямые ссылки на все локации. Оставьте одну ссылку на хаб.

10. Проведите аудит через 2–4 недели: проверьте, какие страницы локаций попали в индекс, по каким запросам они ранжируются, нет ли склейки. Убедитесь, что страницы не попали в статус «Исключены роботом». Если сайт запущен недавно, используйте чеклист первых 30 дней для полной проверки.

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

Сколько страниц локаций можно создать, чтобы Яндекс не воспринял это как doorway?

Количество страниц не ограничено, если каждая из них содержит уникальный контент и привязана к реальному адресу. Проблемы начинаются, когда страницы создаются «для SEO» без реального филиала — это doorway-страницы, и Яндекс их фильтрует. Главное правило: одна реальная точка = одна страница с уникальным описанием, фотографиями и отзывами.

Нужно ли закрывать страницы локаций от индексации, если филиал временно закрыт?

Нет. Если филиал закрыт временно (ремонт, сезонность), лучше оставить страницу в индексе и добавить заметное уведомление: «Филиал временно не работает. Ближайшая точка — [ссылка]». Если филиал закрыт навсегда — настройте 301-редирект на хаб локаций или ближайшую точку, а не просто удаляйте страницу.

Как быть, если услуги в разных филиалах отличаются?

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

Влияет ли структура URL на ранжирование локальных страниц?

Прямого влияния на ранжирование формат URL не оказывает, но читаемая структура (/lokacii/metro-sokol/) помогает пользователям и упрощает аналитику. Избегайте URL с ID (/lokacii/?id=145) — они менее понятны и хуже кликаются в выдаче. Следите, чтобы URL не создавали дубли с GET-параметрами.

Что делать, если конкуренты занимают весь ТОП по геозапросам моего района?

Сначала проверьте, что техническая база в порядке: уникальный контент, Schema.org, NAP-консистентность, правильные анкоры. Затем усильте страницу локации контентом: добавьте отзывы, фотографии, описание маршрутов, привяжите статьи из блога. Убедитесь, что профиль в Яндекс.Бизнесе (Справочнике) заполнен полностью и совпадает с данными на сайте. Локальное SEO — это комплекс, где каждый элемент усиливает общий результат.

Обязательно ли использовать Schema.org LocalBusiness для каждой точки?

Строго говоря — нет, сайт будет работать и без неё. Но без разметки вы отдаёте Яндексу задачу «угадать» ваши адреса, часы работы и связь филиалов. С LocalBusiness — передаёте структурированные данные, которые повышают шансы на расширенный сниппет и корректное отображение на картах. Для мультилокационного бизнеса отсутствие разметки — упущенное конкурентное преимущество.

Резюме

Перелинковка мультилокационного сайта — это баланс между удобством для пользователя и сигналами для поисковика. Модель «все ссылаются на все» проста в реализации, но убивает локальную релевантность. Модель hub-and-spoke требует больше работы на старте, но даёт каждой точке шанс ранжироваться по своим геозапросам.

Если у вашего бизнеса несколько адресов и вы хотите, чтобы каждый филиал приводил клиентов из поиска — начните с аудита текущей структуры ссылок. В рамках SEO-продвижения мы в Pulse Digital разбираем перелинковку как часть комплексного технического аудита и выстраиваем структуру, которая работает на каждую точку.