Игнорирование микроразметки JobPosting лишает сайт до 40% потенциального бесплатного трафика из специализированных виджетов Google Jobs и Яндекс.Работы. В нише рекрутинга техническая валидность страницы вакансии важнее ее текстового объема, так как роботы-агрегаторы индексируют строго определенные поля данных.
Микроразметка JobPosting: критические поля
Для попадания в Google Jobs обязательным является заполнение полей title, description, datePosted и hiringOrganization. Ошибка в формате даты (например, использование относительных значений «2 дня назад» вместо ISO 8601) приводит к тому, что вакансия либо не индексируется, либо вылетает из выдачи через 30 дней. Оптимальный период обновления datePosted — раз в 7-14 дней для актуализации позиции в топе агрегатора.
Кейс: внедрение поля baseSalary (диапазон зарплаты) увеличило CTR сниппета на 15-22% в сегменте IT-рекрутинга, так как соискатели чаще кликают на вакансии с четко указанным «вилкой» (например, 150 000 — 200 000 руб.), чем на формулировку «по результатам собеседования».
Экспертный вывод: используйте JSON-LD вместо Microdata. Это снижает риск ошибок при верстке и ускоряет парсинг данных роботом на 10-15%.
Гео-привязка и локальная индексация
Поле jobLocation — главный фильтр для соискателя. Ошибка многих SEO-специалистов — указать только город. Для максимального охвата в Google Jobs необходимо использовать структуру с указанием страны и региона (например, RU -> Moscow). Если вакансия удаленная, обязательно используйте атрибут jobLocationType: "TELECOMMUTE".
Практика показывает, что вакансии с точным указанием адреса офиса (streetAddress) ранжируются выше в локальном поиске («работа рядом со мной»), что особенно критично для линейного персонала (ритейл, HoReCa), где радиус поиска соискателя редко превышает 5-7 км.
Экспертный вывод: для удаленки всегда ставьте TELECOMMUTE. Попытка обмануть алгоритм, указав крупный город вместо удаленного формата, ведет к высокому показателю отказов (Bounce Rate выше 70%) и последующему пессимизированию страницы.
Борьба с дублями в агрегаторах
Проблема Job-порталов — идентичные описания вакансий от разных агентств или филиалов одного бренда. Если Google видит 10 страниц с текстом «Менеджер по продажам» и одинаковыми требованиями, он оставит в индексе только одну. Чтобы избежать этого, внедряйте уникальные идентификаторы в поле directApply или используйте разные URL для каждой позиции, опираясь на структуру URL и иерархия категорий.
Пример: при наличии 50 одинаковых вакансий курьера по разным районам города, группировка их на одной странице с перечислением локаций через микроразметку списка повышает видимость всей категории на 30% эффективнее, чем создание 50 пустых страниц-дублей.
Экспертный вывод: используйте канонические ссылки (rel="canonical") на основную вакансию-шаблон, если контент совпадает более чем на 80%, чтобы не размывать ссылочный вес.
Валидация и технический мониторинг
Ошибка в одном символе в JSON-LD делает всю разметку невидимой. В крупных каталогах (от 1000 вакансий) ручная проверка невозможна. Необходимо настроить автоматический мониторинг через Google Search Console в разделе «Улучшения» -> «Вакансии». Среднее время исправления критических ошибок в разметке на больших проектах составляет 3-5 рабочих дней до переиндексации.
Важный нюанс: Яндекс.Работа менее требователен к JSON-LD, но чувствителен к наличию четкого заголовка H1 и структурированного списка требований/обязанностей (теги ul/li). Отсутствие списка в описании снижает вероятность попадания в «рекомендованные» на 10-12%.
Экспертный вывод: раз в месяц проводите выборочный аудит 5% новых вакансий через Rich Results Test. Это позволяет вовремя заметить сбои в работе CMS при генерации кода.
Вывод
Для захвата трафика из агрегаторов начните с полного внедрения JSON-LD с обязательным заполнением полей baseSalary и jobLocationType. Избегайте создания сотен страниц-дублей для однотипных вакансий — лучше оптимизировать одну страницу-хаб. Мой вердикт: техническая разметка JobPosting сегодня дает более быстрый и дешевый прирост конверсии, чем классическое наращивание ссылочной массы, так как переводит сайт из разряда «просто сайта» в разряд «источника данных» для поисковика.
