Новое в веб-разработке: что меняется и к чему готовиться

Каждый год список громких новинок обновляется, но до реальных проектов доходит меньше половины – поэтому здесь собраны только те современные тенденции в веб-разработке, которые уже подтверждены статусом Baseline, отраслевыми опросами и практикой аудита легаси-систем. Дальше разберем, какие тренды веб-разработки в этом году стоит закладывать в техзадание уже сейчас, а что пока остается экспериментом.

Главное:

• Будущее веб-разработки в 2026 году определяют шесть линий: браузерная платформа, генерация кода, модернизация легаси, безопасность, подготовка сайта к ИИ-агентам и экономика проекта.
• Готовность браузерной возможности проверяют по статусу Baseline, а не по дате релиза в блоге вендора. Widely available кладут в основу верстки, Newly available берут как улучшение с запасным вариантом отображения.
• ИИ-инструментами пользуются 90% специалистов по разработке ПО, при этом 46% не доверяют точности результата (DORA, 2025; Stack Overflow, 2025). В России код с ИИ пишут 58% инженеров, полностью доверяют результату 11% (Т-Технологии, 2026).
• Спрос сместился с новых сайтов на модернизацию работающих, и подрядчика выбирают по аудиту интерфейса, точкам падения конверсии и предсказуемости отдачи от вложений (Workspace, 2026).
• У сайта появился второй пользователь, ИИ-агент. Вместе с ним в смету приходят машиночитаемые данные, структурированная разметка и документация, которая читается без рендеринга страницы.

Что нового в веб-разработке на самом деле, проще всего проверить на одной метрике. Откройте подборку трендов двухлетней давности: Core Web Vitals в ней почти наверняка описаны через FID, отклик на первое взаимодействие. В отчетах этой метрики больше нет, вместо нее считают INP, отзывчивость на всех взаимодействиях за сессию, включая третий клик по фильтрам каталога.

Сайт с отличным FID при этом легко проваливается по INP. Читатель, взявший устаревший список за план работ, полгода оптимизирует показатель, которого никто уже не смотрит. 

Изменения в веб-разработке 2026 года идут по шести линиям, и ИИ-генерация здесь только одна из них.

• Платформа. Разработчики браузеров договорились о согласованном наборе возможностей на год вперед в рамках Interop 2026, а статус Baseline показывает, готова ли конкретная возможность к продакшену.
• Генерация кода. ИИ-ассистенты стали рабочей нормой, но узкое место переехало из написания кода в ревью и тестирование.
• Легаси. За модернизацией работающего продукта приходят чаще, чем за новым сайтом, и цена архитектурной ясности выросла вместе с этим.
• Безопасность. Уязвимость появляется теперь и на выходе генератора: 45% задач на генерацию кода дают код с уязвимостью из списка OWASP Top 10 (Veracode, 2025).
• Второй пользователь. Сайт читает ИИ-агент, которому нужны машиночитаемые данные, структурированная разметка и документация, доступная без исполнения JavaScript.
• Инфраструктура и данные. Локализация персональных данных по 152-ФЗ, российский контур, наблюдаемость и явные контракты на интеграции стали частью технического решения проекта.

Во всех шести линиях работает один и тот же сдвиг. Произвести цифровой артефакт стало дешево, а не сломать при этом соседний дорого, поэтому ценность переехала в то, что годами считалось скучной частью работы: понятная архитектура, проверяемые контракты, тесты и измеримые метрики поставки. От этого же зависит структура сметы у владельца ИТ-продукта.

Новейшие технологии веб-разработки. Что из нового в браузерах уже безопасно использовать

У веба есть штатная процедура проверки готовности, она называется Baseline. Это система статусов на web.dev и webstatus.dev, которая показывает, в каких браузерах возможность поддерживается и как давно. Статус Newly available означает, что функция заработала во всех основных движках: Chrome, Edge, Firefox и Safari. Widely available присваивается через 30 месяцев после этой даты, когда возможность держат и старые версии браузеров, еще заметные в статистике посещений.

Критерий для техзадания из этого получается простой. Widely available кладут в основу верстки, Newly available берут как улучшение с запасным вариантом отображения.

Рядом с Baseline работает Interop, ежегодный список расхождений между браузерами, которые разработчики движков договариваются устранить за год. Interop 2026 объявили в феврале, состав фокус-областей собирали по опросам State of HTML и State of CSS, а прогресс каждого движка виден на публичном дашборде в процентах пройденных тестов (web.dev, 2026).

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

Больше всего в смете меняют view transitions. Одностраничные переходы получили Newly available по итогам Interop 2025, а в 2026 году идет работа над переходами между документами. Сценарий «плавно, как в мобильном приложении» на обычном многостраничном сайте больше не требует перевода всего проекта в SPA, и вместе с этим отпадают расходы на маршрутизацию, гидратацию и отдельную SEO-обвязку.

Есть в Interop 2026 и направления, где договоренности нет даже о том, как проводить тесты: единообразное дерево доступности, формат JPEG XL, динамический вьюпорт на мобильных, субтитры WebVTT. Для планирования это значит, что доступность и поведение мобильных браузеров останутся местом расхождений и в 2027 году, поэтому их проверяют руками на устройствах, а не автотестами.

Этот же фильтр убирает из обзоров Web3, AR/VR и голосовые интерфейсы. За пять лет они не дошли до массовых клиентских проектов, а контейнерные запросы и переходы между страницами дошли и меняют верстку уже сейчас.

Внедрение ИИ выросло, доверие к результату упало

ИИ-ассистентами пользуются 90% специалистов по разработке ПО, на 14 процентных пунктов больше, чем годом ранее (DORA, 2025). В том же году 46% разработчиков в опросе Stack Overflow ответили, что не доверяют точности того, что выдает ассистент, годом ранее так отвечали 31%. Инструмент стал массовым быстрее, чем к нему появилось доверие.

Российская картина повторяет ту же развилку, и разрыв здесь даже шире.

Код с помощью ИИ пишут 58% инженеров, полностью доверяют результату 11%. Рост личной продуктивности отмечают 64%, при этом общая скорость разработки почти не меняется (Т-Технологии, 2026).

Разрыв между ощущением и замером проверили экспериментально. Опытным разработчикам open-source выдавали задачи в знакомых им кодовых базах, часть задач разрешалось решать с ассистентом. С ассистентом участники работали на 19% медленнее, а свою работу оценивали как на 20% более быструю (METR, 2025). Подводит здесь интуиция: экономия на наборе кода заметна сразу, а время, ушедшее на проверку, в самоощущение не попадает.

Куда уходит выигрыш, видно по опросу Sonar. Ежедневно применяют ИИ в программировании 72% разработчиков, на проверку и правку сгенерированного уходит 24% рабочего времени, полностью доверяют результату 4%. Время не исчезает, оно переезжает из фазы «написать» в фазу «убедиться, что это работает и не сломает соседнее».

Больше всего инструмент дает в задачах с высокой рутинностью и понятным критерием готовности:

• Прототипы, черновые решения и proof of concept, где скорость важнее долговечности кода.
• Знакомство с чужим проектом, когда нужно понять, где что лежит и откуда берется конкретное поведение.
• Цепочки связанных правок, когда за структурой ответа API меняются DTO, фронтенд и тесты.
• Рефакторинг по шаблону, вроде выноса повторяющегося кода или приведения файлов к единому стилю.
• Черновики тестов, документации и примеров, которые потом дописывает человек.

У всех этих сценариев результат легко проверить, а цена ошибки локальна. Как только задача уходит в бизнес-логику с неявными правилами, выигрыш съедается ревью.

На обратном полюсе стоит вайбкодинг, когда разработчик описывает задачу словами и принимает сгенерированный результат, не разбираясь во внутренностях. В Technology Radar это зафиксировано как антипаттерн, а измерение продуктивности числом сгенерированных строк названо вводящей в заблуждение метрикой (ThoughtWorks, 2026). Чем заменить такую метрику, разберем в последнем разделе.

Крупные команды внедряют ИИ как инфраструктурный проект. В Т-Банке ИИ-инструментами регулярно пользуются больше 85% двенадцатитысячного штата разработки, и компания строит собственную экосистему агентов, поскольку внешние сервисы плохо ложатся на сложную корпоративную инфраструктуру. Вокруг этой работы сложилась отдельная инженерная дисциплина, context engineering. Контекст агенту готовят осознанно: общие инструкции держат в репозитории, в файлах вида AGENTS.md, промпты кешируются, история сжимается, поиск идет по проекту целиком, а не по одному открытому файлу. Обратная сторона описана там же, это раздувание инструкций и протухание контекста, когда агент опирается на устаревшие правила проекта.

Отсюда следствие для студии и для инхаус-команды. ИИ усиливает то, что уже есть: там, где настроены код-ревью, тесты, линтеры и CI, он ускоряет работу, а там, где этого нет, с той же скоростью производит фрагментацию.

Современные подходы веб-разработки к легаси

Запросы на модернизацию, рефакторинг и оптимизацию работающего продукта в 2026 году звучат чаще, чем заказы на новый сайт. Подрядчика при этом выбирают по аудиту интерфейса, по найденным точкам падения конверсии и по предсказуемости отдачи от вложений (Workspace, 2026). Продавать процесс стало сложнее, чем результат.

Обычно за таким запросом стоит проект на CMS, который живет пять или десять лет и накопил историю решений.

Разбирать его удобнее по уровням запутанности, потому что от уровня зависит и объем работ, и цена ошибки:

• Контентный. Логики почти нет, есть разросшаяся структура, дубли страниц, неактуальные разделы и шаблоны, которые правили в спешке. Диагностика простая: посмотрите, сколько страниц не открывали ни разу за последний год.
• Логический. Бизнес-правила расползлись по шаблонам, хукам, обработчикам форм и плагинам, и одно условие про скидку живет в четырех местах в трех вариантах. Проверяется числом файлов, которые придется открыть, чтобы это условие поменять.
• Интеграционный. Сайт стал точкой стыковки CRM, склада, платежей, аналитики и рассылок, причем без контрактов на данные, по принципу «раньше приходило так, надеемся, так и будет приходить». Здесь стоит спросить, что произойдет с заказами, если CRM пришлет поле в другом формате.

От уровня зависит и стратегия. В облачной практике для выбора давно применяют модель 7R, семь стратегий, названия которых начинаются на R, предложенных Gartner в 2010 году (IBM, NetApp).

Ценность модели в том, что разговор «нам надо все переписать» превращается в выбор из семи вариантов с разной ценой, и обычно побеждает комбинация: архив остается как есть, платежи переезжают на новую версию среды, расчет скидок уходит в отдельный слой. Для интеграционного уровня подходит Strangler Fig, когда новый слой ставят рядом со старым, по одному переводят на него сценарии и гасят старый код по краям, не останавливая развитие продукта на квартал.

Место для бизнес-логики за десять лет успело сменить несколько мод, от микросервисов до headless CMS с фронтендом на JAMstack-сборке и PWA для мобильных сценариев. Исходная проблема при этом не исчезала: неописанное правило расползется и по микросервисам тоже.

Генерация кода сделала производство дешевым, а сопровождение дорогим, поэтому архитектурная ясность подорожала. Практичный шаг здесь один, вынести правила бизнеса туда, где их видно. Достаточно слоя рядом с CMS с условиями скидок, статусами заказа и доступностью товара, при котором сама CMS остается контентным ядром. Работает он только вместе с явными контрактами на интеграции и спецификацией правила, написанной до генерации кода, иначе ассистент будет уверенно выдавать правдоподобный код, закрепляющий фрагментацию. Отсюда выросла практика spec-driven development, а какие проверки ставят на контракты, разберем в разделе про безопасность.

Мнение эксперта

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

Дмитрий Панькин, основатель Resolventa – российской компании заказной веб-разработки на Symfony и Laravel, работающей по модели выделенной команды с 2012 года.

Инфраструктура, данные и требования регуляторов

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

Первое ограничение касается размещения персональных данных. Закон 152-ФЗ требует держать базы с данными российских пользователей на серверах в России, причем требование распространяется не только на основную базу, но и на резервные копии, аналитические выгрузки и логи, куда данные попадают транзитом. С 30 мая 2025 года ответственность за утечки ужесточена, штрафы исчисляются миллионами рублей, а для повторных случаев предусмотрены оборотные, то есть считаемые от выручки. Отдельная норма действует с 1 февраля 2024 года: хостинг-провайдеры работают в России только после включения в реестр Роскомнадзора, поэтому провайдера имеет смысл проверить в реестре до подписания договора.

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

На веб-ресурсы приходится каждая пятая успешная атака на организации в мире. Самый частый метод, отказ в обслуживании: доля DDoS среди инцидентов с веб-ресурсами достигла 46%, вдвое больше показателя 2024 года (Positive Technologies, 2025).

Два риска из этого списка связаны напрямую с устройством современной сборки. Теневые API остаются от прошлых версий, тестов или внешних интеграций, не задокументированы и не стоят на мониторинге, при этом продолжают отвечать на запросы, часто без нормальной аутентификации. У контейнеров свой сценарий: компрометация одного контейнера через уязвимость в приложении становится плацдармом для перемещения по внутренней сети оркестратора, а запуск процессов с правами root или открытый доступ к сокету Docker позволяют выйти за пределы контейнера.

Большую часть этих сценариев закрывает короткий набор проверок:

• Инвентаризация персональных данных вместе с резервными копиями, выгрузками и логами, плюс проверка провайдера в реестре Роскомнадзора.
• Полный перечень API-эндпоинтов, включая старые версии и служебные. Ненужное закрыто, остальное под аутентификацией и мониторингом.
• Конфигурация контейнеров: процессы без прав root, ограниченный доступ к сокету Docker, обновление образов вместе с зависимостями.
• Защита от DDoS на уровне провайдера или CDN, проверенная до инцидента, а не во время.

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

Границы no-code и визуальных платформ

В обзоры под видом новых технологий веб-разработки регулярно попадают конструкторы и визуальные платформы, и часть задач они действительно закрывают. Лендинг или промо-страницу собирают за два дня вместо двух недель, акцию, калькулятор или новую продуктовую страницу тестируют без участия разработчиков. В российских банках и телекоме на no-code делают внутренние сервисы, HR-порталы и корпоративные чат-боты, так что речь не про игрушки для маркетинга.

Граница у no-code проходит там же, где у генерации кода. Производство артефактов дешевеет, дисциплина от этого не появляется, и как только на странице возникают роли, интеграция с учетными системами и персональные данные, проект возвращается к обычной разработке с ревью, тестами и понятным местом для бизнес-правил. Требование к размещению баз с персональными данными российских пользователей действует здесь в полном объеме, подробнее об этом в разделе про инфраструктуру.

Безопасность сгенерированного кода и рост техдолга

Компилируемый код и безопасный код – разные вещи, и разрыв между ними измерен. Veracode прогнала более сотни моделей через типовые задачи генерации: результат почти всегда собирается, но 45% задач заканчиваются фрагментом с уязвимостью из списка OWASP Top 10, а на защите от межсайтового скриптинга доля провалов доходит до 86%. Средний security pass rate держится около 55% и не растет вместе с общим качеством генерации (Veracode, 2025).

Фильтрация промптов эту проблему не решает: модель воспроизводит небезопасные шаблоны, распространенные в обучающих данных, и на выходе ревьюер видит аккуратный идиоматичный текст, который проходит тесты и не имеет внешних признаков ошибки.

Второй эффект спешки виден в структуре кодовой базы.

За 2024 год число блоков от пяти строк, дублирующих соседний код, выросло восьмикратно, и объем скопированного впервые превысил объем перемещенного (GitClear, 2025).

Разница между этими операциями принципиальна. Перемещение кода означает, что разработчик реорганизует систему, копирование означает, что он обходит ее устройство. Через год такой проект дороже поддерживать: одно исправление приходится вносить в шесть мест, а найти все шесть удается не всегда.

Последствия взлома тоже стали тяжелее. По данным Positive Technologies за 2025 год, на эксплуатацию уязвимостей приходится 40% успешных атак в мире и 43% среди атак на российские организации. Взлом веб-приложения перестал заканчиваться дефейсом главной страницы, все чаще он открывает доступ вглубь корпоративного периметра, вплоть до самого процесса сборки ПО.

Отдельный класс рисков приносят агентные сценарии на сайте, где ИИ читает пользовательский ввод и имеет доступ к данным или внешним вызовам. В Technology Radar это описано как смертельная триада: доступ к приватным данным, необработанный внешний контент и возможность отправить что-то наружу. Пока все три условия сходятся в одном компоненте, чат-бот работает как канал утечки, и защита состоит в том, чтобы разорвать любое из трех условий.

Скорость держат под контролем одним и тем же набором проверок, независимо от размера проекта:

• Статический анализ и проверка зависимостей в CI, с блокировкой сборки на критичных находках, а не с отчетом «на посмотреть».
• Контрактные тесты на интеграции, чтобы смена формата данных на стороне CRM или платежей падала на тестах, а не на клиенте.
• Mutation testing на критичных правилах, поскольку тесты, которые проходят при испорченной логике, дают ложное чувство защищенности.
• Изолированный запуск агентов, без доступа к продовым секретам, с ограниченным набором разрешенных действий и отдельными токенами для внешних ИИ-сервисов.
• Наблюдаемость и архитектурные правила в конвейере: логи, трейсы, алерты плюс проверка того, где может лежать бизнес-логика, а где нет.

Половина этого списка дает тот же результат, что и его отсутствие. Уязвимость и дубль появляются там, где быстрее всего пишется код, а смотрят обычно в другом месте.

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

ИИ-агент как второй пользователь сайта

У сайта появился второй пользователь. Он не смотрит на макет, не реагирует на анимацию и не читает заголовок первого экрана. Ему нужны разметка, документация и ответы API, чтобы сделать за человека выбор, сравнение или заказ.

Netlify ввела для этого термин Agent Experience, AX, в 2025 году и выпустила открытый фреймворк оценки AXIS. Логика простая: UX описывает удобство для человека, DX для разработчика, AX показывает, насколько продукт пригоден для использования агентом. Проверяется это на конкретных вопросах. Может ли агент зарегистрироваться и получить доступ без ручных шагов, находит ли машиночитаемое описание возможностей, понятны ли ошибки в ответах, есть ли документация в виде, который читается без рендеринга страницы.

Инфраструктурным ядром стал Model Context Protocol, открытый стандарт подключения агентов к данным и инструментам. В спецификации от 28 июля 2026 года его перевели на stateless-архитектуру, отказавшись от обязательной инициализации сессии, добавив маршрутизацию по заголовкам и кешируемые списки инструментов с указанием времени жизни (MCP, 2026). Интеграции для агентов после этого ведут себя как обычный веб, их можно кешировать, балансировать и разносить по регионам.

Рядом с протоколом живут соглашения, которые внедряются за день. Файл llms.txt дает языковым моделям карту смыслов сайта, файл agents.md держит инструкции для кодовых агентов внутри репозитория.

Роль документации от этого меняется сильнее всего.

К середине 2026 года 66% обращений к документации клиентов Mintlify создают не браузеры, а кодовые агенты (Mintlify, 2026).

Для сервиса с API это означает смену жанра: документация перестала быть страницей для чтения и стала интерфейсом. Если она отдается только после исполнения JavaScript и без структуры, агент уйдет к конкуренту с простым текстовым вариантом.

Экономическая сторона агентного веба выглядит жестче технологической. По данным Cloudflare Radar, соотношение обращений краулера к переходам живых пользователей измеряется сотнями к одному: у Anthropic около 870:1, у Perplexity около 858:1, причем за год оба показателя снизились. Cloudflare сама оговаривает, что часть переходов не видна, поскольку запросы из мобильных приложений не передают заголовок Referer. Направление от этого не меняется, контент забирают чаще, чем присылают за ним читателя.

Для российских проектов отсюда следует смена цели в оптимизации. То, что на рынке называют GEO или AEO, работает на той же базе, что и классическое SEO: структурированная разметка schema.org, честные заголовки, факты с цифрами в тексте, а не вокруг него. Разница в том, что попадать теперь нужно не только в позицию выдачи, но и в ответ, который формирует модель.

Вторая часть вывода касается денег. Трафик из ИИ-поиска может расти медленнее, чем падают переходы из классического, и страховкой в этом случае остаются прямые каналы: подписки, приложение, повторные покупки, узнаваемое имя. Сайт при этом работает источником фактов о продукте, и чем чище на нем данные о наличии, ценах и условиях доставки, тем корректнее агент их перескажет.

Что меняется в бюджете проекта

Ожидание «ИИ снизит смету» на практике не подтверждается. Экономия возникает на рутине, где она доходит до 20-40% времени разработчика, а до сроков релиза добирается в виде 5-10%, поскольку дальше работа упирается в ревью и тестирование (KPMG, 2026). Смета в итоге перераспределяется между этапами, а не сжимается.

Рынок при этом чувствует себя не так плохо, как звучит в разговорах.

В первом полугодии 2026 года о росте выручки к тому же периоду 2025-го сообщили чуть более половины агентств. Увеличить расходы планируют 47%, расширить штат рассчитывают 41%, при этом каждое пятое агентство готовится сокращать затраты на 30-70% (Workspace, выборка 1968 юрлиц, 2026).

Расслоение внутри рынка заметнее общей динамики. По оборотам за 2025 год наименьший рост показали дизайн и реклама, наибольший пришелся на PR и работу с маркетплейсами. Заказчики стали уходить от подрядчиков со слабыми компетенциями либо к более сильным, либо к более дешевым, и середина рынка от этого вымывается.

Отсюда складывается новая структура затрат, где деньги уходят из производства артефактов и приходят в их проверку и сопровождение.

Проверяют такую смету результатом, а не объемом работ. Заказчики уже спрашивают у подрядчика точки падения конверсии по данным аудита и предсказуемость отдачи от вложений, а не количество страниц и часов.

Оценки будущего у самих агентств сдержанно оптимистичные, но расходятся. Одни готовятся к стагнации и режут расходы на необязательное, другие исходят из того, что к середине 2027 года значительная часть производственных задач уйдет к ИИ-агентам, и вкладываются в переквалификацию команд вместо сокращений. Сходятся обе стратегии в одном: выигрывает тот, у кого выстроены процессы, поскольку генерация кода уравняла всех по скорости.

Перспективы веб-разработки: с чего начать перестройку процессов

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

Быстрее всего отдача от процессов, потому что переписывать здесь ничего не нужно:

• Снимите текущие значения четырех метрик DORA и добавьте к ним rework rate. Без базовой линии любой разговор об ускорении останется впечатлением.
• Заведите общие инструкции для агентов в репозитории и пересматривайте их вместе с кодом, иначе через полгода они начнут описывать проект, которого уже нет.
• Переведите ревью с чтения строк на системную проверку через автотесты, регрессионные прогоны и архитектурные правила в конвейере.
• Включите статический анализ и проверку зависимостей с блокировкой сборки, чтобы уязвимости из сгенерированного кода падали на конвейере, а не у клиента.

С платформой нужен фильтр, а не список желаний. Пройдите по фокус-областям Interop 2026 и сверьте их со статусами Baseline: Widely available закладывается в макеты и техзадания без оговорок, Newly available берется с прогрессивным улучшением. Проверьте заодно, какие метрики скорости вы отслеживаете, и если в отчетах остался FID, перенастройте на INP.

Самой недооцененной частью обычно оказываются данные, и начинать стоит с того, что уже влияет на продажи: корректность структурированной разметки, актуальность цен и наличия, честные условия доставки и возврата в машиночитаемом виде. Дальше идут технические слои для сервисов с API, простая текстовая версия документации и явные контракты на интеграции. Здесь же проверьте, как сайт отдается без исполнения JavaScript, поскольку агент, в отличие от человека, редко ждет рендеринга.

С легаси действует одно правило: не начинать с переписывания. Определите уровень запутанности, выберите стратегию из модели 7R и вынесите бизнес-правила туда, где их видно, оставив CMS контентным ядром.

Общая рамка у всего перечисленного одна. Произвести цифровой артефакт сегодня может кто угодно, а гарантировать, что он не сломает соседний, могут немногие. Скорость генерации стала базовой возможностью, преимуществом стала проверяемость: архитектурная ясность, контракты, тесты и метрики, по которым видно, стал ли продукт быстрее меняться. Все описанное выше, от статусов Baseline до подготовки данных для агентов, обслуживает именно эту способность.