Разработка сайта на WordPress: структура до дизайна, а не после

Как работаем

Что на руках

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

• 01
  Карта страниц и адресов
• 02
  Макеты и свёрстанные шаблоны
• 03
  Настроенная админка с инструкцией
• 04
  Технический срез при сдаче
• 05
  Доступы и документация по проекту на вашей стороне

Почему структура обсуждается до дизайна

Это самый недооценённый этап и единственный, который почти невозможно переделать дешево. Разговор занимает день, а определяет стоимость владения сайтом на годы.

• Какие разделы нужны. Не «как у конкурента», а под то, что вы продаёте и что люди ищут. Разделы, под которые нет ни спроса, ни контента, не создаются.
• Какие страницы внутри разделов и по какому признаку они делятся: по услугам, по аудиториям, по объектам. Один признак, а не три сразу, иначе страницы начинают дублировать друг друга.
• Какие адреса. Короткие, читаемые, с понятной вложенностью. Менять адрес работающей страницы — это переадресация, потеря части накопленного веса и риск ошибок, поэтому адреса решаются один раз.
• Как страницы связаны ссылками. Откуда человек попадает на услугу, куда уходит дальше, какие страницы поддерживают друг друга. Внутренние ссылки проектируются, а не расставляются «куда получилось».
• Что будет расти. Если через год появится сто страниц под товары или города, это видно из структуры сразу, и шаблоны готовятся под рост.

Результат этапа — карта страниц с адресами, которую вы видите и утверждаете до того, как нарисован первый макет. Дизайн потом рисуется под эту карту, а не наоборот.

Технические требования, которые мы закладываем в вёрстку

Это тот список, из-за несоблюдения которого к нам потом приходят с просьбой «починить SEO». Дешевле заложить сразу.

• Содержимое в ответе сервера. Текст, заголовки и ссылки приходят в исходном коде страницы, а не появляются после выполнения скриптов. Это проверяется на сдаче.
• Один заголовок первого уровня на страницу, дальше иерархия по смыслу, а не по размеру шрифта. Самая частая находка в сайтах с конструкторами — пять заголовков первого уровня на одной странице.
• Текст текстом. Цены, условия и характеристики не картинками и не в тяжёлых файлах: иначе их не видит ни поиск, ни человек с телефона.
• Сворачиваемые блоки — с содержимым в разметке, а не подгружаемым по клику. Иначе ответы на вопросы, ради которых блок и сделан, недоступны.
• Изображения с подписями, в современных форматах, с размерами в разметке — чтобы страница не прыгала при загрузке.
• Разметка для организации, товаров, вопросов и ответов — на этапе шаблона, одна и та же логика для всех страниц типа.
• Адаптив. Сначала телефон, потом компьютер: большая часть трафика мобильная, и «потом поправим» в этом месте не работает.
• Скорость. Проверяется на реальных страницах с реальными изображениями, а не на пустом шаблоне.

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

Редактируемость: чтобы сайт не умер через полгода

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

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

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

Если сайт заменяет существующий

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

• Опись старого сайта до начала. Полный список адресов, какие из них приносят трафик, какие в индексе. Это основа карты переадресаций.
• Карта переадресаций со старых адресов на новые, один к одному, а не всё на главную. Переадресация всего на главную — самая дорогая ошибка при переезде.
• Сохранение адресов, где это возможно. Если старый адрес читаемый и приносит трафик, правильнее оставить его, а не улучшать.
• Перенос контента с проверкой: тексты, изображения с подписями, страницы, которые приносят трафик, — ничего не теряется по дороге.
• Фиксация базовой линии перед переключением: позиции, трафик, индексация с датой. Без неё невозможно понять, была ли просадка.
• Наблюдение после переключения: ошибки в панелях вебмастера, индексация новых адресов, работа переадресаций.

Небольшая просадка в первые недели после переезда нормальна и восстанавливается. Ненормально — потеря, которая не восстанавливается, и почти всегда её причина в отсутствии нормальной карты переадресаций.

Набор плагинов: что ставим и чего избегаем

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

Что обычно действительно нужно:

• Один SEO-плагин для управления заголовками, описаниями и индексацией. Один, а не два.
• Кеширование — тот, что совместим с вашим хостингом, а не тот, что популярнее.
• Работа с изображениями: сжатие и современные форматы при загрузке.
• Формы — с проверкой полей и защитой от спама.
• Резервное копирование в отдельное хранилище.
• Поля и типы записей для повторяющихся сущностей: услуг, кейсов, сотрудников.

Чего избегаем:

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

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

Скорость закладывается при сборке, а не лечится потом

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

• Тема без лишнего. Готовая универсальная тема тянет код для десятков вариантов оформления, из которых вы используете один.
• Изображения на входе. Сжатие и современные форматы настраиваются так, чтобы работали для того, что загружает контент-менеджер, а не только для картинок из макета.
• Шрифты. Два начертания вместо шести и локальная раздача вместо подключения к сторонним сервисам.
• Скрипты по страницам. Код плагина формы не нужен на странице блога; подключение делается там, где он используется.
• Кеш с понятными правилами сброса, чтобы обновлённая цена появлялась сразу, а не через сутки.
• Проверка на реальных страницах с реальными изображениями и реальным объёмом текста, а не на пустом шаблоне.

Результат замера входит в технический срез при сдаче: вы видите цифры по основным типам страниц и знаете, с чем сайт уходит в работу.

Что входит в сдачу проекта

Сдача — это не «передали пароль от админки». Проект считается сданным, когда у вас на руках всё, что нужно для самостоятельной работы и для того, чтобы при желании сменить подрядчика без потерь.

• Доступы оформлены на вас: домен, хостинг, админка, панели вебмастера, аналитика. Не на нас с обещанием передать потом.
• Технический срез с результатами проверок: содержимое в ответе сервера, структура заголовков, скорость по типам страниц, настройки индексации, карта сайта.
• Карта страниц и адресов в том виде, в котором её утверждали, плюс карта переадресаций, если был перенос.
• Список плагинов с объяснением задачи каждого — чтобы через год не гадать, зачем это стоит.
• Схема резервного копирования: что копируется, куда, как часто и как разворачивается.
• Инструкция и обучение для вашей команды: как добавить страницу, услугу, новость, как заменить изображения.
• Исходники макетов и шрифтовые лицензии, если шрифты платные.

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

Из чего складывается срок

Срок разработки определяется не объёмом вёрстки, а скоростью решений и готовностью контента. Распределение, которое мы видим на практике:

• Структура — 3–5 дней нашей работы плюс время на ваше согласование. Это самый важный этап, и торопить его невыгодно.
• Дизайн — зависит от числа уникальных шаблонов, а не от числа страниц: двадцать однотипных услуг верстаются одним шаблоном.
• Сборка и настройка админки — предсказуемая часть, укладывается в план.
• Контент — главная переменная. Ожидание текстов, фотографий и прайса растягивает проекты чаще, чем что-либо ещё. Если контент готовите вы, срок стоит закладывать с запасом.
• Перенос и переадресации — отдельная задача, если сайт заменяет существующий.

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

Вопросы