🔥 PARASITE SEO #4: готовая Schema, которая связывает автора...

🔥 PARASITE SEO #4: готовая Schema, которая связывает автора, сайт и соцсети

В прошлом посте мы собрали Entity Home - центральную страницу, которая объясняет Google:

«Вот я. Вот мой сайт. Вот мои профили. Вот мой контент».

Теперь обещанная техническая часть.

Как все это связать через Schema.org? 👇

🧩 Нам понадобятся 3 сущности:

ProfilePage → страница вашего профиля

Person → вы как автор

Organization → ваш бренд / компания

А дальше связываем их между собой.

Представим:

Money Site: site.ru

Автор: Иван Петров

Entity Home: site.ru/ivan-petrov/

Бренд: SEOdelov

Пример JSON-LD:

<script type="application/ld+json">

"

@context": "https://schema.org",

"@graph": [

"

@type": "ProfilePage",

"@id": "https://site.ru/ivan-petrov/#profilepage",

"url": "https://site.ru/ivan-petrov/",

"mainEntity": "

@id": "https://site.ru/#person"

"

",

"

@type": "Person",

"@id": "https://site.ru/#person",

"name": "Иван Петров",

"url": "https://site.ru/ivan-petrov/",

"worksFor": "

@id": "https://site.ru/#organization"

",

"sameAs": [

"LINKEDIN",

"YOUTUBE",

"REDDIT",

"X"

]

",

"

@type": "Organization",

"@id": "https://site.ru/#organization",

"name": "SEOdelov",

"url": "https://site.ru/"

"

]

"

</script>

Не пугайтесь кода 😁

На самом деле здесь происходит очень простая вещь.

Google получает карту:

👤 Иван Петров

↓

работает / связан с

↓

🏢 SEOdelov

↓

имеет официальный сайт

↓

🌐 site.ru

А через sameAs получает еще один слой:

Иван Петров

↙ ↓ ↘

LinkedIn YouTube Reddit X

То есть мы не заставляем поисковик самостоятельно угадывать:

«Этот Иван из LinkedIn и Иван с site.ru - один человек или просто совпадение?»

Мы явно описываем связь.

🔥 А теперь самое интересное.

У нас ведь есть СТАТЬИ.

И здесь начинается следующий уровень связки.

Допустим, на site.ru опубликована статья.

В ее Article Schema можно указать:

"author": "

"@id": "https://site.ru/#person"

"

Обратите внимание.

Мы не создаем нового автора.

Мы ссылаемся на ТОТ ЖЕ @id, который уже использовали в Entity Home.

Получается:

СТАТЬЯ №1 ─┐

СТАТЬЯ №2 ─┤

СТАТЬЯ №3 ─┤

↓

↓

Entity Home

↙ ↓ ↘

LinkedIn YouTube Reddit

↓

Бренд

↓

Money Site

🕸 Вот это уже настоящий граф сущностей.

Причем @id здесь особенно удобен.

Представьте @id как внутренний «паспорт» объекта внутри вашей структурированной модели.

Например:

https://site.ru/#person

В разных Schema-блоках мы можем ссылаться на этот идентификатор и тем самым показывать:

👉 речь идет об одной и той же сущности.

Но есть один ОЧЕНЬ важный момент.

⚠️ Не превращайте sameAs в помойку ссылок.

Туда не надо пихать:

❌ каждую статью о вас

❌ каждый каталог

❌ сотни профилей

❌ случайные упоминания

❌ купленные страницы

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

То есть:

«Это тоже Я».

А не:

«На этой странице когда-то написали обо мне».

И еще важнее:

Schema должна соответствовать тому, что реально находится на странице.

Не надо создавать в JSON-LD фантастическую биографию эксперта, которой пользователь на странице вообще не видит 😁

💡 И теперь возвращаемся к Parasite SEO.

Зачем мы вообще делали всю эту конструкцию?

Потому что наша цель не:

«Поставить Schema и получить +20 позиций».

Так это не работает.

Цель - построить максимально однозначный цифровой след:

Money Site

↕

Entity Home

↕

Person / Organization

↕

Социальные профили

↕

Авторство

↕

Внешние публикации

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

🚀 А теперь вопрос становится еще интереснее:

Что делать с публикациями на ЧУЖИХ сайтах?

Как связать гостевую статью, Reddit, LinkedIn, YouTube и другие внешние страницы с нашей сущностью, если доступа к их коду у нас НЕТ?

Вот это и разберем в следующей части.

Там уже будет чистая практика External Entity Building 🔥

Ваш @seodelov 👇

Источник новости https://t.me/seodelov/148...