На чем сделан сайт: анализ

Вопрос «на чём сделан сайт» звучит по двум поводам: либо вы оцениваете свой сайт перед доработкой или переносом, либо смотрите на конкурента и хотите понять, чем он собран и почему у него быстрее грузится каталог. В обоих случаях цель одна — получить план работ, а не выиграть спор о фреймворках. Ниже — как определять стек по открытым признакам, какие выводы из этого корректно делать и где детекторы ошибаются.

Что вообще определяют

Смежно: веб-разработка с нуля, конструкторы сайтов, WordPress для блога и магазина, раздел о сайтах.

Метод первый: исходный код страницы

Самый честный источник — то, что сервер отдаёт браузеру. Открываете исходный код страницы (view-source) или панель разработчика и ищете характерные маркеры.

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

Метод второй: HTTP-заголовки ответа

Заголовки видны на вкладке Network в панели разработчика (или запросом `curl -I`). Они рассказывают о сервере и инфраструктуре больше, чем разметка.

• - `Server` — веб-сервер или прокси, иногда с версией;
• - `X-Powered-By` — язык или платформа, если администратор не убрал заголовок;
• - `Set-Cookie` — имена сессионных и служебных cookie почти всегда выдают платформу;
• - `Link` с ссылкой на API — типичный признак WordPress;
• - заголовки кеша и трассировки запроса (`X-Cache`, `Age`, `Via`, идентификатор узла) — перед сайтом стоит CDN;
• - `Content-Security-Policy` — перечисляет домены, с которых грузятся скрипты: это готовый список сторонних сервисов;
• - `Location` при первом запросе — как настроены редиректы http→https и www.

Отдельно посмотрите `robots.txt` и карту сайта. Имя файла карты и её структура часто указывают и на CMS, и на SEO-плагин. Там же видно, что владелец сам считает служебным: закрытые разделы, параметры, страницы фильтров.

Метод третий: детекторы стека

Расширения и сервисы класса Wappalyzer работают по базе отпечатков: сочетание путей к файлам, имён cookie, глобальных JS-переменных, заголовков и текстовых маркеров сопоставляется с известными технологиями. Это быстрый способ получить гипотезу за один клик.

Где такие детекторы ошибаются:

• - CDN и прокси перед сайтом подменяют заголовки, и «технология» определяется по инфраструктуре, а не по приложению;
• - отпечаток остаётся после миграции: старые файлы темы лежат на сервере, хотя сайт уже переехал;
• - кастомная сборка на популярной библиотеке определяется как «библиотека», хотя половина логики своя;
• - SPA дорисовывает часть скриптов после загрузки, и статический анализ их не видит;
• - версии платформ, которые показывают такие инструменты, часто устаревшие или угаданные.

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

Метод четвёртый: домен и почта

Публичные данные о делегировании дают контур инфраструктуры: NS-записи показывают, где управляется DNS, A-запись или CNAME — где физически живёт сайт (свой сервер, облако, платформа-хостинг), MX-записи — какой почтовый сервис используется. Для переноса это критично: часто «сложность миграции» сводится к тому, что домен зарегистрирован на бывшего подрядчика, а доступов к панели DNS ни у кого нет.

Анализ конкурента: что смотреть и где граница

Корректный конкурентный анализ работает только с тем, что сайт сам отдаёт браузеру: разметка, заголовки ответа, публичные файлы, скорость, структура разделов. Этого достаточно для выводов о наборе технологий и о том, как устроен путь клиента.

Чего делать нельзя: подбирать пароли, сканировать порты, искать уязвимости, выгружать базы, обходить ограничения доступа и игнорировать запреты в `robots.txt` при массовом сборе данных. Изучение чужих решений — нормальная практика, попытка проникнуть внутрь — нет.

Что полезно выписать по конкуренту:

1. 1. Платформа и характер фронтенда (серверный рендер или клиентский).
2. 2. Наличие CDN и скорость первого экрана на мобильном.
3. 3. Набор сторонних скриптов: аналитика, чат, квиз, коллбек.
4. 4. Способ приёма заявок и количество полей в форме.
5. 5. Структура разделов, наличие блога и FAQ на коммерческих страницах.

Скорость и Core Web Vitals

Технология сама по себе не делает сайт быстрым или медленным — делают решения внутри. Поэтому в анализ всегда входит замер. Опубликованные Google пороги «хорошо»: LCP до 2,5 с, INP до 200 мс, CLS до 0,1. Мерить нужно на мобильном профиле и на разных типах страниц — главной, карточке и статье.

Фраза «сайт медленный, потому что он на этой CMS» почти всегда неверна. Сначала замер и разбор по элементам, потом выводы. Технические ориентиры — в статье про SEO-оптимизацию.

Когда оставлять платформу, а когда переносить

Оставить и доработать, если:

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

Планировать перенос, если:

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

Перенос всегда начинается с карты URL и списка редиректов, иначе накопленный трафик остаётся на старых адресах. Услуга: сайты, диагностика: SEO-аудит.

Порядок осмотра без «магии»

Открыть сайт на телефоне и десктопе
 → исходный код: маркеры CMS и сборки
 → заголовки ответа и cookie
 → robots.txt и карта сайта
 → DNS и MX по домену
 → пройти форму заявки до конца
 → замер Core Web Vitals на мобильном
 → список сторонних скриптов и виджетов
 → зафиксировать доступы и владельцев
 → решение: доработать / перенести / оставить

Мини-отчёт после анализа

1. 1. Стек и хостинг — с пометкой, что подтверждено, а что гипотеза.
2. 2. Критичные риски: доступы, безопасность, приём заявок, бэкап.
3. 3. Что чинится на месте за один-два спринта.
4. 4. Что потребует переноса и сколько это стоит по сравнению с доработкой.
5. 5. Рекомендованный следующий шаг и ответственный за него.

Как мы работаем по России

Анализ стека — полностью удалённая работа: Москва, Санкт-Петербург, Екатеринбург, Новосибирск, Казань, Ростов-на-Дону или небольшой город — разницы нет. Нужны URL, цели и, если речь о вашем сайте, доступы к хостингу, домену и админке. Разные часовые пояса закрываются письменным протоколом и фиксированным окном ответа. Обсудить задачу: контакты, ориентиры по стоимости — цены.

Частые ошибки

• - начинать с редизайна, не разобравшись со стеком и доступами;
• - обещать «перенесём за день» без инвентаризации страниц и редиректов;
• - удалять плагины и модули пачкой на живом сайте без бэкапа;
• - доверять одному скриншоту детектора вместо проверки исходного кода;
• - путать «сайт медленный» и «хостинг плохой» без замеров;
• - копировать решение конкурента, не понимая, зачем оно там появилось.

Частые вопросы

Как точно узнать CMS чужого сайта?

Абсолютной точности извне не бывает. Совпадение трёх независимых признаков — путей в HTML, имён cookie и структуры карты сайта — даёт надёжную гипотезу. Точный ответ есть только у владельца доступов.

Детекторы стека показывают разное. Кому верить?

Тому, что подтверждается исходным кодом и заголовками. Разные базы отпечатков обновляются по-разному, а CDN перед сайтом легко сбивает оба инструмента.

Можно ли определить стек, если сайт полностью на JavaScript?

Частично. Помогают имена файлов сборки, объект с начальным состоянием в разметке и запросы к API на вкладке Network. Серверную часть при этом обычно видно только по косвенным признакам.

Нужно ли всегда уходить с конструктора?

Нет. Часто выигрыш даёт не смена платформы, а структура, скорость и контент. Сравнение вариантов — в статьях про бесплатный конструктор и Tilda.

С чего начать, если доступов к своему сайту нет?

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

Насколько глубоко стоит изучать конкурента?

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

Что сделать на этой неделе

1. 1. Пройти порядок осмотра по своему сайту и записать результат в таблицу.
2. 2. Отметить, что подтверждено фактами, а что осталось гипотезой.
3. 3. Замерить Core Web Vitals на трёх типах страниц на мобильном профиле.
4. 4. Проверить, куда уходят заявки, и отправить тестовую форму.
5. 5. Принять решение — доработка или перенос — и зафиксировать срок.

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