На Битриксе можно создать файл /about/index.php — и сразу получить страницу /about/. Файл лежит в проекте, попадает в Git и разворачивается вместе с остальным кодом.
Попробуйте повторить этот шаг в стандартном WordPress или Laravel. Файл page-about.php в теме WordPress сам по себе не создаст страницу /about/. Blade-файл about.blade.php в Laravel тоже не откроет новый URL, пока разработчик не объявит маршрут.
Для корпоративного сайта, где структуру страниц проектирует разработчик, Битрикс действительно удобнее из коробки: адрес страницы напрямую связан с файлом. Но это преимущество не уникально. Такой же процесс можно построить на Laravel и WordPress — на открытом ПО, с хранением архитектуры в Git и без критической зависимости от конкретного подрядчика.
Вопрос не в том, какая платформа «лучше вообще». Вопрос в том, что команда получает сразу, что должна настроить и кому принадлежит устройство проекта.
Почему Битрикс удобнее для сайта из кодовых страниц
Страница сразу становится URL
У Битрикса есть файловая структура публичных страниц и разделов:
/about/index.php → /about/
/services/index.php → /services/
/services/audit/index.php → /services/audit/
В PHP-файле разработчик подключает шаблон сайта, пишет разметку и при необходимости вызывает компоненты CMS. Для простой физической страницы не нужна отдельная запись в таблице маршрутов: файл в публичной части уже связан с адресом. Структура публичных страниц Битрикса
Это даёт понятный рабочий процесс:
- разработчик создаёт файл;
- файл проходит ревью;
- изменение попадает в Git;
- страница разворачивается вместе с проектом.
Структуру индивидуальных страниц можно увидеть, просто открыв репозиторий. Не нужно отдельно сверять файлы шаблонов, записи в базе и таблицу маршрутов.
Вложенность проекта совпадает со структурой сайта
Адрес /services/audit/ естественно следует из каталога /services/audit/. Это удобно для корпоративных сайтов, лендингов, разделов услуг и отраслевых страниц: архитектура URL остаётся видимой в файловой системе.
Такую модель можно назвать файловым пейдж-роутером: расположение файла определяет, какой код отвечает за конкретный URL.
CMS и код находятся рядом
Битрикс совмещает два подхода:
- разработчик определяет страницу и её структуру в коде;
- редактор управляет данными через CMS;
- компоненты выводят каталог, новости, формы и другой изменяемый контент;
- общий шаблон обеспечивает шапку, подвал и единое оформление.
Для проекта, где страницы создаёт команда разработки, а редакторы меняют содержимое в предусмотренных местах, это практичная модель.
Где преимущество заканчивается
Физическая страница — не то же самое, что динамический маршрут. Товару с адресом /catalog/iphone-15/ обычно не соответствует собственная папка с index.php. Такие запросы обрабатывают настройки ЧПУ компонентов, urlrewrite.php или роутинг Битрикса. Битрикс: обработка адресов
Поэтому преимущество Битрикса точнее сформулировать так:
Битрикс из коробки даёт прямую связь между файлами и простыми физическими страницами сайта.
Это сильная сторона для определённого типа проектов, но не универсальное превосходство над другими платформами.
Почему WordPress и Laravel по умолчанию работают иначе
WordPress: источник страниц — база данных
В WordPress редактор создаёт страницу в админке, назначает ей адрес и публикует. Файлы темы определяют, как найденная страница будет выглядеть.
Например, page-about.php может быть специальным шаблоном для страницы «О компании». Но один только файл не добавляет страницу /about/: сначала WordPress должен найти соответствующую запись в базе, а затем выбрать шаблон по своей иерархии. Иерархия шаблонов WordPress
Это отличная модель для редакционного сайта, где страницы создают контент-менеджеры. Но если источником структуры должен быть Git, возникают два связанных объекта:
- запись в базе сообщает, что страница существует;
- файл темы содержит код её отображения.
Laravel: URL задаётся маршрутом
В стандартном Laravel разработчик явно связывает адрес с обработчиком или представлением:
Route::view('/about', 'about');
Затем создаётся Blade-представление. Новый файл сам по себе URL не создаёт. Документация Laravel по маршрутизации
Явные маршруты удобны для приложений со сложной логикой: сразу видно, какие запросы принимает система и какие правила к ним применяются. Но для сайта из десятков индивидуальных страниц команда повторяет два действия: создаёт представление и регистрирует адрес.
И WordPress, и Laravel могут работать как Битрикс. Просто файловая маршрутизация не является их стандартной исходной моделью.
Как получить то же самое на Laravel
Laravel Folio: страницы как Blade-файлы
Официальный пакет Laravel Folio добавляет файловый пейдж-роутер. Он сканирует директорию страниц и строит маршруты по именам файлов:
resources/views/pages/about.blade.php
→ /about
resources/views/pages/services/audit.blade.php
→ /services/audit
resources/views/pages/blog/[slug].blade.php
→ /blog/{slug}
После подключения Folio разработчик создаёт файл и получает URL без отдельной строки в routes/web.php. Вложенные директории становятся вложенными маршрутами, а динамические сегменты описываются именами файлов.
В результате Laravel получает тот же базовый сценарий, за который удобен Битрикс:
- страницы определяются кодом;
- структура адресов видна в репозитории;
- изменения проходят через Git и code review;
- проект можно развернуть заново без ручного создания каждой страницы в админке.
При этом Laravel остаётся полноценным фреймворком: для сложных участков можно использовать обычные маршруты, контроллеры, middleware и модели.
Как добавить CMS-возможности
Folio решает маршрутизацию, но не превращает Laravel в готовую CMS. Управляемый контент можно подключить несколькими способами:
- хранить небольшие объёмы контента в Markdown или YAML;
- использовать административную панель;
- подключить headless CMS;
- создать собственные модели и формы редактирования только для нужных сущностей.
Это требует начальной архитектурной работы, зато команда не обязана принимать всю модель монолитной CMS. Можно оставить страницы в коде, а в базу вынести только действительно изменяемые данные.
Как получить то же самое на WordPress
Acorn: Laravel-компоненты внутри WordPress
Acorn от Roots добавляет в WordPress Blade, контейнер зависимостей, маршрутизацию и другие привычные возможности Laravel.
В базовом варианте виртуальную страницу можно объявить в коде:
Route::view('/about/', 'pages.about');
Такой маршрут создаёт адрес без обычной записи «О компании» в базе WordPress. Маршрутизация Acorn
Чтобы приблизиться к модели Битрикса или Folio, поверх Acorn можно добавить соглашение: сканировать директорию Blade-страниц и автоматически регистрировать маршруты по именам файлов.
resources/views/pages/about.blade.php
→ /about/
resources/views/pages/services/audit.blade.php
→ /services/audit/
Таким образом, WordPress продолжает управлять публикациями, пользователями, медиа и другими CMS-сущностями, а индивидуальные страницы определяются кодом.
Что нужно предусмотреть для виртуальных страниц
WordPress не воспринимает виртуальный маршрут как обычную запись из таблицы wp_posts. Поэтому архитектура должна явно решать:
- title и meta description;
- canonical URL;
- Open Graph и другие метаданные;
- добавление страниц в sitemap;
- хлебные крошки и навигацию;
- права доступа и предпросмотр;
- кеширование.
Это не причина отказываться от подхода. Это список требований, которые нельзя оставлять в неявных договорённостях с разработчиком. Их лучше оформить как пакет, модуль и документацию проекта. Acorn отдельно описывает работу SEO с маршрутами. Acorn: SEO виртуальных страниц
При чём здесь Next.js и Astro
Next.js и Astro показывают, как файловый пейдж-роутер выглядит, когда он является основой фреймворка:
Next.js: app/about/page.tsx → /about
Astro: src/pages/about.astro → /about
Next.js: app/blog/[slug]/page.tsx → /blog/:slug
Astro: src/pages/blog/[slug].astro → /blog/:slug
Статические страницы, вложенность и динамические сегменты описываются одним набором соглашений. Структура URL читается по структуре проекта. Next.js · Astro
Битрикс даёт похожий опыт для физических PHP-страниц. Laravel получает полноценную файловую маршрутизацию через Folio. WordPress может совместить CMS-модель с кодовыми страницами через Acorn и собственный слой регистрации маршрутов.
Файловый роутер при этом не равен JAMstack. Роутер определяет, какой код отвечает за URL. JAMstack и режимы рендеринга определяют, когда создаётся HTML и как он доставляется пользователю. Astro может заранее собирать страницы или рендерить выбранные маршруты на сервере; Next.js поддерживает несколько стратегий рендеринга; Битрикс обычно выполняет PHP при запросе. Astro: режимы рендеринга · JAMstack
FOSS и независимость от подрядчика
WordPress и Laravel дают возможность построить решение на открытом программном обеспечении. Но FOSS сам по себе не устраняет зависимость от исполнителя. Проект может быть открытым по лицензии и при этом оставаться непонятным без автора.
Независимость появляется, когда результатом работы является не только сайт, но и воспроизводимая система.
Что должно принадлежать заказчику
- репозиторий со всем прикладным кодом;
- история Git и доступы владельца;
- описание архитектуры и файлового роутинга;
- зафиксированные версии зависимостей;
- инструкция локального запуска;
- автоматизированное развёртывание;
- миграции и схема данных;
- резервные копии и процедура восстановления;
- список внешних сервисов и владельцев аккаунтов;
- документация по обновлению и типовым операциям.
Что нельзя оставлять только «в голове» подрядчика
- ручную регистрацию маршрутов после деплоя;
- создание обязательных страниц непосредственно в production-базе;
- неизвестные правки ядра или сторонних плагинов;
- секреты в личных аккаунтах разработчика;
- сборку, которую можно выполнить только на одном компьютере;
- недокументированные cron-задачи, вебхуки и DNS-настройки;
- критические плагины или модули без исходного кода и права сопровождения.
Практический критерий независимости
Перед передачей проекта другой разработчик должен суметь:
- получить репозиторий;
- запустить проект по инструкции;
- создать новую страницу добавлением файла;
- выполнить тесты и сборку;
- развернуть изменение;
- восстановить сайт из резервной копии.
Если это возможно без звонка прежнему подрядчику, архитектура действительно переносима. Если нет — проблема не только в выборе CMS или фреймворка.
Что выбрать на практике
| Главный процесс в проекте | Подходящий вариант |
|---|---|
| Нужна готовая CMS, а разработчик создаёт индивидуальные страницы файлами | Битрикс |
| Редакторы самостоятельно создают большинство страниц и публикаций | WordPress |
| Нужна сложная логика приложения и явный контроль маршрутов | Laravel |
| Нужен Laravel, где файлы страниц автоматически становятся URL | Laravel + Folio |
| Нужен WordPress, но часть страниц должна определяться кодом | WordPress + Acorn + файловая регистрация маршрутов |
| Файловая маршрутизация должна быть основой современного фронтенда | Astro или Next.js |
| Приоритет — FOSS и переносимость между исполнителями | Laravel или WordPress с воспроизводимой архитектурой и документацией |
Вывод
Битрикс лучше стандартного WordPress и Laravel в одном конкретном сценарии: разработчик добавляет физическую страницу как файл и сразу получает соответствующий URL. Для корпоративного сайта из индивидуальных кодовых страниц это простая и удобная модель, доступная из коробки.
Но сама идея не принадлежит Битриксу. Laravel Folio реализует файловую маршрутизацию в открытой экосистеме Laravel. WordPress можно дополнить Acorn и собственным файловым роутером, сохранив CMS-возможности и определяя специальные страницы в коде.
Поэтому выбор можно сформулировать так:
- Битрикс — готовое соглашение и быстрый старт про магазины в РФ;
- Laravel + Folio — тот же принцип на FOSS с большей архитектурной свободой;
- WordPress + Acorn — CMS для редакторов плюс кодовые страницы, но с дополнительной настройкой;
- Astro или Next.js — файловые маршруты как основа фронтенд-архитектуры.
А независимость от подрядчика определяется не логотипом платформы, а тем, находятся ли код, маршруты, конфигурация, развёртывание и документация под контролем владельца проекта.
