Вопросы и ответы

Разработка сайта стоит от 49 000 ₽. Итоговая цена зависит от типа сайта, объёма функционала и от того, делается проект на готовом решении или индивидуально.

Ориентиры по стоимости, от которых я отталкиваюсь:

• Сайт на готовом решении (1С-Битрикс или WordPress) — самый быстрый и экономичный вариант: берётся проверенный шаблон, настраивается под задачи, наполняется контентом.
• Индивидуальная разработка — дороже и дольше, но структура, дизайн и логика делаются под конкретный бизнес.
• Доработка действующего сайта — считается по времени, от 1 700 ₽ за час.

Точную цифру я называю после того, как разберу задачу: какие нужны разделы, интеграции, обмены с 1С или CRM, есть ли готовый дизайн и контент. Оценка бесплатная — опишите задачу, и я подготовлю расчёт с составом работ и сроками.

Час работы стоит от 1 700 ₽. По часам считаются доработки сайтов, интеграции, обмены с 1С и CRM, парсинг товаров и цен, наполнение и техническая поддержка.

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

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

Доработка сайта на 1С-Битрикс, WordPress или PHP считается по времени — от 1 700 ₽ за час. Небольшая правка занимает 1–2 часа, крупная функция — несколько дней.

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

Типичные задачи по доработке:

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

Я работаю и с сайтами, которые делал не я, — в том числе без документации.

Поисковое продвижение стоит от 40 000 ₽, технический SEO-аудит сайта — от 40 000 ₽.

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

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

Возможны оба варианта: понятные задачи с чёткими границами я оцениваю фиксированной суммой, а развитие и поддержку считаю по часам — от 1 700 ₽/час.

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

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

В любом случае стоимость и сроки я обозначаю до начала работ.

Сайт на готовом решении обычно запускается за 2–4 недели, индивидуальная разработка занимает от 1,5–3 месяцев, отдельная доработка — от нескольких часов до нескольких дней.

На сроки сильнее всего влияют три вещи: объём функционала, готовность контента и скорость обратной связи со стороны заказчика. Часто проект ждёт не разработку, а тексты, фотографии и данные о товарах.

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

Работа начинается с предоплаты, крупные проекты делятся на этапы с оплатой по каждому этапу. Работаю как индивидуальный предприниматель (ИНН 502481206802), с юрлицами — по договору и со всеми закрывающими документами.

Схема оплаты зависит от размера задачи:

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

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

Да. Я индивидуальный предприниматель (ИНН 502481206802), работаю с юридическими лицами по договору, с оплатой по счёту и закрывающими документами.

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

С частными заказчиками работаю проще — по согласованной переписке и оценке, без лишней бюрократии, если она не нужна.

Поддержка — это исправление ошибок, обновления CMS и плагинов, правки контента и вёрстки, доработка функционала и контроль работоспособности сайта. Считается по времени, от 1 700 ₽/час.

Что обычно входит в поддержку:

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

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

Да, первичный разбор задачи и оценка стоимости и сроков бесплатны. Платной становится только сама работа после согласования.

Опишите задачу в свободной форме — что есть сейчас и что хочется получить. Я посмотрю сайт, задам уточняющие вопросы и скажу, что технически возможно, сколько это займёт и во сколько обойдётся.

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

Основные работы я выполняю сам как fullstack-разработчик — и frontend, и backend. При необходимости подключаю проверенных дизайнеров и верстальщиков, но ответственность за результат остаётся на мне.

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

Fullstack-подход важен там, где сайт должен не просто выглядеть аккуратно, а стабильно работать: принимать заявки, обмениваться данными с 1С и CRM, выдерживать нагрузку и развиваться дальше.

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

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

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

Да, работаю удалённо со всей Россией. Общение идёт по телефону, почте и в мессенджерах — Telegram и MAX.

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

Связаться со мной можно по телефону +7 915 016-99-88, по почте aleksey@chugunov.pro или в Telegram — отвечаю в рабочее время в тот же день.

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

Порядок работы простой и не меняется от проекта к проекту:

1. Разбор задачи — что есть сейчас и какой нужен результат.
2. Оценка и план работ — состав работ, стоимость, сроки.
3. Разработка и доработка — с промежуточными результатами.
4. Интеграции и обмены — 1С, CRM, оплаты, доставки, внешние сервисы.
5. Проверка и запуск — тестирование и вывод в работу.
6. Поддержка и развитие — после запуска остаюсь на связи.

Контакты: +7 915 016-99-88, aleksey@chugunov.pro, Telegram.

Создание и разработка сайтов, интернет-магазины на Битрикс и WordPress, доработка и поддержка, перенос и восстановление сайтов, лечение от вирусов, ускорение, SEO-аудит и продвижение, парсинг товаров и цен, наполнение, доработка и интеграция с Битрикс24.

Основные направления и цены «от»:

• Создание сайта на готовом решении — от 49 000 ₽, запуск за 2–4 недели.
• Индивидуальная разработка сайтов — от 1 700 ₽/час.
• Интернет-магазин на 1С-Битрикс — от 90 000 ₽, с обменом с 1С.
• Интернет-магазин на WordPress — от 60 000 ₽, на WooCommerce.
• Доработка сайтов на Битрикс и WordPress — от 1 700 ₽/час.
• Доработка и интеграция с Битрикс24 — от 1 700 ₽/час.
• Перенос сайта на другой хостинг или домен — от 9 000 ₽, перенос на Битрикс — от 30 000 ₽.
• Восстановление сайта и лечение от вирусов — от 1 700 ₽/час.
• Ускорение сайта — от 15 000 ₽, с ориентиром на Core Web Vitals.
• Технический SEO-аудит и поисковое продвижение — от 40 000 ₽.
• Парсинг товаров и цен, наполнение сайта — от 1 700 ₽/час.

Полное описание каждой услуги с составом работ — в разделе «Услуги». Если нужной задачи в списке нет, напишите: чаще всего она решается в рамках доработки.

Интернет-магазин на WordPress с WooCommerce стоит от 60 000 ₽, на 1С-Битрикс — от 90 000 ₽. Разница в цене объясняется лицензией и более широкими торговыми возможностями Битрикс: каталог, склады, скидки и обмен с 1С работают в базовой системе.

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

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

На итоговую цену влияют:

• размер каталога и наличие торговых предложений (цвет, размер, объём);
• обмен с 1С: по одному складу или по нескольким, сколько типов цен;
• число способов оплаты и служб доставки с расчётом стоимости;
• личный кабинет, программы лояльности, скидки и промокоды;
• откуда берётся контент — выгрузка из 1С, прайс поставщика или ручное наполнение.

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

Менять хостинг стоит при медленной работе сервера, регулярных сбоях, нехватке ресурсов для обменов и импорта, устаревшей версии PHP и отсутствии нормальных резервных копий. Перенос стоит от 9 000 ₽.

Поводы для переезда, которые встречаются чаще всего:

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

Что входит в перенос:

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

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

При смене домена дополнительно настраиваются 301-редиректы со старых адресов, чтобы не потерять позиции и накопленные ссылки.

Из замеров, поиска причин и точечных исправлений: тяжёлые запросы к базе, кеширование, вес изображений, блокирующие скрипты, время ответа сервера. Услуга стоит от 15 000 ₽, ориентир — показатели Core Web Vitals.

Порядок работ:

1. замеры скорости и показателей Core Web Vitals на ключевых типах страниц;
2. поиск причин: запросы к базе, кеширование, вес изображений, блокирующие скрипты, время ответа сервера;
3. исправления по приоритету — сначала то, что даёт наибольший эффект;
4. повторные замеры и проверка, что заявки, корзина и оформление заказа работают как раньше.

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

Если причина в хостинге — скажу об этом прямо: на слабом тарифе оптимизация кода упирается в потолок.

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

На что обратить внимание:

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

Лечение сайта считается по времени, от 1 700 ₽/час, и работает на любой CMS и на самописных сайтах. Важно не просто вычистить код, а найти точку входа — иначе заражение вернётся.

Ничего не переустанавливать и не «чинить» самостоятельно: каждое действие может затереть то, что ещё можно спасти. Первым делом нужно зафиксировать текущее состояние и проверить все возможные источники копий.

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

Что обычно удаётся использовать для восстановления:

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

Восстановление считается по времени, от 1 700 ₽/час. Напишите — посмотрю, что осталось, и скажу, насколько полно сайт получится вернуть.

Парсинг — это автоматический сбор данных с сайтов: карточек товаров, характеристик, изображений и цен. Используется для наполнения каталога, обновления цен от поставщиков и мониторинга конкурентов. Стоимость — от 1 700 ₽/час, разово или по расписанию.

Типичные сценарии:

• Наполнение каталога — перенос товаров с сайта поставщика или со старого сайта, когда выгрузки нет.
• Обновление цен и остатков — регулярный сбор с сайтов поставщиков и загрузка в каталог.
• Мониторинг цен — отслеживание изменений у конкурентов с отчётом в таблице.
• Разовый сбор данных — для аналитики или переноса на другую платформу.

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

Работаю с публично доступными данными и учитываю ограничения сайта-источника: частоту запросов, robots.txt и условия использования. Если данные закрыты авторизацией или лицензией, я об этом сразу говорю.

Наполнение стоит от 1 700 ₽/час. Тексты и описания готовятся с помощью ИИ, но обязательно проходят редактуру: факты, цены, характеристики и формулировки проверяются вручную.

Что входит в наполнение:

• перенос и вычитка текстов, вёрстка страниц в редакторе;
• подготовка изображений: обрезка, сжатие, alt-описания;
• заполнение карточек товаров, характеристик и категорий;
• заголовки, описания и микроразметка для поисковых систем;
• внутренняя перелинковка между разделами.

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

Поэтому правило простое: ИИ готовит черновик, человек проверяет и правит. Так наполнение обходится дешевле ручного, но остаётся достоверным.

Да. Кроме 1С-Битрикс и WordPress я работаю с самописными сайтами на PHP и с сайтами на других CMS — дорабатываю, восстанавливаю, лечу от вирусов и переношу на другой хостинг.

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

Отдельный вопрос — стоит ли оставаться на самописном решении. Если сайт стабильно работает и его развивают редко — да. Если каждая правка требует программиста, а найти его сложно, разумнее перейти на WordPress или Битрикс. Я скажу об этом честно, а не буду продавать переезд ради переезда.

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

Возможные варианты:

• Готовое решение — дизайн уже есть, я настраиваю его под ваш бренд: логотип, цвета, шрифты, состав и порядок блоков, изображения.
• Ваш макет — если дизайн уже нарисован, я его верстаю и подключаю к CMS.
• Индивидуальный дизайн — подключаю дизайнера, согласовываем макеты, дальше верстаю и программирую сам.

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

Для доработки нужны доступы к сайту, хостингу и панели управления доменом. Для нового сайта — описание задачи, примеры нравящихся сайтов, логотип, тексты и фотографии либо согласие, что контент готовлю я.

Для доработки существующего сайта:

• доступ в административную часть сайта;
• доступ к хостингу — панель управления, FTP/SSH, база данных;
• доступ к домену, если работы затрагивают почту или переезд;
• контакт того, кто вёл сайт раньше, — если такой есть.

Для нового сайта дополнительно:

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

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

Домен и хостинг лучше оформлять на себя — так они останутся вашими при смене подрядчика. С выбором тарифа и настройкой я помогаю, а при необходимости беру регистрацию и настройку на себя.

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

Что я делаю со своей стороны:

• подбираю хостинг под задачу — Битрикс и большой каталог требуют больше ресурсов, чем сайт-визитка;
• настраиваю окружение: версию PHP, лимиты, cron, SSL-сертификат;
• настраиваю почту на домене, чтобы письма с сайта доходили и не попадали в спам;
• подключаю резервное копирование.

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

На обращения отвечаю в рабочее время в тот же день. Аварийные ситуации — сайт не открывается, не приходят заявки, заражение — беру в работу вне очереди.

Приоритеты у меня расставлены так:

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

Связаться можно по телефону +7 915 016-99-88, по почте aleksey@chugunov.pro, в Telegram или MAX. Для срочных ситуаций надёжнее звонок: сообщение может остаться незамеченным до конца дня.

Готовый сайт — это проверенное решение на 1С-Битрикс или WordPress, которое настраивается под ваш бизнес. Это дешевле и быстрее индивидуальной разработки: запуск занимает недели, а не месяцы.

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

Готовое решение стоит выбирать, когда задача типовая — корпоративный сайт, интернет-магазин, сайт клиники, автосервиса, строительной компании. Индивидуальная разработка нужна, когда логика проекта нестандартная и под неё нет подходящего шаблона.

В каталоге на сайте собраны готовые решения на 1С-Битрикс и на WordPress с описанием и ценами — можно посмотреть и выбрать подходящее.

В каталоге 483 готовых решения на 1С-Битрикс и 240 готовых сайтов на WordPress и Tilda. Тематики — от корпоративных сайтов и интернет-магазинов до строительства, медицины, автоуслуг, производства и общепита.

Готовые решения на 1С-Битрикс сгруппированы по тематикам: корпоративный сайт, каталог товаров и услуг, landing page, универсальные шаблоны, продукты питания, строительство и ремонт, одежда и обувь, бытовая техника, подарки, B2B, спорт и туризм, авто, красота и здоровье, детские товары, мебель и другие.

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

Форматы тоже разные: сайт-визитка, лендинг, корпоративный сайт, каталог, интернет-магазин. Если подходящего варианта не нашли — напишите, подберу под задачу.

Готовый сайт на WordPress стоит 49 000–60 000 ₽ и запускается за 1–3 дня. В цену входит установка на ваш хостинг, настройка под бренд, замена изображений и текстов и наполнение в рамках шаблона.

Что входит в цену:

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

У каждого сайта в каталоге есть демо — его можно открыть и посмотреть, как всё работает, до заказа.

Отдельно оплачиваются задачи за пределами шаблона: новые типы страниц, нестандартный функционал, интеграции с 1С и CRM, большой объём наполнения.

Готовые решения на 1С-Битрикс стоят от 4 900 до 109 900 ₽ в зависимости от разработчика и функционала. Это цена самого шаблона: лицензия Битрикс, установка, настройка и наполнение оплачиваются отдельно.

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

Из чего складывается итоговый бюджет проекта на готовом решении:

• стоимость самого решения из каталога;
• лицензия 1С-Битрикс подходящей редакции — покупается отдельно;
• хостинг, домен и SSL-сертификат;
• работы по установке и настройке под ваш бизнес — от 49 000 ₽;
• наполнение контентом и каталогом, если оно нужно.

Я называю полную сумму сразу, со всеми составляющими, чтобы не было сюрпризов после запуска.

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

Это ключевое отличие от готовых сайтов на WordPress, где настройка и наполнение уже включены в стоимость.

Входит в цену решения: шаблон с демо-данными, установленный и работающий на вашем хостинге.

Оплачивается отдельно:

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

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

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

По каким критериям я помогаю выбирать:

• Структура под задачу — есть ли в решении те разделы, которые нужны: каталог, услуги, проекты, отзывы, расчёт стоимости, онлайн-запись.
• Тип каталога — простой список услуг или полноценный магазин с фильтрами и торговыми предложениями.
• Поддержка разработчиком — как часто выходят обновления и отвечает ли автор на обращения.
• Отсутствие лишнего — решение «на все случаи жизни» обычно тяжелее и медленнее, чем нужно.
• Совместимость — редакция Битрикс, версия PHP, наличие обмена с 1С.
• Скорость демо — если демо разработчика открывается медленно, ваш сайт быстрее не станет.

Опишите задачу, и я подберу 2–3 варианта с объяснением, чем они отличаются, — это бесплатно.

Да. У каждого решения в каталоге есть ссылка на демо и галерея скриншотов — можно открыть сайт, походить по разделам и проверить, как работают каталог, формы и мобильная версия.

На что смотреть в демо:

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

Если сомневаетесь между вариантами — пришлите ссылки, скажу, какой будет проще развивать дальше.

В первую очередь от готовности контента. Установка и настройка под бренд занимают 1–3 дня, а запуск с наполнением, интеграциями и SEO-подготовкой — 2–4 недели.

Разница в сроках объясняется объёмом работ:

• 1–3 дня — установка решения, настройка под бренд, замена демо-контента на ваш, подключение форм и аналитики.
• 2–4 недели — то же плюс проработка структуры, написание текстов, подготовка фотографий, наполнение каталога, обмен с 1С, подключение оплаты и доставки, SEO-подготовка.

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

Настройками меняются цвета, шрифты, логотип, структура меню, состав и порядок блоков, тексты и изображения. Программирования требуют новые типы страниц, нестандартные расчёты, обмены с 1С и изменение логики каталога.

Граница проходит примерно так: всё, что решение предусмотрело как вариант оформления, настраивается в админке бесплатно и быстро. Всё, чего в нём изначально нет, — это доработка по времени, от 1 700 ₽/час.

Что чаще всего дорабатывают в готовых решениях:

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

Важный момент: доработки я делаю так, чтобы решение можно было обновлять дальше. На Битрикс это означает работу через /local/, собственные компоненты и обработчики событий, на WordPress — дочернюю тему и отдельный плагин. Правки внутри файлов решения слетают при первом же обновлении.

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

После настройки под бренд сайты на одном решении выглядят по-разному: другие цвета и шрифты, свой логотип, свои фотографии, свой набор и порядок блоков, свои тексты. Узнать «тот самый шаблон» может разве что специалист.

Что действительно влияет на продвижение:

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

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

Сайт продолжит работать: решение остаётся у вас на хостинге. Проблемы появятся позже — при обновлении CMS или версии PHP. Тогда решение либо дорабатывается вручную, либо сайт переносится на поддерживаемое.

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

Если поддержка всё же прекратилась, есть три пути:

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

Отдельно замечу: доработки, сделанные по правилам — через /local/, дочернюю тему или отдельный плагин, — при таком переезде не теряются.

Готовый сайт на WordPress выгоднее по бюджету и сроку: 49 000–60 000 ₽ с настройкой и наполнением, без лицензии. Готовое решение на Битрикс сильнее там, где нужны развитый интернет-магазин из коробки, интеграция с 1С и учётным контуром компании, высокая нагрузка и официальная поддержка платформы.

Что даёт 1С-Битрикс:

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

Что даёт WordPress:

• бесплатное ядро — платить нужно только за работы и хостинг;
• запуск от 1–3 дней против нескольких недель на Битрикс с настройкой;
• дешевле владение: нет ежегодного продления лицензии, ниже требования к хостингу;
• проще самостоятельное ведение контента и дешевле поддержка;
• огромный выбор готовых решений под любую нишу.

Практический критерий: если сайт должен быть частью учётного контура компании, обмениваться данными с 1С и выдерживать серьёзную нагрузку — берите Битрикс, лицензия окупается. Если это корпоративный сайт, лендинг или магазин без сложной складской логики — WordPress почти всегда выгоднее.

Решения на 1С-Битрикс — это официальные продукты из Маркетплейса 1С-Битрикс, каталог обновляется автоматически. Готовые сайты на WordPress и Tilda — подобранные и проверенные мной шаблоны.

Раздел с решениями на Битрикс синхронизируется с официальным Маркетплейсом: подтягиваются описания, скриншоты, цены, поддерживаемые редакции и ссылки на демо. Это значит, что вы покупаете лицензионный продукт с поддержкой разработчика, а не «сборку с торрента».

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

Моя роль — не перепродажа, а подбор, установка, настройка и дальнейшее сопровождение. Именно здесь возникает разница между «купленным шаблоном» и работающим сайтом.

Я работаю по собственному техническому стандарту: 8 принципов и 7 этапов от анализа задачи до документирования. Ключевое правило — ноль правок в ядре CMS, чтобы сайт можно было обновлять без потери доработок.

Стандарт основан на официальной документации 1С-Битрикс и WordPress, отраслевых практиках PHP-разработки и опыте поддержки реальных проектов. Восемь принципов действуют одинаково на обеих платформах:

1. Ядро не трогаем — доработки живут отдельно от платформы и переживают обновления.
2. Документированные API — ORM, события и публичные функции вместо запросов в служебные таблицы.
3. Разделение слоёв — данные, бизнес-правила, интеграции и представление в разных файлах.
4. История в Git — видно, когда и зачем внесена доработка и как вернуть рабочее состояние.
5. Копия перед боем — опасные изменения проверяются на тестовой среде.
6. Безопасность в проекте — проверка прав и данных закладывается при проектировании.
7. Измеримая скорость — запросы, кеш и вес ресурсов контролируются по замерам.
8. Описанные решения — нестандартный модуль или обмен сопровождается технической запиской.

Полное описание с примерами кода — на странице «Стандарт разработки». Конкретная реализация зависит от архитектуры проекта и версии CMS, но принципы остаются неизменными.

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

1. Анализ задачи — уточняются цель, пользовательские сценарии, ограничения платформы и ожидаемый результат.
2. Анализ проекта — версия CMS и PHP, структура сайта, активные модули и плагины, существующие доработки, состояние ядра, наличие резервных копий и возможные конфликты.
3. Выбор архитектуры — где разместить функционал, какие API и события использовать, нужен ли отдельный модуль или плагин, как хранить данные и выполнять фоновые процессы.
4. Реализация — код пишется с учётом правил платформы, безопасности, производительности и дальнейшего сопровождения.
5. Тестирование — основной сценарий, граничные случаи, ошибки ввода, права пользователей, мобильная версия и влияние на существующий функционал.
6. Развёртывание — проверка резервной копии, контролируемый перенос изменений, повторная проверка ключевых сценариев.
7. Документирование — фиксируются особенности настройки и запуска, при необходимости передаётся инструкция для заказчика.

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

На 1С-Битрикс — в каталоге /local/: собственные компоненты, модули, обработчики событий. На WordPress — в дочерней теме или отдельном плагине через actions и filters. Файлы платформы и сторонних решений не редактируются.

Системные файлы 1С-Битрикс, WordPress и сторонних расширений не предназначены для проектных доработок: прямое редактирование ведёт к потере изменений при обновлении, конфликтам версий и сложностям в сопровождении.

Куда размещается новый функционал:

• Битрикс — /local/: components/, templates/, modules/, php_interface/, classes/. Каталог /bitrix/ считается частью платформы.
• WordPress — тема и дочерняя тема для представления, отдельный плагин для функционала, который должен пережить смену темы: интеграции, обмены, собственные типы данных, REST API, фоновые задачи.
• Самостоятельные классы и сервисы — когда задаче нужен отдельный слой бизнес-логики.

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

Да, проектный код ведётся в Git, если это допускают условия проекта и инфраструктура. Заказчику это даёт историю изменений, возможность быстро откатиться к рабочему состоянию и понятную передачу проекта другому разработчику.

Что даёт контроль версий на практике:

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

В репозиторий не попадают системные файлы CMS, резервные копии, кеш, временные данные, пользовательские загрузки и конфиденциальные настройки — для Битрикс и WordPress у меня свои .gitignore.

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

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

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

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

Если тестовой среды на проекте нет, я её разворачиваю. Это особенно важно перед обновлением платформы на сайтах со сторонними решениями и унаследованным кодом.

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

Что проверяется в каждом обработчике:

• авторизован ли пользователь;
• имеет ли он право выполнить именно это действие;
• относится ли действие к доступному ему объекту;
• прошёл ли запрос защитную проверку — nonce в WordPress, проверка сессии в Битрикс;
• допустимы ли переданные значения по типу, формату и диапазону.

Отдельно: проверка технического токена не заменяет проверку полномочий. Для каждого действия отдельно определяется, кто имеет право его выполнять. И скрытая кнопка в интерфейсе — не ограничение доступа: защита выполняется на стороне сервера.

При выводе данные экранируются в момент вывода, а не «когда-то раньше при сохранении». Данные из базы, стороннего API или настроек не считаются автоматически безопасными.

Ключи, пароли и токены не размещаются в публичных файлах, JavaScript-коде и открытом репозитории — их место в защищённых настройках или переменных окружения.

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

По замерам, а не на глаз: контролируются количество запросов к базе, объём выбираемых данных, кеширование, вес CSS и JS, обработка изображений и обращения к внешним API.

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

Что контролируется в каждой доработке:

• количество и сложность запросов к базе;
• объём выбираемых данных — только нужные поля и ограничение количества записей;
• повторные вычисления и обращения к одним и тем же данным;
• кеширование: оно проектируется вместе с функционалом, а не добавляется после жалоб на скорость;
• размер и условия подключения CSS и JS — файлы грузятся только там, где нужны;
• работа фоновых задач и обращения к внешним API;
• поведение при росте каталога и числа пользователей.

Кеш при этом не должен скрывать ошибки в архитектуре и не должен нарушать актуальность цен, остатков и персональных данных.

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

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

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

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

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

После завершения работ у вас на руках:

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

Никаких «серверов разработчика», без которых сайт перестанет работать, и никаких закрытых модулей с ежемесячной платой за собственный функционал.

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

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

На практике передача проекта чаще всего упирается не в нежелание подрядчика, а в состояние кода: правки размазаны по файлам ядра, логика перемешана с вёрсткой, никто не знает, какой файл за что отвечает.

Что делает передачу быстрой:

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

Если вы уходите — я передам проект и отвечу на вопросы нового разработчика. Удерживать клиента непрозрачностью кода — плохая стратегия.

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

Полноценное ТЗ на несколько десятков страниц оправдано на крупных проектах со сложной логикой и несколькими участниками. Для типичной задачи достаточно зафиксировать:

• что должно получиться и зачем это нужно бизнесу;
• кто и как этим будет пользоваться;
• какие данные участвуют и откуда берутся;
• что считается корректным поведением в спорных случаях;
• что в задачу не входит.

Последний пункт экономит больше всего нервов обеим сторонам.

Если готового описания нет — я составлю его сам по результатам разбора и пришлю на согласование. Это входит в бесплатную оценку задачи.

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

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

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

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

Ни один процесс не исключает ошибки полностью. Но проверка по списку убирает основную массу проблем до того, как их найдут посетители.

Да: семантическая разметка, последовательность заголовков, адаптивность, управление с клавиатуры, видимый фокус, подписи полей, alt-описания и контрастность. Интерфейс не должен зависеть от идеального объёма контента.

Базовые требования к вёрстке в любом проекте:

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

Отдельно оговорюсь: полное соответствие конкретному уровню WCAG — самостоятельная задача, требующая специализированного аудита. В обычной разработке учитываются основные требования доступности, применимые к интерфейсу.

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

Порядок работы с чужим проектом:

1. технический разбор: версии CMS и PHP, что кастомизировано, тронуто ли ядро, есть ли резервные копии;
2. оценка рисков — что можно править сразу, а что требует предварительного приведения в порядок;
3. выполнение задачи по стандарту, без углубления беспорядка;
4. отдельный перечень найденных проблем с приоритетами — чтобы вы решали, что и когда исправлять.

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

Требование «сначала перепишем всё правильно, потом сделаем вашу задачу» я считаю нечестным по отношению к заказчику.

От состояния проекта и объёма задачи. Работа считается по времени — от 1 700 ₽ за час; перед началом я смотрю сайт и называю оценку в часах.

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

Чаще всего ко мне обращаются с такими задачами по Битрикс:

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

Обмен настраивается через штатный модуль обмена: из 1С на сайт выгружаются товары, цены и остатки, а с сайта в 1С передаются заказы. Нетиповые данные требуют доработки правил обмена на стороне 1С или сайта.

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

Что обычно приходится дорабатывать:

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

У меня есть аттестация «1С Специалист» и сертификаты программиста Битрикс, поэтому я одинаково понимаю обе стороны обмена — это заметно ускоряет разбор проблем.

Да, я регулярно подхватываю чужие проекты на 1С-Битрикс, в том числе без документации и без связи с прежним подрядчиком.

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

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

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

Типичные причины медленной работы Битрикс:

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

Я начинаю с замеров — на что именно уходит время, — и только потом правлю. Такой порядок даёт результат, который видно в цифрах, а не «на глаз».

Доработки не теряются, если они вынесены за пределы ядра: кастомизированные компоненты копируются в свой namespace, а изменения логики выносятся в обработчики событий, а не правятся в файлах системы.

Главное правило работы с Битрикс — не править файлы ядра. Если этому следовать, обновления проходят штатно.

Что помогает обновляться безопасно:

• кастомизация компонентов копированием, а не изменением оригиналов;
• своя логика — через обработчики событий в init.php или собственном модуле;
• резервная копия перед каждым обновлением;
• обновление сначала на тестовой копии сайта, потом на боевом;
• проверка ключевых сценариев после обновления: заказ, формы, обмен с 1С.

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

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

Выбор определяется задачами, а не бюджетом «на вырост»: лишние возможности не ускоряют проект, но усложняют его.

На что смотреть при выборе:

• нужен ли модуль интернет-магазина и обмен с 1С;
• планируется ли многосайтовость;
• какой объём каталога и какая ожидается посещаемость;
• нужна ли расширенная работа с CRM.

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

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

Лицензия Битрикс покупается бессрочно, а продление — это доступ к обновлениям на следующий период. Пока обновления приходят, закрываются уязвимости и поддерживаются новые версии PHP.

Чем рискует сайт без обновлений:

• накапливаются незакрытые уязвимости;
• возникает несовместимость с актуальными версиями PHP на хостинге;
• обновиться «одним прыжком» через несколько лет становится дороже, чем продлевать регулярно.

Если продление давно просрочено, я сначала оцениваю объём работ по приведению сайта в актуальное состояние, а потом уже обновляю.

Для типовых задач готовое решение выгоднее: запуск быстрее и дешевле, а функционал уже проверен на сотнях сайтов. Разработка с нуля оправдана, когда логика проекта нестандартная.

Готовое решение — это шаблон с настроенным каталогом, корзиной, формами и адаптивной вёрсткой. Его настраивают под бренд и задачи: цвета, структура, блоки, наполнение.

На что обратить внимание при выборе решения:

• поддерживается ли оно разработчиком и как часто обновляется;
• насколько оно перегружено лишним функционалом;
• совместимо ли с нужной редакцией Битрикс;
• как в нём реализован обмен с 1С.

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

Заявки и заказы с сайта передаются в CRM автоматически: формы создают лиды или сделки, а статусы и данные клиента при необходимости возвращаются обратно на сайт.

С Битрикс24 интеграция проходит проще всего — есть штатные механизмы связи. С другими CRM интеграция делается через их API: настраивается передача заявок, привязка к менеджерам, источники обращений и статусы.

Что обычно нужно настроить:

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

Последний пункт особенно важен: без логирования «потерянную заявку» невозможно расследовать.

Да. Сданы экзамены «Программист Битрикс уровень 1. Интеграция дизайна и настройка платформы» и «Программист Битрикс уровень 2. Основные технологии и расширение типовых возможностей системы».

Кроме сертификатов Битрикс есть аттестация «1С Специалист» по конфигурированию и внедрению в «1С:Предприятие 8» и высшее техническое образование (Московский авиационный институт).

Практический опыт в IT — более 20 лет. Среди проектов были работы для «Мосфильм», Gipfel, «Эвалар», Major, H&M, «Эlevel» и других компаний. Сканы документов можно посмотреть на странице «Обо мне».

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

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

Обязательная часть переноса — сохранение SEO:

• карта соответствия старых и новых адресов;
• 301-редиректы со старых URL;
• перенос заголовков, описаний и микроразметки;
• проверка индексации после запуска.

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

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

Порядок действий при «упавшем» после обновления сайте:

1. вернуть рабочее состояние из бэкапа, чтобы сайт снова открывался;
2. включить вывод ошибок на тестовой копии и найти конкретную причину;
3. устранить её — обновить модуль, вынести правки из ядра, поправить совместимость;
4. повторно обновиться на копии и только потом на боевом сайте.

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

Это два разных продукта. «1С-Битрикс: Управление сайтом» — CMS для сайтов и интернет-магазинов. Битрикс24 — корпоративный портал и CRM для работы компании: сделки, задачи, телефония, документы.

Путаница возникает из-за общего названия, но задачи у продуктов разные:

• 1С-Битрикс: Управление сайтом — то, на чём работает сам сайт: страницы, каталог, корзина, оформление заказа, обмен с 1С.
• Битрикс24 — то, что происходит внутри компании: лиды и сделки, задачи и проекты, чаты, звонки, документы, отчёты.

Они прекрасно работают вместе: заявка с сайта попадает в Битрикс24, менеджер ведёт по ней сделку, а статусы при необходимости возвращаются на сайт в личный кабинет клиента. Но одно не заменяет другое: на Битрикс24 не сделать полноценный интернет-магазин, а CMS не заменит CRM.

Я работаю с обоими продуктами — и с сайтами, и с порталом.

Да. Настраиваются воронки и стадии сделок, пользовательские поля, роботы и бизнес-процессы, права доступа, отчёты. Нетиповая логика делается приложениями через REST API. Стоимость — от 1 700 ₽/час.

Что чаще всего требуется в Битрикс24:

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

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

Да. Битрикс24 подключается к любому сайту: заявки со всех форм попадают в CRM как лиды или сделки, вместе с источником, UTM-метками и страницей обращения.

Сайт не обязан быть на 1С-Битрикс: интеграция работает через REST API и открытые линии. Подключаются WordPress, Tilda, самописные сайты и лендинги.

Что настраивается при интеграции:

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

Журналирование здесь — не формальность. Именно оно позволяет ответить на вопрос «а точно ли заявка была?» — и в 100% случаев прекращает споры между отделом продаж и подрядчиком по сайту.

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

Порядок диагностики:

1. посмотреть журнал обмена на стороне сайта и протокол в 1С — в большинстве случаев причина видна прямо там;
2. проверить доступы: логин, пароль, адрес обмена, срок действия SSL-сертификата;
3. проверить лимиты хостинга: время выполнения скрипта, память, размер загружаемого файла — типичная причина обрыва на больших каталогах;
4. сверить структуру: не появились ли в 1С новые свойства, характеристики, склады или типы цен;
5. проверить, не блокирует ли обмен защита сайта или изменение прав на папку выгрузки.

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

Если журнала обмена нет — я его добавляю. Без него каждая последующая поломка снова превращается в расследование.

Композитный сайт — технология Битрикс, которая отдаёт посетителю сохранённую статическую копию страницы мгновенно, а динамические части подгружает следом. Даёт заметный прирост скорости, но требует аккуратной настройки.

Как это работает: страница делится на статическую часть, одинаковую для всех, и динамическую — корзина, авторизация, персональные цены. Статика отдаётся сразу, динамика догружается запросом.

Где composite действительно помогает: каталоги и информационные разделы с высокой посещаемостью и редко меняющимся содержимым.

На что обратить внимание при включении:

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

Поэтому я включаю композит после оптимизации, а не вместо неё.

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

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

На что я смотрю в первую очередь:

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

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

Да. В личном кабинете можно показывать историю и статусы заказов из 1С, документы и счета, персональные цены, остатки по складам, повторный заказ и данные по договорам.

Личный кабинет чаще всего нужен в B2B, где он заменяет часть работы менеджера. Что в него обычно выносят:

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

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

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

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

Что важно знать про бюджет проекта на Битрикс:

• лицензия — разовая покупка, дальше идёт ежегодное продление доступа к обновлениям по льготной цене;
• редакция подбирается под задачу: для интернет-магазина нужна редакция с соответствующим модулем;
• готовое решение из Маркетплейса оплачивается отдельно от лицензии;
• хостинг под Битрикс требует больше ресурсов, чем под сайт-визитку на WordPress.

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

Торговые предложения — варианты одного товара с разными характеристиками и ценами: размер, цвет, объём, фасовка. Нужны, когда у товара несколько вариантов, у каждого своя цена, свой остаток и свой артикул в 1С.

Пример: футболка — это товар, а «синяя, размер M» — торговое предложение. У каждого варианта свои цена, остаток, штрихкод и артикул, но карточка в каталоге одна.

Когда торговые предложения нужны:

• у товара есть варианты, которые учитываются в 1С отдельными позициями;
• цена и наличие различаются от варианта к варианту;
• покупатель должен выбирать вариант прямо в карточке.

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

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

Чаще всего это новые блоки и формы, доработка WooCommerce, правки вёрстки, ускорение, защита после взлома и интеграции. Небольшая правка занимает 1–2 часа, новый функционал — от одного дня; работа считается от 1 700 ₽ за час.

Чаще всего обращаются с такими задачами:

• новые блоки, формы и разделы;
• доработка каталога и корзины на WooCommerce;
• правки вёрстки и адаптивной версии;
• ускорение сайта;
• устранение последствий взлома и защита сайта;
• интеграции с 1С, CRM и внешними сервисами.

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

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

Сильные стороны 1С-Битрикс:

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

Сильные стороны WordPress:

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

Разница в подходе принципиальная: в Битрикс магазин, права доступа, кеширование и защита — части одной платформы с общей поддержкой. В WordPress тот же результат собирается из ядра и сторонних плагинов, каждый со своим автором и своим циклом обновлений. Для небольшого проекта это гибкость, для крупного — дополнительный риск.

Главный практический критерий — нужен ли полноценный обмен с 1С по товарам, ценам, остаткам и заказам. Если да, Битрикс обычно дешевле в итоге, несмотря на лицензию. Если нет — WordPress почти всегда выгоднее.

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

WooCommerce уверенно тянет каталог до нескольких тысяч товаров с несложной структурой характеристик. Для десятков тысяч позиций, торговых предложений и сложной складской логики лучше подходит 1С-Битрикс.

WooCommerce закрывает стандартные потребности магазина: каталог, варианты товара, корзина, оформление заказа, оплаты, доставки, купоны, отчёты.

Когда WooCommerce — хороший выбор:

• каталог до нескольких тысяч позиций;
• несложная структура характеристик;
• ограниченный бюджет на запуск и поддержку.

Когда стоит смотреть в сторону Битрикс:

• десятки тысяч товаров и множество торговых предложений;
• обмен с 1С по нескольким складам и типам цен, персональные цены для клиентов;
• сложная торговая логика — правила корзины, скидки, бонусы, B2B-сценарии: в Битрикс это есть в базовой системе, в WooCommerce собирается из плагинов;
• высокая посещаемость и требования к производительности — здесь работают штатные инструменты кеширования и масштабирования платформы;
• нужна единая техническая поддержка и официальные обновления вместо десятка независимых авторов плагинов.

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

Что обычно даёт результат:

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

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

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

Базовый набор мер, который стоит сделать на любом сайте:

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

Резервные копии — самый недооценённый пункт. Они не предотвращают взлом, но превращают катастрофу в задачу на пару часов.

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

Порядок работ при заражении:

1. ограничить доступ к сайту, чтобы он не заражал посетителей и не попал под санкции поисковых систем;
2. снять копию для анализа и найти вредоносные файлы и внедрённый код;
3. определить точку входа — чаще это уязвимый плагин или украденный пароль;
4. вычистить код, обновить всё, что можно обновить, сменить пароли и ключи;
5. проверить, не оставлены ли скрытые администраторы и задачи по расписанию;
6. снять пометку о вредоносности в панелях вебмастеров.

Последний пункт часто забывают, и сайт остаётся помеченным в поиске уже после лечения.

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

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

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

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

Да. Обмен товарами, ценами, остатками и заказами между WordPress (WooCommerce) и 1С настраивается, как и передача заявок в CRM. В отличие от Битрикс, штатного модуля обмена нет — интеграция делается через API или готовые модули.

Варианты реализации обмена с 1С:

• готовый модуль обмена — быстрее и дешевле, подходит для типовых каталогов;
• индивидуальная интеграция через REST API — гибче, нужна при нестандартной структуре данных;
• обмен через промежуточные файлы — вариант, когда прямой доступ к 1С ограничен.

Передача заявок в CRM (amoCRM, Битрикс24 и другие) настраивается через их API. Важная деталь — логирование отправок: без него потерянную заявку невозможно расследовать.

Честное сравнение: в 1С-Битрикс обмен с 1С, складами и службами доставки — часть платформы, он поддерживается вендором и обновляется вместе с системой. На WordPress это всегда отдельное решение: модуль стороннего автора или интеграция под проект. Работает надёжно, но требует сопровождения при смене версий 1С и WooCommerce. Если обмен для бизнеса критичен и структура данных сложная, Битрикс в итоге выходит дешевле.

Переносятся структура, тексты, изображения и адреса страниц, а дизайн воссоздаётся на WordPress. Со старых адресов настраиваются редиректы, чтобы сохранить позиции в поиске.

Обычно на WordPress переходят, когда конструктор перестаёт справляться: не хватает функционала, нужна интеграция с 1С или CRM, хочется полного контроля над сайтом и его кодом, либо не устраивает стоимость подписки.

Что важно сделать при переносе:

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

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

Безопасный порядок обновления:

1. сделать резервную копию файлов и базы данных;
2. обновить сначала на тестовой копии, если сайт коммерческий;
3. обновлять по частям, а не всё сразу — так проще найти виновника;
4. после обновления проверить формы, корзину и оформление заказа.

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

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

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

Правильные способы:

• дочерняя тема — для изменений шаблонов и стилей;
• отдельный небольшой плагин — для функционала, который должен пережить смену темы;
• хуки (actions и filters) вместо копирования больших кусков кода;
• перекрытие шаблонов WooCommerce штатным механизмом, а не правкой плагина.

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

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

На что смотреть при оценке плагина:

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

При оптимизации я смотрю реальный вклад каждого плагина в скорость и предлагаю заменить проблемные или перенести их функционал в код. Часто три-четыре плагина удаётся убрать без потери возможностей.

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

Сравнение по существу:

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

Практический подход: если сайт уже собран на Elementor — не переделываю его без причины, а работаю в том же инструменте. Для новых проектов чаще беру Gutenberg с готовыми блоками: сайт легче, а редактировать его всё равно несложно.

Главное, чего стоит избегать, — смешивать несколько конструкторов на одном сайте.

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

Что вы сможете делать сами:

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

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

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

Проблема почти всегда в способе отправки: WordPress по умолчанию отправляет письма средствами сервера, и почтовые службы им не доверяют. Решается отправкой через SMTP и настройкой записей SPF, DKIM и DMARC для домена.

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

Что настраивается для решения:

• отправка через SMTP реального почтового ящика на вашем домене;
• записи SPF и DKIM в DNS, подтверждающие право сервиса отправлять почту от имени домена;
• политика DMARC;
• корректный адрес отправителя — не wordpress@, а реальный ящик домена;
• журнал отправленных писем, чтобы видеть факт отправки и ошибки;
• дублирование заявок в Telegram или CRM, чтобы они не зависели от почты.

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

Белый экран — это фатальная ошибка PHP, скрытая от посетителей. Нужно включить журнал ошибок, найти виновника — обычно несовместимый плагин или тема — и отключить его через файловую систему.

Порядок действий:

1. включить журналирование ошибок в wp-config.php: WP_DEBUG и WP_DEBUG_LOG при выключенном WP_DEBUG_DISPLAY — тогда текст ошибки попадёт в файл, а не на экран посетителю;
2. посмотреть в журнале, какой файл и какого плагина вызывает ошибку;
3. отключить этот плагин, переименовав его папку через файловый менеджер или FTP — админка при белом экране обычно недоступна;
4. если не помогло — временно переключиться на стандартную тему тем же способом;
5. после восстановления доступа обновить или заменить проблемный компонент.

Частая причина — несовместимость плагина с новой версией PHP или WordPress. Именно поэтому обновления на коммерческом сайте лучше проводить на копии.

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

Нужны актуальная версия PHP, база данных MySQL или MariaDB, SSL-сертификат, доступ к cron и резервное копирование. Для магазина дополнительно важны объём памяти на процесс и время выполнения скриптов.

На что смотреть при выборе:

• Версия PHP — актуальная поддерживаемая ветка. Старые версии небезопасны и медленнее.
• Лимиты — память на процесс и максимальное время выполнения: их не хватает при импорте товаров и обменах.
• Cron — возможность запускать задания системным планировщиком, а не встроенным WP-Cron, который зависит от посещаемости.
• SSL-сертификат — обязателен, обычно бесплатный.
• Резервное копирование — ежедневное, с хранением вне сервера и с возможностью самостоятельного восстановления.
• Панель управления и доступ по SSH — упрощают обслуживание.

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

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

Рабочая схема:

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

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

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

Что чаще всего требуется:

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

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

Поэтому проверка прав делается при каждом обращении к странице и к файлу, а не только при отрисовке интерфейса.

Да. Языковые версии делаются отдельными разделами сайта с корректными языковыми атрибутами и перекрёстными ссылками hreflang, чтобы поисковые системы показывали нужную версию нужной аудитории.

Что важно решить до старта:

• Структура адресов — подпапки вида /en/, поддомены или отдельные домены. Для большинства проектов подпапки проще и дешевле.
• Объём перевода — переводится весь сайт или только ключевые разделы. Половинчатый перевод хуже отсутствия версии.
• Что переводить — кроме текстов это меню, формы, письма, товары, характеристики, заголовки и описания для поиска.
• Кто переводит — автоперевод без вычитки заметен и вредит доверию, особенно в B2B.
• Валюты и доставка — для магазина языковая версия обычно тянет за собой отдельные цены и условия.

Технически ключевой момент — корректные атрибуты языка и hreflang. Без них поиск может показывать англоязычную версию русским посетителям и наоборот.

Нужен договор эквайринга с банком или платёжным сервисом, после чего платёжный модуль подключается к WooCommerce. Отдельно настраивается онлайн-касса — по закону чек должен формироваться при оплате.

Порядок подключения:

1. выбор платёжного сервиса или банка и заключение договора — тарифы и сроки вывода средств отличаются заметно;
2. подключение платёжного модуля к сайту и настройка в тестовом режиме;
3. подключение онлайн-кассы или фискализации на стороне платёжного сервиса;
4. настройка статусов заказа: что происходит при успешной оплате, отказе и возврате;
5. тестовые платежи на реальных суммах и проверка чека;
6. переключение в боевой режим.

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

Также настраивается журнал платежей: он нужен и для разбора спорных ситуаций, и для сверки с банком.

Кроме копирования файлов и базы нужно заменить адреса сайта в базе данных, перенести почту и задания cron, выпустить SSL-сертификат и переключить домен только после проверки сайта на новой площадке.

Типичные ошибки при самостоятельном переносе:

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

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

Услуга переноса стоит от 9 000 ₽ и включает проверку работоспособности на новом месте.

Пять онлайн-сервисов: генератор UTM-меток, генератор паролей, генератор CSS (градиенты и тени), генератор QR-кодов и сжатие изображений. Все работают в браузере, без регистрации и бесплатно.

Что есть в разделе «Инструменты»:

• Генератор UTM-меток — сборка ссылок для Яндекс Директ, Google Ads и соцсетей с поддержкой динамических параметров.
• Генератор паролей — надёжные пароли нужной длины, сразу 5 вариантов.
• Генератор CSS — градиенты и тени с живым предпросмотром и готовым кодом.
• Генератор QR-кодов — коды для ссылок, текста, телефона, email и Wi-Fi с настройкой размера и цветов.
• Сжатие изображений — уменьшение веса JPG, PNG и WebP перед публикацией на сайте.

Это инструменты, которыми я пользуюсь сам в работе. Они собраны без рекламы, без лимитов «5 раз в день» и без предложения зарегистрироваться ради результата.

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

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

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

Никуда. Все инструменты работают полностью в браузере: пароли, ссылки, содержимое QR-кодов и изображения не отправляются на сервер и нигде не сохраняются.

Это принципиальный момент, особенно для генератора паролей и сжатия изображений. Пароль, сгенерированный на чужом сервере, доверия не заслуживает — как и фотографии, загруженные неизвестно куда.

Как это устроено технически:

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

Практическое следствие: инструменты работают быстро и не зависят от размера очереди на сервере, а закрытие вкладки не оставляет следов.

UTM-метки показывают, откуда пришёл посетитель: из какой рекламной системы, кампании, объявления и по какой ключевой фразе. Без них весь платный трафик сливается в общую массу и оценить отдачу от рекламы невозможно.

Что даёт корректная разметка ссылок:

• видно, какие каналы приносят заявки, а какие — только клики;
• можно сравнивать кампании, объявления и посадочные страницы между собой;
• в CRM видно источник каждой сделки, а не только «сайт»;
• решения о перераспределении бюджета принимаются по данным, а не по ощущениям.

Пять параметров и их назначение:

• utm_source — источник: yandex, google, vk;
• utm_medium — тип трафика: cpc, email, social;
• utm_campaign — название кампании;
• utm_content — объявление или блок, чтобы различать варианты;
• utm_term — ключевая фраза.

Собрать ссылку без ошибок помогает генератор UTM-меток — он же следит за корректностью адреса и кодировкой.

В генераторе UTM-меток есть готовые пресеты источников — Яндекс Директ, Google Ads, ВКонтакте, Facebook, Instagram, YouTube, TikTok. Достаточно выбрать источник, вставить адрес страницы и название кампании: остальное подставится автоматически.

Порядок работы:

1. вставьте адрес страницы, на которую ведёт реклама;
2. выберите источник — например, Яндекс Директ: utm_source и utm_medium=cpc подставятся сами;
3. укажите название кампании, при необходимости — объявление и ключевую фразу;
4. добавьте динамические параметры кнопками, если нужна детальная аналитика;
5. скопируйте готовую ссылку одной кнопкой.

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

Адрес проверяется на корректность — сервис не даст собрать ссылку с опечаткой в домене или протоколе.

Поддерживаются 11 макросов Яндекс Директа и 9 макросов Google Ads: номер кампании и объявления, ключевая фраза, тип площадки, позиция, тип устройства, регион показа и другие.

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

Яндекс Директ: тип площадки, источник перехода, тип позиции, позиция объявления, ключевая фраза, идентификаторы кампании, объявления, фразы и группы, тип устройства, регион показа.

Google Ads: ключевое слово, идентификаторы кампании, группы объявлений и объявления, тип сети, тип соответствия, устройство, площадка размещения, позиция объявления.

Практический совет: не добавляйте все макросы подряд. Чем длиннее ссылка, тем выше шанс, что что-то потеряется при копировании или обрежется в стороннем сервисе. Обычно достаточно кампании, объявления и ключевой фразы.

Для соцсетей макросы не предусмотрены — там параметры заполняются вручную.

Достаточно длинный, случайный и уникальный для каждого сервиса. Пароль не должен содержать личных данных, слов из словаря, дат рождения, номеров телефонов и последовательностей вроде 123456 или qwerty.

Практические правила:

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

В генераторе паролей длина настраивается от 4 до 64 символов, по умолчанию 12. Наборы символов включаются отдельно, есть опция исключить похожие символы — 0 и O, 1 и l — чтобы пароль не путался при диктовке или ручном вводе.

Каждый раз выдаётся 5 вариантов: удобно выбрать тот, который проще прочитать.

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

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

Где это пригождается:

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

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

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

Градиент: выбирается тип — линейный или радиальный, задаётся угол от 0 до 360°, добавляется сколько угодно цветовых точек. Результат виден сразу, готовый CSS можно скопировать одной кнопкой.

Тень: настраиваются смещение по горизонтали и вертикали, размытие, растяжение, прозрачность и цвет. Есть переключатель внутренней тени (inset).

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

Обратите внимание: генератор делает именно эти два свойства. Скруглений, анимаций и раскладок в нём нет — он намеренно простой.

Пять типов: ссылка, произвольный текст, телефон, email с темой письма и Wi-Fi с паролем и типом шифрования. Размер настраивается от 120 до 1000 пикселей, цвета кода и фона — произвольные, результат скачивается в PNG.

Где это применяют: визитки, листовки, упаковка, баннеры, меню в кафе, инструкции к товару, таблички с Wi-Fi для гостей, ценники со ссылкой на карточку товара.

Практические советы по использованию QR-кодов:

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

Код генерируется прямо в браузере: содержимое — ссылка, пароль от Wi-Fi, контакты — никуда не передаётся.

Сначала уменьшите размеры до реально нужных, затем сожмите с качеством 70–85% и сохраните в WebP. Уменьшение ширины даёт наибольшую экономию: фотография 4000 px на сайте, где она показывается в 800 px, — самая частая причина медленной загрузки.

Порядок действий в сервисе сжатия изображений:

1. перетащите файлы в окно — принимаются JPG, PNG и WebP, до 5 МБ и до 20 файлов за раз;
2. выберите максимальную ширину: 1920 px хватает для фонов и больших баннеров, 1280 или 800 px — для контентных изображений;
3. задайте качество: 70–85% для фотографий, выше — для изображений с текстом и мелкими деталями;
4. оставьте формат «Авто» — он выберет WebP, который весит заметно меньше при том же качестве;
5. скачайте результат: рядом с каждым файлом видно, на сколько процентов уменьшился вес.

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

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

Изображения обычно составляют большую часть веса страницы, поэтому их оптимизация — самый быстрый способ ускорить сайт. Часто вес страницы удаётся сократить в несколько раз без заметной потери качества.

Почему это важно:

• скорость загрузки напрямую влияет на поведение посетителей: с медленных страниц уходят, не дождавшись;
• показатели Core Web Vitals учитываются поисковыми системами при ранжировании;
• на мобильном интернете разница между страницей в 800 КБ и в 5 МБ ощущается сразу;
• лёгкие изображения снижают нагрузку на хостинг и трафик.

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

Если нужно разобраться с этим системно — есть отдельная услуга ускорения сайта, от 15 000 ₽, с замерами до и после.