Приводим в порядок веб-инфраструктуру

Повествование ведется от лица Йоста де Валка.

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

Я решил его создать. specification.website — это платформо-независимая спецификация технических возможностей, которыми должен обладать хороший сайт. Двенадцать разделов: основы, SEO, доступность, безопасность, известные URI, готовность к агентам, производительность, приватность, устойчивость, интернационализация и другие. Открытый проект, ведется публично.

Это и есть базовая веб-инфраструктура. И большинство платформ поставляют ее в неполном виде.

Два PR, одна и та же ошибка

В этом месяце в двух разных репозиториях приняли мои пул-реквесты. Первый — PR #16837 в пакете @astrojs/sitemap для Astro, вышел в версии 3.7.3 на прошлой неделе. Второй — PR #431 в EmDash, месяцем раньше. Оба фиксили примерно одно и то же: теперь индекс карты сайта действительно передаёт значение < lastmod > для каждого файла. Благодаря этому краулер может понять, какая именно дочерняя карта сайта изменилась, и не перекачивать их все заново. Исправление для Astro заняло 145 строк кода вместе с тестами. Для EmDash — 270 строк.

Ни одно из них не было каким-то сложным. Просто никто не хотел потратить час (или около того) на то, что не является новой функцией, не имеет маркетинговой страницы и всего лишь приводит все в порядок.

Две совершенно разные кодовые базы — и одинаковая дыра в одних и том же дефолтном поведении. Отдельные стандарты существуют (sitemaps.org, schema.org, Open Graph протокол, документация Google), но нет единого канонического источника, на который могли бы ориентироваться разработчики платформ.

Именно в этот момент фраза «Надо бы написать спецификацию» перестала быть просто мыслью и превратилась в реальный проект.

Дефолтные данные — это инфраструктура

Google запустил протокол Sitemap в июне 2005 года вместе с инструментом для отправки карт сайта. В течение пяти лет генерация карты сайта оставалась рутинной задачей, на которую соглашались лишь немногие технически подкованные люди — формировать ее приходилось для каждого сайта отдельно. А потом в октябре 2010 года вышел WordPress SEO by Yoast 1.0 со встроенной генерацией XML-карт сайта. Уже через год-два эта функция появилась практически в каждом SEO-плагине для WordPress. То же самое произошло с тегами Open Graph, схемой JSON-LD, каноническими URL, метаданными robots, hreflang.

Ни один из этих дефолтных форматов не является сложным. Все упирается в кропотливый труд. Большинство из них — это сто строк кода, пара тестов и готовность внимательно изучить спецификацию, чтобы выпустить скучную, но правильную реализацию. Я рассказывал про дефолтные данные на WordCamp Europe в 2014 году, потому что они определяют поведение миллионов пользователей, которые никогда даже не открывали панель настроек. Определяют и по сей день.

Сегодня в сети гораздо больше платформ, чем в 2010-м. WordPress — лишь одна из них. Серьёзный блог теперь может работать на Astro, Eleventy, Next.js, любой headless CMS или EmDash. И всем им нужны одни и те же дефолты. Но ни одна из этих платформ не поставляет их все «из коробки», потому что эта работа кажется «негламурной», да и практически никто из аудитории ее не заметит.

Вот эту брешь я постоянно вижу, когда смотрю на SEO в современном веб-стеке. Все фрагменты мозаики в основном есть. Просто они не подключены к дефолтам. Спецификация даёт всем, кто занят в этой сфере — будь то интеграция для Astro, модуль для EmDash, тема для Hugo или стартер для Next.js, — чёткую точку опоры.

Это всё ещё SEO

Правильно размеченный индекс карты сайта помогает Googlebot решить, что нужно переобойти. Он также помогает краулерам ChatGPT и Perplexity принять аналогичное решение. Содержимое страницы, содержащей ссылку на Markdown-версию, доступно для агента без парсинга HTML — если агент знает, где ее искать. JSON-LD схема даёт поисковым системам граф для обхода. И она же предоставляет этот граф агентам.

Майк Кинг называет эту работу relevance engineering (инженерия релевантности). Другие называют её GEO. Я понимаю порыв, но считаю это ошибкой. Мы потратили два десятилетия на то, чтобы научить людей думать о SEO при создании сайта. Этот капитал доверия тяжко заработан. Разбрасываться им, каждые полгода придумывая новый акроним — чисто маркетинговый рефлекс, совершенно бесполезный.

В технологиях тоже нет чёткой точки перехода. Google внедрил BERT для понимания запросов в 2019 году. Passage Indexing вышел в 2020-м. Трансформерные модели ранжирования, подпитывающие AI Overviews, — это эволюция тех моделей, которые уже работали в классическом поиске. Изменения были непрерывными. Ребрендинг продаёт разрыв, которого на самом деле нет.

Готовность к агентам — это новый трюк. Новые трюки будут всегда. Сантехник должен продолжать учиться, когда отрасль переходит на новые трубы, но мы всё равно называем его сантехником. SEO-специалисты, которые учатся предоставлять Markdown-альтернативы и JSON-LD-графы для агентов, по-прежнему занимаются SEO.

Помогите это построить

specification.website — открытый проект. Пул-реквесты приветствуются.

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

Переименование SEO не продвинет веб. Его двигает написанный патч. А когда одного патча недостаточно — написанная спецификация.

Это не самая крутая работа. Но именно такая работа приближает нас к тому вебу, который мы хотим получить.

Источник: https://joost.blog

Дмитрий/ автор статьи
CCO, Senior SEM/PPC Specialist, WordPress-энтузиаст, переводчик с английского и немецкого. Серый кардинал русскоязычного WP-комьюнити.
Блог про WordPress
Добавить комментарий

Получать новые комментарии по электронной почте.