SEO вакансий: страницы, JobPosting и Indexing API

Страница вакансии живёт быстрее обычной статьи: сегодня позиция открыта, завтра изменились условия, через неделю найден сотрудник. Если сайт создаёт новый URL при каждой правке, оставляет JobPosting на закрытых объявлениях или перенаправляет все архивы на общий список, человек получает устаревшие предложения, а поисковая система — противоречивые сигналы. Поэтому SEO вакансий начинается с жизненного цикла данных, а не с генерации JSON-LD.

Хороший документ описывает одну реальную открытую позицию, работодателя, место или правила удалённой работы, обязанности, требования и способ откликнуться. Структурированные данные повторяют видимую информацию. Sitemap и Indexing API сообщают об изменениях, но не делают слабую страницу полезной и не гарантируют обход, индексацию или специальное отображение.

Ниже разделены задачи работодателя, карьерного раздела и агрегатора. Особое внимание уделено Indexing API: Google разрешает его не для любых SEO-страниц, а только для URL с JobPosting либо трансляцией BroadcastEvent, вложенной в VideoObject. Использовать этот интерфейс как универсальную «быструю индексацию» нельзя.

Какую задачу решает страница вакансии

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

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

Работодателю полезны также постоянные страницы профессий и команд: «работа разработчиком», «команда поддержки», «офис в Казани». Они объясняют процесс и остаются после закрытия конкретной позиции. Не размечайте такие вечные материалы как JobPosting без действующего объявления. Это информационные или категорийные страницы со своей задачей.

Агрегатор соединяет вакансии разных организаций и несёт дополнительную ответственность за источник, актуальность и дедупликацию. Он не должен создавать впечатление, что является работодателем, если только не нанимает сам. Название и идентификатор hiringOrganization берутся из реальных данных, а способ отклика ясно показывает, куда уйдёт заявка.

До разработки сформулируйте измеримый контракт: доля открытых позиций с полными полями, время снятия закрытого объявления, успешность формы, ошибки разметки и ответы URL. Клики и позиции оцениваются позже и не заменяют качество процесса. Общие показатели продвижения собраны в статье о KPI SEO.

Как построить URL и архитектуру раздела

Каждая реальная вакансия получает один стабильный канонический URL, связанный с внутренним идентификатором записи. Название должности можно включить в slug для понятности, но изменение формулировки не обязано создавать новый документ. Если адрес всё же изменён, старый ведёт одним постоянным редиректом на новый, пока речь идёт о той же позиции.

Иерархия обычно выглядит так: карьерный раздел → направление или город → карточка вакансии. Навигация реализуется обычными ссылками, доступными без формы и JavaScript-жеста. Хлебные крошки помогают вернуться к актуальному списку. Закрытая позиция может предложить похожие вакансии, но такие рекомендации не заменяют честный статус исходной страницы.

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

У агрегатора отдельный URL имеет каждая уникальная вакансия, а не каждая комбинация источника и UTM. Если одно объявление поступило из двух каналов, используйте идентификатор работодателя, должность, локацию и реквизиты для дедупликации. Не объединяйте разные смены или города только из-за похожего заголовка.

Страница должна быть доступна из структуры, а не только из фида. Sitemap помогает обнаружению, но устойчивые внутренние ссылки показывают контекст. Правила проектирования разобраны в материале о структуре сайта, а причины потери URL — в статье про страницы-сироты.

Сразу предусмотрите архивную политику. База хранит дату открытия, изменения, плановое окончание, фактическое закрытие, причину и статус URL. Без этих полей невозможно синхронно обновить видимый текст, JobPosting, Sitemap и уведомление API. Ручная пометка в интерфейсе без серверного состояния быстро расходится между каналами.

Что кандидат должен увидеть на странице

Используйте конкретное название роли без рекламных добавок и перечисления всех ключей. «Backend-разработчик PHP» понятнее, чем «Срочно! Лучшая работа программистом с высокой зарплатой». Заголовок страницы, H1 и поле title JobPosting описывают одну позицию согласованно, хотя не обязаны совпадать посимвольно.

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

Работодатель представлен настоящим названием, ссылкой на организацию и при наличии логотипом. Агрегатор обозначает источник и не имитирует чужой бренд. Контакты и политика обработки данных доступны до отправки формы. Нельзя публиковать фиктивную позицию только для сбора резюме: Google запрещает объявления, за которыми нет текущего найма.

Способ отклика должен работать и относиться к этой позиции. Не заставляйте человека войти только для чтения описания; требования Google допускают форму отклика, но сведения о вакансии должны быть доступны публично. Проверьте успешную отправку, сообщение об ошибке, доступность клавиатурой и мобильный сценарий.

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

Добавьте дату публикации или обновления так, чтобы человек понимал свежесть. Не меняйте datePosted ежедневно без нового открытия позиции: это исходная дата публикации, а не инструмент искусственного омоложения. Существенное обновление можно показать отдельной датой интерфейса и точным lastmod в Sitemap.

Как заполнить JobPosting

Разметка находится на детальной странице одной вакансии и описывает тот же текст, который видит кандидат. Минимальные обязательные свойства Google включают datePosted, полное description, hiringOrganization, jobLocation для работы в конкретном месте и title. Точный набор зависит от формата, поэтому шаблон сверяют с текущей официальной документацией.

validThrough обязателен, если у объявления есть дата окончания. Значение передаётся в ISO 8601 и учитывает время и зону, когда это существенно. Если дата неизвестна и вакансия действительно не имеет установленного срока, свойство можно не добавлять, но фактическое закрытие всё равно должно быстро обновить страницу и разметку.

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

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

Дополнительные свойства образования и опыта используйте, только если данные надёжны. Некоторые возможности могут находиться в развитии и не давать видимого эффекта. Валидность означает корректный синтаксис и обязательные поля, а не гарантию показа. Общая логика внедрения раскрыта в статье о Schema.org.

Проверяйте несколько состояний: офисная работа, полностью удалённая, без объявленной зарплаты, срочный договор, обновление и закрытие. Один красивый пример не покрывает условные ветви шаблона. После релиза сравните разметку с данными базы и видимой страницей, а не только с исходным JSON.

Локация, удалённая работа и зарплата

Для работы на конкретном месте jobLocation содержит Place и PostalAddress с реальной страной, регионом и городом. Не подставляйте адрес головного офиса, если сотрудник будет работать на другом объекте. Несколько допустимых мест можно описать отдельно, когда кандидат действительно выбирает между ними.

jobLocationType: TELECOMMUTE предназначен для полностью удалённой позиции. Один день из дома, гибрид или возможность иногда договориться не делают вакансию полной удалёнкой. Честно опишите формат в тексте и не используйте флаг для попадания в более широкий фильтр.

Для удалённой работы укажите страны или территории, откуда разрешён найм, через applicantLocationRequirements. Ограничение может быть связано с юридическим лицом, часовым поясом или налогами. Нельзя заявлять «из любой точки», а затем отказывать всем за пределами одного города. Видимый текст повторяет существенные границы.

Зарплата описывается MonetaryAmount и QuantitativeValue с валютой, значением или диапазоном и единицей: час, день, неделя, месяц или год. Сумма до налогов и после налогов, фиксированная часть и бонусы должны быть понятны человеку. Если диапазон зависит от региона, не объединяйте несовместимые условия в одну вводящую в заблуждение цифру.

Региональные страницы полезны только при реальных отличиях вакансий и условий. Копии «работа в каждом городе» без открытых позиций создают пустые посадочные. Для сети офисов продумайте локальную навигацию и корректный адрес; общие принципы есть в материале о региональном SEO.

Мультиязычный карьерный сайт переводит не только заголовок, но обязанности, требования и способ отклика. Языковые версии связываются корректным hreflang и собственными URL. Не канонизируйте русский текст на английский только потому, что вакансия одна: страницы предназначены разным читателям.

Дубли, canonical и агрегаторы

Одна вакансия часто появляется на сайте работодателя, карьерной платформе и у партнёров. Владелец каждого домена управляет только своими URL. Canonical между доменами является сигналом, но не договором о том, какой источник выберет поисковик. Агрегатор должен добавлять удобство поиска и актуальные данные, а не копировать тысячи объявлений без контроля.

Внутри одного сайта устраните копии с параметрами отслеживания, печатные версии и разные пути категории. Канонический URL вакансии отвечает 200 и указан в Sitemap. Технические варианты перенаправляются или канонизируются по реальному совпадению. Детальная механика описана в руководстве по rel=canonical.

Не ставьте JobPosting на страницы результатов поиска, категории и подборки. Google требует разметку на наиболее детальной leaf page одной позиции. Список может содержать обычные карточки и ссылки. Вставка десятков JobPosting на категорию создаёт нарушение и ухудшает сопровождение: закрытие одной записи меняет общий документ непредсказуемо.

Если агентство размещает вакансию от имени клиента, hiringOrganization описывает реального работодателя, когда он известен и публикация разрешена. Агентство не присваивает себе позицию. Если название конфиденциально, видимый текст и разметка не должны противоречить друг другу или придумывать организацию.

Дедупликация не строится только по названию. «Менеджер по продажам» в двух городах или подразделениях может означать разные позиции. Используйте ID источника, работодателя, локацию, условия и дату. При объединении сохраняйте путь отклика и историю обновления, чтобы закрытие одного источника не удалило действующее предложение другого.

Большой агрегатор отдельно управляет фасетной навигацией, краулингом и картами. Практика каталогов разобрана в статье о SEO агрегаторов, а риски фильтров — в руководстве по фасетной навигации.

Sitemap и границы Indexing API

Sitemap содержит канонические URL открытых вакансий и точный lastmod, когда содержание действительно изменилось. Не добавляйте страницы поиска, фильтры и UTM. Карта остаётся способом покрытия всего раздела; основы формата и лимитов есть в статье о Sitemap.

Indexing API позволяет сообщить Google об обновлении или удалении URL с JobPosting, а также страниц трансляций, где BroadcastEvent вложен в VideoObject. Для статей, товаров, категорий и любых других страниц этот API не предназначен. Не распространяйте сервисный аккаунт на общий «ускоритель индексации» и не обходите квоты несколькими проектами.

Уведомление URL_UPDATED используют для новой или существенно обновлённой вакансии, URL_DELETED — после удаления страницы. Запрос содержит один URL; до ста отдельных запросов можно объединить в HTTP batch. Пакет уменьшает число соединений, но не превращает сто URL в одно уведомление и не отменяет квоты.

Перед настройкой API владелец подтверждает права в Search Console, создаёт сервисный аккаунт, выдаёт минимальный доступ и безопасно хранит ключ. Секрет не попадает в репозиторий, браузер и журнал приложения. Отправитель записывает результат каждого URL, повторяет временные ошибки с ограничением и не бесконечно повторяет постоянный отказ.

Статус уведомления показывает, когда Google получил сообщение, а не факт индексации или специального показа. API лишь помогает назначить свежий crawl. Страница всё равно должна отвечать корректно, быть доступной Googlebot, соответствовать правилам и пройти обработку. Не обещайте кандидату или заказчику «вакансия появится через минуту».

Очередь API наблюдайте по возрасту, а не только по числу сообщений. Сто одинаковых повторов могут выглядеть как высокая активность, хотя одна вакансия застряла. Храните vacancy ID, URL, тип события, версию записи, HTTP-ответ и следующую попытку. Временные ошибки повторяются с увеличивающейся задержкой, постоянные уходят на разбор и не занимают квоту бесконечно. Перед повтором удалённой позиции проверьте, что более новое событие открытия не изменило состояние. Метрика успешной доставки подтверждает лишь приём уведомления API и никогда не подменяет отчёт об индексировании.

Яндекс использует свои механизмы. Для специализированных сайтов вакансий в Вебмастере описан отдельный YML-фид с требованиями к предложениям и сетам. Это не тот же канал, что Google JobPosting или Indexing API. Перед внедрением проверьте применимость программы к типу сайта, региону и текущему интерфейсу.

Как закрывать и повторно открывать вакансию

Состояния должны быть явными: draft, scheduled, open, paused, filled, expired и removed. Только open доступна для отклика и содержит актуальную JobPosting. Paused не принимает заявки и не должна выглядеть открытой; команда решает, сохранится ли публичная информационная страница без разметки или позиция временно исчезнет.

Google предлагает три способа убрать закрытую вакансию: установить validThrough в прошлом, полностью удалить страницу с 404/410 либо удалить JobPosting. Для сохранённой архивной страницы наиболее понятен статус «вакансия закрыта», отключённый отклик и отсутствие активной разметки. Если документ больше не нужен, честный 404 или 410 сообщает об удалении.

Не перенаправляйте каждую закрытую позицию на главную карьерного раздела. Это не равнозначная замена и может выглядеть как soft 404. Прямой 301 оправдан, если вакансия действительно объединена с тем же действующим объявлением или адрес изменился без смены сущности. Иначе покажите архив с похожими позициями или удалите URL.

После закрытия синхронно меняются видимый статус, кнопка, разметка, Sitemap и API-уведомление. Очередь должна быть идемпотентной: повтор одного события не возвращает вакансию в открытое состояние. Периодическая сверка находит записи, у которых база закрыта, а публичный HTML всё ещё принимает отклик.

Защититесь и от событий, пришедших не по порядку. У каждого изменения есть версия записи: поздний повтор open не перекрывает более новое filled, а неудачная отправка API не откатывает публичный статус. Сначала фиксируется состояние базы и становится доступен правильный HTML, затем обновляются Sitemap и очередь уведомлений. Если вторичный канал временно недоступен, задача повторяется с той же версией и ключом идемпотентности. В журнале видны прежнее и новое состояния, инициатор, время публикации, результат удаления разметки и ответ каждого канала. Так оператор может безопасно повторить шаг, не открывая вакансию заново и не отправляя кандидатов в уже закрытую форму.

Повторное открытие оценивайте по идентичности. Если это та же позиция, временно приостановленная без существенной смены условий, обновите существующий URL и отправьте URL_UPDATED. Новый набор с другим requisition ID, командой, локацией или обязанностями лучше считать новой вакансией, сохранив честный архив старой.

Удалённая страница не должна отвечать 200 пустой карточкой «ничего не найдено». Это soft 404. Проверьте реальный код снаружи, удалите URL из активного Sitemap и уведомите API. Различия 404 и 410 и оформление помощи человеку разобраны в статье о странице 404.

Качество, отклик и защита кандидата

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

Форма собирает только необходимые данные, объясняет цель и срок хранения, использует защищённое соединение и не раскрывает резюме в публичном URL. Загруженные файлы проверяются и хранятся вне открытого каталога. Ссылка для просмотра кандидата требует авторизации; noindex и robots.txt не являются защитой персональных данных.

Измеряйте не только отправку формы. Нужны ошибки валидации, начало и успешное завершение, источник, ID вакансии и время. Не передавайте в аналитику имя, телефон, email или содержимое резюме. В отчёте соединяют агрегированные события по vacancy_id, не создавая публичный профиль кандидата.

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

Агрегатор проверяет право публикации и канал обновления. Если источник перестал присылать изменения, предложения не остаются активными бесконечно. Задайте TTL или дату обязательной перепроверки, но не выдумывайте validThrough для работодателя. При конфликте данных объявление временно снимается до подтверждения.

Разметка проходит автоматическую и ручную выборочную проверку. Зарплата в JSON должна быть видна, remote — действительно полным, организация — совпадать, форма — принимать заявку. Общие правила структурированных данных предупреждают, что техническая корректность не гарантирует использования и что нарушение может привести к ручным мерам.

Числовой пример управления вакансиями

На карьерной платформе 6 240 URL: 2 480 открытых вакансий, 1 760 сохранённых архивов и 2 000 удалённых записей, которые ещё встречаются во внешних ссылках. Проверка суммы: 2 480 + 1 760 + 2 000 = 6 240. В активный Sitemap должны входить канонические открытые страницы, а архивы оцениваются по отдельной политике.

Команда проверила 320 URL: 160 открытых, 80 архивных и 80 удалённых. Найдены 24 закрытые вакансии с активной JobPosting, 16 страниц с зарплатой только в JSON-LD, 12 удалённых URL с кодом 200 и пустым текстом, 8 дублей с параметрами. Всего 24 + 16 + 12 + 8 = 60 нарушений.

Закрытые записи синхронизировали, скрытые зарплаты либо показали человеку, либо удалили из разметки, soft 404 заменили честными статусами, дубли перенаправили. Повторная выборка включала те же 320 URL и дала ноль прежних нарушений. Это означало соответствие проверенному контракту, а не обещание, что все открытые вакансии будут показаны поиском.

За рабочий день появилось 48 новых вакансий, изменилось 82 и закрылось 50. Очередь сформировала 48 + 82 + 50 = 180 уведомлений. Их отправили двумя HTTP batch: 100 и 80 отдельных запросов. Каждая запись сохранила URL, тип события, ответ API и число попыток; успешный batch не считался доказательством индексации.

В конце дня сверка базы и сайта показала 2 478 открытых страниц: было 2 480, добавили 48, закрыли 50, поэтому 2 480 + 48 − 50 = 2 478. Изменённые 82 не меняют количество. Sitemap содержал ровно 2 478 канонических URL, а очередь не имела необработанных постоянных ошибок.

Операционный SLA закрытия составлял 30 минут. Из 50 закрытых позиций 46 обновились за 12 минут, 3 — за 24 минуты и одна за 41 минуту из-за ошибки origin. Доля в SLA: 49 ÷ 50 × 100 = 98%. Команда исправила повтор очереди и сохранила инцидент, не связывая техническую метрику с будущими позициями.

Мониторинг и регламент команды

Ежедневная сверка сравнивает базу, публичный HTML, JobPosting, Sitemap и очередь уведомлений. Для каждой вакансии проверяются статус, canonical, код, возможность отклика, datePosted, validThrough и lastmod. Расхождение создаёт задачу с владельцем, а не просто строку в общем отчёте.

Алерты нужны на активную разметку закрытой записи, закрытую кнопку при статусе open, 4xx открытой вакансии, JobPosting на списке, недоступный robots.txt, рост ошибок API и отставание очереди. Порог задаётся по риску: одна фиктивно открытая вакансия уже вводит кандидата в заблуждение, даже если доля мала.

Раз в неделю проверяйте Search Console и Яндекс Вебмастер, но интерпретируйте данные по каналам. Google JobPosting, Google Indexing API и YML-программа Яндекса — разные системы. Ошибка одного фида не доказывает проблему другого. Общие возможности Google описаны в статье о Search Console.

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

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

Отчёт руководителю разделяет операционные и поисковые показатели. Первые — полнота, свежесть, SLA закрытия, успешность отклика и ошибки. Вторые — показы, клики и целевые действия по открытым страницам. Ни корректная разметка, ни API не гарантируют позиции или специальное представление; команда отвечает за точные данные и доступный процесс.

Каждый месячный отчёт сопровождайте выборкой URL и временем проверки. Тогда улучшение SLA можно перепроверить по журналу, а ошибку конкретного источника — отделить от общего шаблона. Агрегированные проценты без списка состояний и правил закрытия плохо подходят для расследования.

Главный вывод

SEO вакансий — это синхронное управление реальным наймом и публичным URL. Детальная страница показывает полные условия и рабочий отклик, JobPosting повторяет видимый текст, Sitemap хранит канонические открытые адреса, а Indexing API сообщает Google об изменениях только для разрешённых типов страниц. После закрытия вакансия перестаёт выглядеть активной: разметка удаляется или срок истекает, ненужный URL отвечает 404/410, архив честно сообщает статус. Такая система защищает кандидата и данные сайта, но не обещает индексацию, специальный блок или позиции.