Суть материала
Главное за минуту
Поисковой системе нельзя отправить паспорт автора и получить отметку «эксперт подтверждён». Рабочий подход — создать проверяемую цепочку сущности: реальное имя, постоянная авторская страница, byline в статьях, корректная Person/Article разметка, внешние профили и независимые подтверждения опыта. Google отдельно предупреждает, что вымышленные имена, ложные credentials и AI-generated headshots, используемые для имитации эксперта, являются deceptive authorship.
Можно написать под фотографией человека:
«Иван Петров — эксперт с 18-летним опытом».
Можно добавить Person schema.
Можно придумать должность.
Можно даже создать десятки статей с этим автором.
Но поисковая система всё равно получает в основном утверждения самого сайта о самом себе.
Это слабое доказательство.
Google прямо рекомендует делать автора понятным: использовать byline, вести её на страницу с информацией об авторе и давать сведения о его опыте. Одновременно Google отдельно предупреждает против deceptive authorship — вымышленных профилей, AI-generated headshots, придуманных имён и ложных credentials, используемых для создания впечатления человеческой экспертности.
Поэтому практическая задача звучит не:
«как написать красивую биографию автора?»
а:
«как создать такую цепочку данных, чтобы личность, работа и специализация человека подтверждались из нескольких независимых мест?»
Именно это имеет смысл делать на контентном сайте.
Что поисковая система действительно может проверить
Google не выдаёт обычным авторам статей синюю галочку и не предлагает загрузить паспорт в Search Console.
Поисковый робот работает с открытой информацией.
Он может увидеть:
статья
→имя автора
→ссылка на профиль
→структурированные данные
→внешние профили
→другие публикации
→сайт работодателя
→упоминания человека в других источниках.
Google в рекомендациях по Article прямо советует указывать author.url и sameAs, чтобы помочь системе лучше понять, кто является автором.
Search Quality Rater Guidelines идут ещё дальше: при исследовании репутации нельзя просто принимать на веру заявления самого сайта. Асессорам рекомендуют искать независимые отзывы, ссылки, публикации, рекомендации экспертов, новости и другие внешние источники информации о создателе контента. Для YMYL-тем особое значение имеет мнение профессиональных и экспертных источников.
Это и даёт нам практическую модель.
Сам сайт сообщает, кто автор. Независимые источники подтверждают, что такой человек существует и действительно связан с заявленной областью.
Первый слой: автор должен быть отдельной сущностью сайта
Самая частая техническая ошибка — одна общая страница /about/, где среди двадцати абзацев упомянуты все сотрудники.
Для ключевых авторов лучше иметь собственные постоянные URL:
/authors/ivan-petrov/
/authors/elena-sidorova/
Страница должна быть посвящена именно одному человеку.
Google поддерживает ProfilePage для страниц, основным объектом которых является Person или Organization, и отдельно приводит страницу автора новостного сайта или сотрудника компании как корректный сценарий.
На странице должны быть видны минимум:
- имя и фамилия;
- реальная роль;
- область специализации;
- краткая профессиональная биография;
- практический опыт;
- список публикаций этого автора;
- ссылки на внешние подтверждения;
- при необходимости контакт или способ связаться с редакцией.
Если человек пишет про WordPress, а биография состоит из:
«Любит технологии, путешествия и качественный контент»
она почти ничего не сообщает об экспертности.
Гораздо полезнее:
«Разрабатывает сайты на WordPress с 2017 года. Работает с PHP, Nginx, WooCommerce и технической оптимизацией. Автор практических разборов по производительности и серверной настройке».
Но и такую информацию желательно подтверждать.
Второй слой: имя автора должно быть одинаковым везде
Поисковой системе сложнее связать сущность, если на сайте используется:
Александр Сергеев
на GitHub:
alex-s
на конференции:
Александр А. Сергеев
а в статье:
Редакция проекта.
Никто не требует запрещать никнеймы, но основная идентичность должна быть понятной.
Практически:
Авторская страница: Александр Сергеев
Article author: Александр Сергеев
GitHub bio: Александр Сергеев / компания
страница компании: Александр Сергеев
выступление: Александр Сергеев, должность
профессиональный профиль: то же имя.
Если используется псевдоним, его можно явно связать с основным именем, а не создавать две несвязанные сущности.
Третий слой: каждая статья должна вести к автору
На статье недостаточно просто вывести имя обычным текстом.
Byline лучше сделать ссылкой:
<a href="/authors/ivan-petrov/" rel="author">
Иван Петров
</a>
Google прямо рекомендует byline там, где пользователь её ожидает, и советует вести её на дополнительную информацию об авторе.
Дальше та же связь должна быть отражена в Article schema:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Как ускорить WordPress",
"author": {
"@type": "Person",
"@id": "https://example.com/authors/ivan-petrov/#person",
"name": "Иван Петров",
"url": "https://example.com/authors/ivan-petrov/"
}
}
Google рекомендует указывать Person, имя и url или sameAs, позволяющие однозначнее определить автора.
Главное правило:
видимый автор статьи и автор в schema должны совпадать.
Не нужно писать пользователю «Редакция», а роботу подсовывать конкретного эксперта.
Четвёртый слой: разметьте саму страницу автора
Для /authors/ivan-petrov/ можно использовать:
{
"@context": "https://schema.org",
"@type": "ProfilePage",
"@id": "https://example.com/authors/ivan-petrov/#profile",
"url": "https://example.com/authors/ivan-petrov/",
"mainEntity": {
"@type": "Person",
"@id": "https://example.com/authors/ivan-petrov/#person",
"name": "Иван Петров",
"jobTitle": "WordPress-разработчик",
"image": "https://example.com/images/ivan-petrov.jpg",
"worksFor": {
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example"
},
"sameAs": [
"https://github.com/example",
"https://www.linkedin.com/in/example"
]
}
}
Google официально поддерживает ProfilePage, mainEntity, name, изображения и sameAs для связанных внешних страниц.
Schema.org дополнительно предоставляет свойства вроде:
jobTitle
worksFor
knowsAbout
hasCredential
hasCertification
affiliation
alumniOf.
Но здесь есть принципиальный момент: наличие свойства в Schema.org не означает, что Google использует его как ranking factor или обязательно показывает в выдаче. Это прежде всего структурированное описание сущности.
Почему нельзя превращать E-E-A-T, Schema.org и другие признаки качества в условные «баллы ранжирования», отдельно разобрано в статье «Факторы ранжирования: какие сигналы учитывают поисковые системы»
Поэтому schema нужна для согласования данных, а не для производства экспертности из воздуха.
Пятый слой: sameAs должен вести на реальные подтверждения
Одна из самых полезных частей Person — внешние связи.
Google прямо рекомендует url или sameAs, чтобы лучше различать авторов.
Но сюда не нужно добавлять двадцать случайных соцсетей.
Лучше три сильных источника, чем пятнадцать пустых аккаунтов.
Для разработчика это могут быть:
- GitHub с реальными репозиториями и историей активности;
- профиль работодателя;
- публичные выступления;
- статьи на других известных сайтах;
- профиль конференции;
- Stack Overflow или профиль профессионального сообщества;
- профессиональная сертификация с проверяемым URL.
Для врача:
- официальный сайт клиники;
- реестр лицензий;
- страница профильной организации;
- научные публикации;
- университет или медицинская организация.
Для юриста:
- адвокатская палата или другой официальный реестр;
- сайт организации;
- профильные публикации;
- конференции и комментарии СМИ.
Для исследователя:
- ORCID;
- университет;
- Google Scholar или издательские страницы;
- DOI-публикации;
- конференции.
Смысл один:
внешняя страница должна существовать не потому, что SEO-специалист вчера создал её ради sameAs, а потому что автор реально работал и оставил профессиональный след.
Шестой слой: сделайте подтверждение двусторонним
Сильнее выглядит не только:
ваш сайт → внешний профиль
но и:
внешний профиль → ваш сайт.
Например, GitHub bio или страница сотрудника компании указывает:
vagizov.com
а авторская страница Vagizov.com указывает на этот GitHub.
Это создаёт понятную двустороннюю связь между сущностями.
То же относится к публичному профилю специалиста, личному сайту, странице конференции или организации.
Не все внешние площадки позволяют поставить backlink. Это нормально.
Но если хотя бы часть независимых профилей подтверждает тот же домен, компанию, должность и специализацию, идентичность становится значительно менее двусмысленной.
А как доказать, что фотография не сгенерирована
По одной фотографии — практически никак.
EXIF можно удалить или подделать.
AI detector может ошибаться.
Самостоятельное заявление:
«Фото настоящее»
ничего не доказывает.
Поэтому фотография не должна быть основой доказательства личности.
Если человек реальный, используйте реальную фотографию или вообще обойдитесь без портрета.
Доказательство должно идти через сущность:
имя
+работодатель
+профессиональные профили
+публикации
+историю деятельности.
Google отдельно предупреждает именно о другом сценарии: создании фиктивного профиля человека с AI-generated headshot, вымышленным именем или ложными credentials для имитации экспертизы.
Подробнее о том, где Google проводит границу между нормальным использованием генеративного ИИ и имитацией экспертности, — в материале «AI-контент и Google: что работает, а что выглядит как мусор».
Поэтому если человека не существует, решение не в том, чтобы сделать его образ «более реалистичным».
Нужно не представлять фиктивного персонажа реальным экспертом.
Если материал фактически делает редакция, честнее указать:
Редакция Example
и использовать Organization.
Если текст подготовлен AI и проверен реальным редактором, можно показать реального редактора или reviewer.
Чем реально подтверждать квалификацию
Стаж
Плохо:
15 лет в SEO.
Лучше:
Работает с поисковым продвижением с 2011 года.
И рядом реальные подтверждения:
- старые проекты;
- публикации прошлых лет;
- архив сайта;
- внешний профиль;
- информация работодателя;
- выступления.
Не обязательно публиковать трудовую книжку.
Нужна непротиворечивая история.
Образование
Если оно имеет значение для темы, укажите учебное заведение и специальность.
Для регулируемых областей полезна ссылка на официальный реестр или страницу организации, если она существует.
Не выкладывайте паспорт и диплом с персональными данными только ради SEO.
Сертификаты
Сильнее всего сертификат с публичным ID или verification URL.
Слабее:
Сертифицированный специалист Google.
без названия программы, даты и возможности проверить утверждение.
Проекты
Для разработчика реальные проекты зачастую убедительнее диплома.
Покажите:
- роль;
- что именно человек сделал;
- технологию;
- результат;
- ссылку на проект или кейс.
Публикации
Если автор действительно специалист, со временем должен появляться профильный архив.
Тридцать материалов одного автора на одну тему создают гораздо более понятную специализацию, чем тридцать статей от него же про:
медицину → сантехнику → инвестиции → автомобили → Photoshop.
Яндекс отдельно пишет, что специализация сайта и подтверждённый опыт автора особенно важны там, где цена ошибки высока.
Независимые упоминания — самый сложный и самый сильный слой
На собственном сайте можно написать что угодно.
Именно поэтому в Quality Rater Guidelines Google отдельно говорится об independent reputation research.
Асессорам предлагают искать:
- независимые рекомендации;
- экспертные упоминания;
- статьи СМИ;
- публикации;
- профессиональные организации;
- обсуждения;
- награды и другие источники репутации.
Для небольшой компании необязательно стремиться в Wikipedia.
Практические варианты проще:
Гостевая экспертная статья
Не SEO-текст с коммерческим анкором, а нормальная публикация с именем автора.
Комментарии в отраслевых СМИ
Автор выступает источником по своей теме.
Конференция или вебинар
Страница мероприятия содержит имя, роль и тему доклада.
Профильная организация
Карточка участника или специалиста.
Open-source
GitHub прекрасно подтверждает реальную разработческую деятельность.
Профессиональное портфолио
Behance, Dribbble или отраслевые каталоги — для дизайнера.
Научные работы
ORCID, DOI и страницы издательств — для исследователей.
Это уже гораздо труднее создать массово фиктивно и поддерживать годами непротиворечиво.
Организация тоже должна быть настоящей сущностью
Экспертность автора не существует отдельно от издателя.
Для корпоративного сайта полезно иметь:
- страницу «О компании»;
- контакты;
- юридическую информацию там, где она уместна;
- реальный телефон и email;
- команду;
- услуги или направления работы;
- историю проектов.
Google поддерживает Organization structured data и рекомендует указывать сведения, помогающие идентифицировать компанию: url, logo, sameAs, контакты, адрес и, когда применимо, юридические идентификаторы.
Для автора тогда получается ещё одна проверяемая связь:
Person → worksFor → Organization.
Если организация сама существует только как название в футере, ценность такой связи гораздо ниже.
Что делать с редакторами и экспертами-рецензентами
Не каждый материал должен быть написан тем специалистом, который проверял факты.
Можно честно разделить роли.
Например:
Автор: Анна Петрова
Экспертная проверка: Сергей Иванов, инженер
Это лучше, чем приписывать весь текст эксперту, который его никогда не писал.
На странице специалиста можно вывести раздел:
Материалы, которые проверял эксперт.
А в статье явно показать:
Материал проверен Сергеем Ивановым, инженером-проектировщиком.
Но опять же — только если человек действительно выполнял проверку.
Как проверить, что техническая часть работает
После внедрения нужно проверить не глазами, а инструментами.
Для каждой статьи:
- Открыть исходный код и убедиться, что
Article.authorреально присутствует. - Проверить, что
author.urlведёт на правильную страницу автора. - Убедиться, что используется один стабильный
Person @id. - Проверить авторскую страницу на
ProfilePage. - Проверить
sameAs. - Прогнать structured data через инструменты Google.
- Проверить schema в валидаторе Яндекс Вебмастера. Яндекс поддерживает Schema.org и предоставляет отдельный валидатор.
- Проверить индексацию author URL.
- Найти автора обычным поиском по имени.
- Проверить, совпадает ли внешний образ человека с заявленной биографией.
Это уже полноценный author audit.
Практический пример: как я бы сделал профиль SEO-специалиста
Допустим, на сайте есть автор:
Иван Петров — SEO-специалист, 10 лет опыта.
Сейчас существует только его фотография и два предложения биографии.
Я бы сделал следующее.
Создал:
/authors/ivan-petrov/
Добавил:
Иван Петров
SEO-специалист
Специализация: техническое SEO, Google Search Console, Яндекс Вебмастер, миграции сайтов.
Дальше — не общие слова, а доказательства.
Опыт: занимается SEO с 2016 года.
Практика: участвовал в 70 проектах — если это реально подтверждается портфолио компании.
Профили: LinkedIn, профессиональная соцсеть или другой существующий публичный профиль.
Выступления: ссылка на страницу конференции.
Публикации вне сайта: две-три реальные статьи.
Материалы на сайте: 40 статей именно по SEO.
Работодатель: компания с отдельной страницей команды, где также указан Иван.
В sameAs ставлю только реальные внешние идентификаторы.
В каждой статье использую один и тот же @id.
Через несколько месяцев появляется ещё одно интервью и выступление — добавляю их в профиль.
Так экспертность растёт не потому, что мы переписали bio.
Растёт объём проверяемых фактов о реальном человеке.
Что точно не нужно делать
Не создавать двадцать «экспертов» с AI-фотографиями, одинаковыми биографиями и нулевой историей вне сайта.
Не придумывать стаж.
Не покупать сертификат ради строки в bio.
Не ставить sameAs на аккаунты, которые не принадлежат автору.
Не использовать Person для вымышленного редакционного персонажа, если пользователь должен воспринимать его как реального человека.
Не писать knowsAbout со списком из ста SEO-ключей.
Не делать врача автором статьи о кредитах только потому, что у него сильный профиль.
Не рассчитывать, что одна разметка Person исправит отсутствие репутации.
Минимальный стандарт для каждого автора
Для обычного экспертного контентного сайта я бы ввёл редакционное правило.
Автор допускается к публикации под личным именем, если есть:
- Реальное имя или честно обозначенный публичный профессиональный псевдоним.
- Постоянная индексируемая author page.
- Реальная специализация.
- Несколько содержательных материалов по этой специализации.
- Хотя бы один сильный внешний профиль или независимое подтверждение.
- Совпадающие данные на сайте и вне сайта.
- Корректный
Person+ProfilePage. Article.authorсо стабильным@id.- Отсутствие выдуманных credentials.
- Редакционная ответственность за опубликованный материал.
Для YMYL-тем планку нужно поднимать: лицензии, профессиональные реестры, профильное образование и экспертная проверка становятся значительно важнее.
Google прямо указывает, что E-E-A-T особенно существенно для тем, способных затронуть здоровье, финансовую стабильность и безопасность пользователя.
Как проверить весь сайт за один день
Начните не с Schema.org.
Сначала выгрузите список авторов.
Для каждого создайте таблицу:
| Проверка | Автор 1 |
|---|---|
| Реальное имя | Да/Нет |
| Author page | URL |
| ProfilePage | Да/Нет |
| Article author URL | Да/Нет |
| Стабильный Person @id | Да/Нет |
| Работодатель подтверждает | URL |
| Внешний профессиональный профиль | URL |
| Реальные проекты | URL |
| Публикации вне сайта | URL |
| Credentials | URL / нет |
| Тематический архив | количество |
| Противоречия | описание |
Самая важная колонка — URL.
Не:
есть опыт.
А:
где его можно проверить?
Если у двадцати авторов таблица заполнена только словами владельца сайта, сначала нужно решать эту проблему, а уже потом улучшать schema.
Поисковым системам нужна не декларация, а непротиворечивая сущность
Google рекомендует показывать, кто создал контент, связывать byline с дополнительной информацией об авторе и избегать фиктивных creator profiles.
Яндекс отдельно говорит о репутации, подтверждённой экспертизе и опыте автора или организации.
Ни одна из систем не обещает:
добавьте Person schema → получите +20% к позициям.
Если нужно глубже понять, где заканчиваются публичные рекомендации Google и начинаются реальные алгоритмические системы ранжирования, см. «Google алгоритмы: как работает ранжирование и Core Update»
Такой механики публично нет.
Практическая задача намного приземлённее.
Нужно сделать так, чтобы человек и робот могли пройти цепочку:
статья
→реальный автор
→специализация
→история публикаций
→реальная организация
→внешние профессиональные следы
→независимые подтверждения.
Если эта цепочка существует, сайт не просто заявляет экспертность.
Он предоставляет данные, по которым её можно проверять.
И именно это я бы считал правильной технической и редакционной работой с авторами в 2026 году.
Практика
Как создать проверяемый профиль автора
Создайте постоянный URL
Для каждого реального автора создайте индексируемую страницу /authors/imya-familiya/, посвящённую только этому человеку, и не меняйте её URL без необходимости.
Заполните проверяемую биографию
Укажите реальное имя, роль, специализацию, опыт и только те достижения, которые можно подтвердить внешним источником или реальной работой.
Подключите внешние подтверждения
Добавьте ссылки на публичные профессиональные профили, работодателя, публикации, реестры, выступления или проекты, где совпадают имя и специализация.
Свяжите все статьи
На каждой публикации выводите byline со ссылкой на ту же авторскую страницу и используйте её как author.url в Article schema.
Разметьте сущность автора
Добавьте ProfilePage + Person, стабильный @id, sameAs и только достоверные дополнительные сведения. Проверьте разметку инструментами Google и Яндекс Вебмастера.
Подтвердите экспертность контентом
Свяжите профиль с архивом профильных статей, кейсов, исследований, кода или других результатов работы, которые демонстрируют опыт, а не просто заявляют о нём.
Проверьте внешнюю картину
Найдите имя автора в поиске без site: и убедитесь, что внешние источники не противоречат биографии на сайте и позволяют однозначно связать человека с указанной специализацией.
Уберите неподтверждаемые заявления
Удалите вымышленные должности, стаж, награды и псевдоэкспертные AI-профили. Если материал создаёт редакция, честнее указать организацию или редакционную команду.
FAQ
Как поисковые системы понимают, что автор настоящий
Для обычных статей Google не предоставляет отдельной процедуры верификации личности автора. Вместо этого Google рекомендует ясные byline, страницы автора и author.url/sameAs, позволяющие системам точнее связать публикацию с конкретным человеком.
Нет. Structured data помогает машине понять, что именно вы утверждаете об авторе, но не превращает утверждение в доказанный факт. Наиболее полезна разметка, когда она совпадает с видимым содержанием и с независимыми внешними источниками.
Фото не является обязательным подтверждением экспертности, но если профиль изображает реального человека, не стоит создавать фиктивную личность через AI-портрет. Google прямо приводит AI-generated headshots в сочетании с вымышленными именами или credentials как пример deceptive authorship.
Независимые проверяемые следы: профиль работодателя, профессиональный реестр, конференция, публикации на других ресурсах, GitHub или другой профиль с реальными работами, сертификат с проверяемым ID, интервью, исследования и устойчивый архив профильных материалов. Quality Rater Guidelines отдельно рекомендуют искать независимые источники репутации, а не верить только заявлениям самого сайта.
Яндекс в ЭПОС прямо связывает экспертность с репутацией, подтверждённым опытом и квалификацией автора или организации и рекомендует опираться на практический опыт и отраслевые знания.
Рейтинг статьи
Материал был полезен?
Оценка помогает понимать, какие материалы стоит обновлять и расширять.
