Архитектура сущностей: как объединение данных на разных доменах усиливает SEO

Это не очередная статья для маркетологов про «качество контента», а разбор того, почему одинокий сайт с каталогом плюс отдельный job-портал на другом домене стабильно сливают трафик конкурентам с нормальной архитектурой. Для бэкендера это прямой повод перестать плодить пять изолированных бэков на разных доменах и собрать общий data layer.

Что именно compounding

Классический сценарий из материала: компания двадцать лет держала отдельный сайт, отдельный job-портал, отдельный форум поддержки. Каждый — один визит, один отвал, рекламный аукцион по новой. Пользователь пришёл, посмотрел вакансию, ушёл к конкуренту, который в выдаче выше. Лечится это не длиной title-тега и не «правильным meta description», а архитектурой: одна аутентификация, одна сущность Organization, профиль которой светится и в новостях, и в каталоге, и в events, и в geo. ML-поисковики давно смотрят не на плотность ключей, а на то, реальная ли сущность, доверяют ли ей, вплетена ли она в граф индустрии. Когда эти узлы начинают ссылаться друг на друга контекстно — каждая новость ссылается на компанию, каждая компания на свои вакансии, каждая вакансия на мероприятие — получается самоподдерживающийся двигатель. Это и есть compounding, и никакой костыль в виде «плотности ключей» его не заменит.

Что должно быть в коде

Никаких «SEO-плагинов». Только нормальная разметка и нормальные связи между сущностями. Минимум по чек-листу:

• schema.org JSON-LD для каждой сущности — Organization, NewsArticle, JobPosting, Event, LocalBusiness. Один валидный блок на страницу, без каши из десяти @type в одном скрипте.
• Внутренние ссылки между площадками по якорям с названием сущности, а не «нажмите сюда». Knowledge graph строится на устойчивых именах, а не на «как заведут редакторы».
• Единый идентификатор сущности во всех доменах — sameAs в JSON-LD, ссылка на wikidata или собственный org-profile, общий slug. Иначе для поисковика каждый домен — отдельная компания с тремя именами.
• Sitemap per entity, не один гигантский на полгигабайта. И robots.txt без Disallow: /api/, если этот API закрывает половину каталога от краулера.

Чем пройтись в терминале

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

# выгрузить все sitemap, склеить в один список
curl -s | grep -oE 'https?://[^<]+' | sort -u > all_urls.txt
# проверить, есть ли JSON-LD на ключевых страницах
for url in $(head -50 all_urls.txt); do
count=$(curl -s "$url" | grep -c 'application/ld+json')
echo "$url: $count blocks"
done
# вытащить sameAs из Organization, чтобы понять, связаны ли домены между собой
curl -s | grep -oE '"sameAs":\[[^]]+\]' | head -3

Если в выдаче у половины страниц нет @graph с явной Organization — никакого compounding у вас не будет, будет тот же остров с мгновенным отвалом и сливами бюджета на рекламу. Бэкапы делайте, метрики на отдельные домены не разносите, и не называйте это «экосистемой» в ТЗ — иначе следующий инцидент в проде будет ваш, а SEO-проблемы спишут на «слабый контент».