DEV Community: Mapli

NAP-консистентность: как скриптом проверить, что адрес, телефон и часы одинаковы на сайте и в картах

Mapli — Wed, 04 Nov 2026 13:29:46 +0000

У локального бизнеса данные о точке живут минимум в четырёх местах: на сайте, в карточке на Яндекс Картах, в 2ГИС и в профиле Google. Пока точка одна и ничего не меняется, всё совпадает. Потом кофейня переезжает в соседний корпус, у салона появляется новый номер, клиника меняет часы на лето. Правку вносят в одно место, остальные три остаются со старыми данными.

В локальном SEO для этого есть термин NAP — Name, Address, Phone: название, адрес и телефон. На практике к ним всегда добавляют часы работы, потому что именно часы устаревают чаще всего. NAP-консистентность — это когда во всех источниках эти данные одинаковы.

Эта статья для разработчиков и вебмастеров, которые ведут сайты кафе, клиник, автосервисов и сетей с филиалами. Разберём:

почему расхождения NAP вредят и клиенту, и поиску;
как завести единый эталон данных точки;
как нормализовать адреса, телефоны и часы, чтобы сравнение было честным;
готовый скрипт на Python, который сверяет JSON-LD сайта с данными карточек;
праздничные и специальные часы в schema.org;
как запускать проверку по расписанию и что делать с найденными расхождениями.

Почему расхождения NAP — это проблема

Самый очевидный ущерб — человеческий. Клиент видит на сайте «до 21:00», приходит в 20:30 и упирается в закрытую дверь, потому что в карточке давно стоит «до 20:00», а на сайт правку забыли внести. Или звонит по номеру из 2ГИС, который отключили полгода назад. Такой клиент не возвращается и иногда оставляет отзыв.

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

Третий уровень — внутренний. Когда никто не знает, какой номер правильный, каждая правка превращается в расследование. Скрипт, который раз в неделю говорит «всё совпадает» или «вот три расхождения», снимает этот вопрос.

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

Шаг 1. Единый эталон данных точки

Главная идея: должен существовать один файл, где записано, как правильно. Не «как на сайте» и не «как в Яндексе», а эталон, с которым сверяется всё остальное. Сайт, карточки и печатные материалы — это копии.

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

points:
  - id: lesnaya-12
    site_url: https://example.ru/contacts/
    reference:
      name: Кофейня «Зерно»
      address: Москва, ул. Лесная, 12к2
      phone: +7 495 123-45-67
      hours: Пн-Пт 08:00-21:00; Сб 10:00-20:00
    cards:
      map_a:
        name: Кофейня «Зерно»
        address: Москва, Лесная улица, 12 к2
        phone: 8 (495) 123-45-67
        hours: Пн-Пт 08:00-21:00; Сб 10:00-20:00
      map_b:
        name: Кофейня «Зерно»
        address: Москва, ул. Лесная, д. 12, корп. 2
        phone: +7 495 123-45-76
        hours: Пн-Пт 08:00-21:00; Сб-Вс 10:00-20:00

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

Для сети с филиалами каждая точка — отдельный элемент списка points со своим id. Это же значение удобно использовать как @id в JSON-LD и как ключ в CMS.

Откуда брать данные карточек

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

Нормальные варианты такие:

Официальные API справочников. У Google есть Places API с полями адреса, телефона и часов. У 2ГИС есть API справочника, у Яндекса — API поиска по организациям. Всем нужен ключ, у каждого свои условия: что можно хранить, как долго и с какой пометкой. Прочитайте их до того, как писать код.
Выгрузки из кабинетов. Кабинеты для владельцев бизнеса у сетей часто позволяют выгрузить список точек файлом. Такой файл можно класть рядом с эталоном и разбирать тем же скриптом.
Снимок, заполненный сотрудником. Для одной-трёх точек проще всего раз в месяц скопировать данные из каждой карточки в блок cards. Скрипт всё равно сделает самое неприятное: нормализует и сравнит.

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

Шаг 2. Нормализация: сравнивать смысл, а не символы

Если сравнивать строки как есть, проверка утонет в ложных тревогах. «ул. Лесная, д. 12, корп. 2», «Лесная улица, 12 к2» и «улица Лесная, дом 12, корпус 2» — один и тот же адрес. «+7 (495) 123-45-67» и «8 495 1234567» — один и тот же номер.

Поэтому перед сравнением каждое поле приводится к канонической форме.

Телефон. Убираем всё, кроме цифр. Российские номера, начинающиеся с 8, переводим в формат с 7. Получаем E.164 вида +74951234567. Для международных сетей лучше взять библиотеку phonenumbers, она знает правила разных стран.

Адрес. Задача сложнее, и полностью её решают только геокодеры. Но для сверки своих же данных хватает простых правил:

нижний регистр и «ё» → «е»;
точки и запятые → пробелы;
полные слова → стандартные сокращения: «улица» → «ул», «корпус» → «к», «строение» → «стр»;
«12 к 2» и «12 к2» → «12к2»;
«д 12» → «12»;
сравнение без учёта порядка слов, потому что сервисы по-разному ставят тип улицы: до названия или после.

Часы. Приводим к словарю «день недели → интервал» или closed. Тогда «Пн-Пт 08:00-21:00» и пять отдельных записей openingHoursSpecification дают одинаковый результат.

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

Совет. Не пытайтесь сделать нормализацию адресов идеальной. Цель — чтобы одинаковые адреса не давали ложных тревог. Если правило ловит лишнее, добавьте его в список замен и двигайтесь дальше.

Шаг 3. Скрипт сверки на Python

Ниже полный скрипт. Он делает четыре вещи:

Читает эталон и снимки карточек из nap.yaml.
Скачивает страницу контактов сайта и достаёт из неё блок JSON-LD с организацией.
Нормализует все источники.
Печатает расхождения и завершает работу с кодом 1, если они есть. Это удобно для CI.

Зависимости: requests, beautifulsoup4, pyyaml.

import json, re, sys
import yaml                      # pip install pyyaml requests beautifulsoup4
import requests
from bs4 import BeautifulSoup

DAYS = ["Mo", "Tu", "We", "Th", "Fr", "Sa", "Su"]
RU_DAYS = {"пн": "Mo", "вт": "Tu", "ср": "We", "чт": "Th",
           "пт": "Fr", "сб": "Sa", "вс": "Su"}

def norm_phone(raw):
    digits = re.sub(r"\D", "", raw or "")
    if len(digits) == 11 and digits[0] in "78":
        digits = "7" + digits[1:]
    elif len(digits) == 10:
        digits = "7" + digits
    return "+" + digits if digits else ""

ADDR_RULES = [
    (r"\bулица\b", "ул"), (r"\bпроспект\b", "пр-т"), (r"\bпр-кт\b", "пр-т"),
    (r"\bпереулок\b", "пер"), (r"\bдом\b", "д"), (r"\bкорпус\b", "к"),
    (r"\bкорп\b", "к"), (r"\bстроение\b", "стр"), (r"\bэтаж\b", "эт"),
]

def norm_address(raw):
    s = (raw or "").lower().replace("ё", "е")
    s = re.sub(r"[.,]", " ", s)
    for pattern, repl in ADDR_RULES:
        s = re.sub(pattern, repl, s)
    s = re.sub(r"\b(\d+)\s*к\s*(\d+)", r"\1к\2", s)   # 12 к 2, 12 к2 -> 12к2
    s = re.sub(r"\bд\s+(?=\d)", "", s)               # «д 12» -> «12»
    return " ".join(s.split())

def expand_days(token):
    token = token.strip().lower()
    if "-" in token:
        a, b = [RU_DAYS.get(t.strip(), t.strip()) for t in token.split("-")]
        i, j = DAYS.index(a), DAYS.index(b)
        return DAYS[i:j + 1]
    return [RU_DAYS.get(token, token)]

def norm_hours_text(raw):
    """'Пн-Пт 09:00-20:00; Сб 10:00-18:00' -> {'Mo': '09:00-20:00', ...}"""
    week = {d: "closed" for d in DAYS}
    for part in (raw or "").split(";"):
        m = re.match(r"\s*([а-яa-z\-\s]+?)\s+(\d{1,2}:\d{2})\s*[-–]\s*(\d{1,2}:\d{2})",
                     part.strip().lower())
        if m:
            for d in expand_days(m.group(1)):
                week[d] = f"{int(m.group(2)[:-3]):02d}{m.group(2)[-3:]}-{m.group(3)}"
    return week

def norm_hours_schema(specs):
    week = {d: "closed" for d in DAYS}
    for spec in specs or []:
        days = spec.get("dayOfWeek", [])
        days = days if isinstance(days, list) else [days]
        for d in days:
            short = d.rsplit("/", 1)[-1][:2]          # https://schema.org/Monday -> Mo
            week[short] = f'{spec["opens"][:5]}-{spec["closes"][:5]}'
    return week

def site_record(url):
    resp = requests.get(url, timeout=20, headers={"User-Agent": "nap-check/1.0"})
    resp.raise_for_status()
    soup = BeautifulSoup(resp.content, "html.parser")   # bytes: кодировку определит сам
    for tag in soup.find_all("script", type="application/ld+json"):
        data = json.loads(tag.string or "{}")
        items = data if isinstance(data, list) else data.get("@graph", [data])
        for item in items:
            if "address" in item and "telephone" in item:
                a = item["address"]
                addr = ", ".join(filter(None, [a.get("addressLocality"),
                                               a.get("streetAddress")]))
                return {
                    "name": item.get("name", ""),
                    "address": norm_address(addr),
                    "phone": norm_phone(item["telephone"]),
                    "hours": norm_hours_schema(item.get("openingHoursSpecification")),
                }
    raise SystemExit(f"{url}: JSON-LD с адресом и телефоном не найден")

def card_record(card):
    return {
        "name": card["name"],
        "address": norm_address(card["address"]),
        "phone": norm_phone(card["phone"]),
        "hours": norm_hours_text(card["hours"]),
    }

def compare(reference, other):
    diffs = []
    if reference["name"].lower() != other["name"].lower():
        diffs.append(("name", reference["name"], other["name"]))
    # порядок слов не важен: «ул Лесная» и «Лесная ул» — один адрес
    if sorted(reference["address"].split()) != sorted(other["address"].split()):
        diffs.append(("address", reference["address"], other["address"]))
    if reference["phone"] != other["phone"]:
        diffs.append(("phone", reference["phone"], other["phone"]))
    for day in DAYS:
        if reference["hours"][day] != other["hours"][day]:
            diffs.append((f"hours.{day}", reference["hours"][day], other["hours"][day]))
    return diffs

def main(path):
    cfg = yaml.safe_load(open(path, encoding="utf-8"))
    errors = 0
    for point in cfg["points"]:
        ref = card_record(point["reference"])
        sources = {"site": site_record(point["site_url"])}
        sources.update({k: card_record(v) for k, v in point["cards"].items()})
        for source, rec in sources.items():
            for field, want, got in compare(ref, rec):
                errors += 1
                print(f"[{point['id']}] {source:8} {field:10} эталон: {want!r} | там: {got!r}")
    print("OK: расхождений нет" if not errors else f"Найдено расхождений: {errors}")
    sys.exit(1 if errors else 0)

if __name__ == "__main__":
    main(sys.argv[1] if len(sys.argv) > 1 else "nap.yaml")

Запуск на примере выше:

$ python nap_check.py nap.yaml
[lesnaya-12] map_b    phone      эталон: '+74951234567' | там: '+74951234576'
[lesnaya-12] map_b    hours.Su   эталон: 'closed' | там: '10:00-20:00'
Найдено расхождений: 2

Этот вывод получен реальным запуском скрипта на тестовой странице. Адрес в map_a записан иначе, чем в эталоне, но после нормализации совпал, поэтому в отчёт не попал. Остались две настоящие ошибки: переставленные цифры телефона и лишнее воскресенье.

Грабли, на которые мы наступили при написании

Кодировка. Первая версия брала resp.text. Тестовый сервер не прислал charset в заголовке, requests по умолчанию решил, что это ISO-8859-1, и кириллица превратилась в кракозябры. Решение — передавать в BeautifulSoup байты (resp.content): он сам найдёт <meta charset> в документе.
@graph. Многие CMS и SEO-плагины кладут организацию не в корень JSON-LD, а в массив @graph рядом с WebSite и BreadcrumbList. Скрипт проверяет оба варианта.
Несколько блоков разметки. На странице бывает три-четыре <script type="application/ld+json">. Ищем тот, где есть и address, и telephone.
dayOfWeek в разных формах. Встречаются "Monday", "https://schema.org/Monday" и "http://schema.org/Monday". Берём последнюю часть после слэша и первые две буквы.

Шаг 4. Праздничные и специальные часы

Обычный график совпадает чаще всего. Расходятся праздники: в карточке на картах владелец отметил сокращённый день 31 декабря, а на сайте об этом никто не вспомнил. Или наоборот.

В schema.org для этого есть тот же openingHoursSpecification, но с полями validFrom и validThrough. Запись с датами действует только в указанный период и уточняет обычный график:

"openingHoursSpecification": [
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "08:00",
    "closes": "21:00"
  },
  {
    "@type": "OpeningHoursSpecification",
    "validFrom": "2026-12-31",
    "validThrough": "2026-12-31",
    "opens": "08:00",
    "closes": "16:00"
  },
  {
    "@type": "OpeningHoursSpecification",
    "validFrom": "2027-01-01",
    "validThrough": "2027-01-02",
    "opens": "00:00",
    "closes": "00:00"
  }
]

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

Как встроить это в проверку:

храните особые даты в эталоне отдельным списком: special: [{date: 2026-12-31, hours: "08:00-16:00"}, {date: 2027-01-01, hours: closed}];
генерируйте из этого списка и обычный график, и записи с validFrom;
в скрипт добавьте функцию, которая для каждой даты из ближайших 14 дней считает «какие часы будут в этот день» по каждому источнику, и сравнивайте уже их.

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

Совет. Заведите в календаре команды напоминание за две недели до каждого длинного праздника: «обновить особые часы в эталоне». Скрипт поймает расхождение, только если праздник уже есть хотя бы в одном источнике.

Шаг 5. Генерируйте разметку сайта из эталона

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

Минимальный генератор блока разметки:

import json, yaml

def to_jsonld(point):
    ref = point["reference"]
    return {
        "@context": "https://schema.org",
        "@type": "LocalBusiness",
        "@id": f'https://example.ru/#{point["id"]}',
        "name": ref["name"],
        "telephone": ref["phone"],
        "address": {
            "@type": "PostalAddress",
            "addressLocality": ref["city"],
            "streetAddress": ref["street"],
        },
        "openingHoursSpecification": ref["hours_spec"],
    }

cfg = yaml.safe_load(open("nap.yaml", encoding="utf-8"))
for p in cfg["points"]:
    print(json.dumps(to_jsonld(p), ensure_ascii=False, indent=2))

Здесь предполагается, что в эталоне адрес хранится по частям (city, street), а часы — сразу в структуре schema.org. Формат эталона подберите под свою CMS: главное, чтобы источник был один.

Текст на странице «Контакты» тоже стоит выводить из эталона, а не набирать в визуальном редакторе. Тогда правка номера в одном файле меняет и видимый текст, и разметку, и ссылку tel:.

Шаг 6. Запуск по расписанию

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

Самый простой вариант — GitHub Actions по расписанию:

name: nap-check
on:
  schedule:
    - cron: "0 6 * * 1"   # каждый понедельник, 06:00 UTC
  workflow_dispatch:
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install requests beautifulsoup4 pyyaml
      - run: python nap_check.py nap.yaml

Если скрипт нашёл расхождения, он вернёт код 1, задача упадёт, и ответственные получат стандартное уведомление о сбое. Подойдёт и обычный cron на сервере с отправкой вывода в рабочий чат.

Что ещё стоит добавить по мере роста:

проверку, что страница контактов отвечает 200, а не редиректом на главную;
сверку координат: точка в разметке geo и точка в карточке не должны расходиться больше чем на 50–100 метров;
отдельный отчёт по сети: сколько точек проверено и где расхождения;
проверку ссылки на сайт в карточках: часто там остаётся старый домен или страница без HTTPS.

Что делать с найденными расхождениями

Скрипт только показывает проблему. Исправлять её нужно в том источнике, который разошёлся с эталоном.

Короткий порядок действий:

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

Совет. Ведите в репозитории файл CHANGELOG-NAP.md: дата, точка, что поменяли и где. Через полгода это лучший ответ на вопрос «почему в 2ГИС другой номер».

Чек-лист NAP-консистентности

[ ] Есть один эталонный файл с данными каждой точки.
[ ] Страница «Контакты» и JSON-LD собираются из эталона.
[ ] Телефоны сравниваются в формате E.164.
[ ] Адреса нормализуются, порядок слов не учитывается.
[ ] Часы сравниваются по дням недели, а не строкой.
[ ] Праздничные часы заведены заранее и есть в разметке через validFrom и validThrough.
[ ] Данные карточек берутся из официальных API, выгрузок или снимков, без парсинга страниц.
[ ] Проверка запускается по расписанию и падает при расхождениях.
[ ] Для каждого расхождения понятно, кто и где его исправляет.

Итог

NAP-консистентность звучит как термин из чек-листа SEO-агентства, но по сути это обычная инженерная задача: один источник правды, нормализация, автоматическая сверка и алерт. Сотня строк на Python закрывает её для одной точки и для сети из десятков филиалов.

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

Как добавить карту на сайт и разметить организацию в JSON-LD: шаблон страницы «Контакты» для локального бизнеса

Mapli — Sun, 01 Nov 2026 11:52:31 +0000

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

На практике обе части часто делают на скорую руку. Карту вставляют первым попавшимся кодом, и она съедает половину бюджета производительности. Микроразметку организации либо не делают вовсе, либо копируют из чужого шаблона с чужими часами работы.

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

как добавить карту на сайт четырьмя способами и какой выбрать;
как встроить виджет карты на сайт без потерь в скорости;
что делать с отзывами с Яндекс Карт на сайте;
как собрать микроразметку организации по schema.org LocalBusiness в JSON-LD;
как проверить результат до релиза.

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

Что должно быть на странице «Контакты»

Минимальный набор для локального бизнеса:

адрес текстом, а не только меткой на карте;
кликабельный телефон (tel:);
часы работы, включая выходные дни;
короткое описание, как найти вход: «вход со двора», «второй этаж, лестница справа»;
встроенная карта с меткой именно вашей организации;
блок application/ld+json с теми же данными.

Ключевое слово здесь — «теми же». Карта, текст страницы и разметка описывают одну точку на местности. Если в одном месте корпус 2, а в другом строение 2, поисковик видит два разных объекта, а клиент идёт не к той двери.

Совет. Начинайте не с кода, а с карточки организации на картах. Откройте её и выпишите название, адрес, телефон и часы ровно в том виде, в каком они там указаны. Это и будет эталон для страницы и для разметки.

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

Вариантов встраивания больше, чем кажется. Выбор зависит от того, что карта должна делать.

1. Виджет карты из карточки организации

Самый быстрый путь. В карточке организации на Яндекс Картах есть пункт «Поделиться» → «Виджет с картой». Вы выбираете размер и получаете готовый iframe.

Плюсы:

метка сразу ваша, с названием и рейтингом;
не нужен API-ключ;
данные в виджете обновляются вместе с карточкой.

Минус один: внешний вид почти не настраивается. Для страницы «Контакты» небольшого бизнеса это обычно не проблема.

2. Конструктор карт

Если нужно больше одной метки или своя схема проезда, берите конструктор. Запрос «яндекс конструктор карт на сайт» как раз про этот сценарий:

несколько филиалов на одной карте;
линия от остановки или метро до входа;
выделенная зона парковки;
подписи к точкам.

Конструктор отдаёт интерактивную карту (JavaScript или iframe), статичную картинку и версию для печати. Статичная картинка пригодится ниже, для приёма с фасадом.

3. JavaScript API

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

Частая ситуация: карту подключили через API, а ключ не указали или указали не тот. Карта рисуется, но поиск и маршруты не работают. Если вы встретили запрос «яндекс карты api» в задаче для сайта одной кофейни, скорее всего, API там избыточен.

4. Статичная карта

Обычная картинка с меткой. Ни скриптов, ни тайлов, ни запросов к сторонним серверам. Подходит для:

лёгких лендингов;
AMP-подобных страниц и писем;
заглушки перед загрузкой интерактивной карты.

У 2ГИС похожий набор — собственный виджет карты и API, поэтому всё, что написано ниже про производительность, относится и к виджету 2ГИС на сайте.

Что выбрать

Задача	Способ
Одна точка, нужно быстро	Виджет из карточки
Несколько филиалов или схема проезда	Конструктор карт
Поиск, маршруты, своя логика	JavaScript API
Максимальная скорость, без скриптов	Статичная карта

Виджет карты на сайт без потерь в скорости

Интерактивная карта тянет скрипты, тайлы и шрифты. Если она в первом экране, страдает LCP. Если у неё нет заданной высоты — CLS. На слабом телефоне с мобильным интернетом это заметно.

Базовая версия: lazy-loading и зарезервированная высота

<div class="map-box">
  <iframe
    src="https://yandex.ru/map-widget/v1/?…ваш_код_виджета…"
    title="Карта: как нас найти"
    loading="lazy"
    referrerpolicy="no-referrer-when-downgrade"
    allowfullscreen></iframe>
</div>

<style>
  .map-box { aspect-ratio: 16 / 9; max-height: 420px; }
  .map-box iframe { width: 100%; height: 100%; border: 0; }
</style>

Что здесь важно:

loading="lazy" — браузер не загружает карту, пока она далеко от области просмотра. Атрибут поддерживается всеми современными браузерами;
aspect-ratio у контейнера резервирует место заранее, вёрстка не прыгает;
title нужен для скринридеров, без него iframe для них безымянный.

Фасад: карта только по клику

Если карта всё же в первом экране или страница должна быть совсем лёгкой, используйте паттерн «фасад». Сначала показываете статичную картинку, а iframe создаёте по клику.

<button class="map-facade" type="button"
        data-src="https://yandex.ru/map-widget/v1/?…ваш_код_виджета…">
  <img src="/img/map-static.webp" alt="Схема проезда к нашему входу"
       width="800" height="450" loading="lazy">
  <span>Показать интерактивную карту</span>
</button>

<script>
  document.querySelectorAll('.map-facade').forEach((btn) => {
    btn.addEventListener('click', () => {
      const frame = document.createElement('iframe');
      frame.src = btn.dataset.src;
      frame.title = 'Карта: как нас найти';
      frame.style.cssText = 'width:100%;aspect-ratio:16/9;border:0';
      frame.allowFullscreen = true;
      btn.replaceWith(frame);
    }, { once: true });
  });
</script>

Фасад не стоит ставить, если карта — главное на странице и без неё человек не поймёт, куда идти. Тогда лучше обычный iframe с loading="lazy" чуть ниже адреса и телефона: текстовые контакты видны сразу, карта догружается следом.

Мобильная версия

На телефоне у встроенной карты есть ещё одна проблема: она перехватывает прокрутку. Человек листает страницу, палец попадает на карту — и вместо скролла карта начинает двигаться.

Несколько приёмов:

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

<a class="route-btn"
   href="https://ссылка-на-карточку-организации-на-картах"
   target="_blank" rel="noopener">
  Построить маршрут
</a>

Несколько карт на одной странице

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

Отзывы с Яндекс Карт на сайт

Отдельный частый запрос — отзывы с Яндекс Карт на сайт. В карточке организации через «Поделиться» доступен виджет отзывов, его код вставляется так же, как карта.

Что важно знать:

отзывы подтягиваются автоматически, переносить тексты на сайт не нужно;
виджет показывает реальные отзывы, в том числе отрицательные, поэтому отвечать на них в карточке нужно регулярно;
к виджету отзывов применимы те же правила скорости: loading="lazy", заранее заданная высота, размещение ниже первого экрана;
не копируйте тексты отзывов на страницу как свои и не размечайте их как отзывы о вашей организации в JSON-LD: Google прямо не показывает звёздочки для отзывов, которые организация размечает о самой себе на своём сайте.

Для отзывов 2ГИС на сайте логика та же: официальный виджет вместо копирования.

Микроразметка организации: JSON-LD по schema.org

Карта на странице — картинка для человека. Поисковику понятнее структурированные данные. Для локального бизнеса берите LocalBusiness или его подтип из schema.org: CafeOrCoffeeShop, AutoRepair, BeautySalon, Dentist, HairSalon и другие. Чем точнее тип, тем лучше. Полный список подтипов — на странице LocalBusiness на schema.org.

Почему JSON-LD, а не Microdata? Оба формата допустимы. Но JSON-LD живёт отдельным блоком и не зависит от вёрстки: редизайн не сломает разметку, а разметка не мешает верстальщику.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "AutoRepair",
  "@id": "https://example.ru/#org",
  "name": "Название как в карточке на картах",
  "url": "https://example.ru/",
  "telephone": "+7-000-000-00-00",
  "image": "https://example.ru/img/facade.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ул. Примерная, д. 1, стр. 2",
    "addressLocality": "Город",
    "postalCode": "000000",
    "addressCountry": "RU"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 55.000000,
    "longitude": 37.000000
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "20:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "10:00",
      "closes": "16:00"
    }
  ],
  "hasMap": "https://ссылка-на-карточку-организации-на-картах",
  "sameAs": [
    "https://ссылка-на-карточку-организации-на-картах",
    "https://ссылка-на-второй-картографический-сервис"
  ]
}
</script>

Разберём поля, на которых чаще всего ошибаются.

name и address

Название — как на вывеске и в карточке, без приписок «недорого» или «круглосуточно». Адрес — в том же формате, что и в карточке: та же улица, тот же формат дома, корпуса и строения. streetAddress — одна строка, город отдельно в addressLocality.

geo: координаты

Координаты — числа, а не строки, с точкой в качестве разделителя. Шести знаков после точки достаточно, чтобы попасть в конкретный вход.

Где их взять: кликните по точке на карте, и сервис покажет координаты в порядке «широта, долгота». Проверка обратная: вставьте пару чисел в поиск по координатам в Яндекс Картах и посмотрите, куда встанет метка.

Частая ловушка: в адресной строке карт координаты нередко идут в обратном порядке, «долгота, широта» (например, параметр ll). Если перепутать, точка уедет далеко от города, а валидатор ничего не скажет — формально всё корректно.

openingHoursSpecification

Структурированный вариант надёжнее строки openingHours: в нём проще описать разные часы по дням. Выходной день просто не указывайте. Если работаете круглосуточно, используйте "opens": "00:00" и "closes": "23:59". На праздники можно добавить отдельный объект с validFrom и validThrough.

sameAs и hasMap

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

Ставьте прямую ссылку на карточку организации, а не на поисковую выдачу карт.
Берите канонический адрес карточки без UTM-меток и параметров сессии.
hasMap указывает на карту с вашим местоположением, туда подходит та же ссылка на карточку.

Совет. Добавьте @id с якорем вида https://example.ru/#org. Если на других страницах сайта тоже есть разметка (статьи, услуги), ссылайтесь на организацию через этот @id. Так у вас будет одна сущность, а не пять почти одинаковых.

Филиалы

У каждого филиала — своя страница и свой блок LocalBusiness со своим адресом, телефоном, часами и ссылкой на свою карточку. Общую компанию описывайте как Organization на главной, а филиалы связывайте с ней через parentOrganization. Не перечисляйте все адреса одним массивом в одном блоке.

Куда положить блок

На страницу «Контакты» обязательно; можно и в шаблон всех страниц, если данные одни и те же.
Блок может стоять в <head> или в <body>, порядок не важен.
Отдавайте его в исходном HTML. Разметку, которую вставляет скрипт после загрузки, обрабатывает не каждый краулер.
Если CMS или SEO-плагин уже генерирует разметку, не добавляйте вторую. Две организации с разными телефонами хуже, чем одна.

Проверка перед релизом

Schema Markup Validator (validator.schema.org) — проверяет синтаксис и соответствие словарю schema.org.
Rich Results Test от Google — показывает, как разметку видит его краулер, в том числе после выполнения JavaScript.
Валидатор микроразметки в Яндекс Вебмастере — проверка для Яндекса, принимает и URL, и фрагмент кода.
Сверка с карточкой. Откройте рядом карточку на картах и пройдитесь по полям: название, адрес, телефон, часы. Никакой валидатор этого за вас не сделает.
Lighthouse или PageSpeed Insights — посмотрите LCP и CLS до и после добавления карты.

Привычки, которые экономят время:

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

Чек-лист страницы «Контакты»

[ ] Адрес, телефон и часы видны текстом в первом экране.
[ ] Карта показывает вашу метку, а не центр города.
[ ] У iframe есть loading="lazy", title и зарезервированная высота.
[ ] На мобильных карта не перехватывает прокрутку.
[ ] Отзывы — официальным виджетом, а не копией текста.
[ ] В JSON-LD точный подтип LocalBusiness, числовые координаты и openingHoursSpecification.
[ ] sameAs ведёт прямо на карточку организации.
[ ] Данные на сайте, в разметке и в карточке совпадают до буквы.

Частые вопросы

Нужен ли API-ключ, чтобы вставить карту на сайт?
Для виджета из карточки и карты из конструктора — нет. Ключ нужен для JavaScript API, когда вы используете поиск, маршруты и другую логику.

Микроразметка организации нужна на всех страницах?
Обязательно — на странице контактов. На остальных достаточно ссылки на организацию через @id, если на них есть своя разметка.

Что важнее: карта или разметка?
Это разные аудитории. Карта помогает человеку дойти до двери, разметка помогает поисковику связать сайт с конкретной точкой и карточкой. Нужны обе, и они должны совпадать.

Коротко

Как добавить карту на сайт: виджет из карточки для одной точки, конструктор для схем и филиалов, API для логики, статичная картинка для скорости.
Виджет карты — с loading="lazy", зарезервированной высотой или фасадом по клику.
Микроразметка — точный подтип schema.org LocalBusiness, числовые координаты, openingHoursSpecification, sameAs на карточку.
Данные на сайте, в разметке и в карточке совпадают.

Пошаговую инструкцию со скриншотами — где взять код виджета, как собрать карту в конструкторе и когда нужен API-ключ — мы собрали здесь: Как вставить Яндекс Карту на сайт.