аудит интернет-магазина: что проверить, кроме сайта на 1С

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

почему возникает рассинхрон остатков и цен между сайтом и 1С

В магазине на полторы тысячи позиций в пятницу вечером бухгалтер меняет цены в 1С перед закрытием месяца. Регламентное задание должно выгрузить изменения на сайт в 23:00, но обмен CommerceML падает по таймауту на файле весом под 40 мегабайт. Сайт всю субботу торгует по ценам среды, а склад уже отгружает по-новому. В понедельник утром звонит клиент: заказал холодильник по цене с сайта, менеджер на телефоне называет сумму на три тысячи рублей выше — и это уже не техническая мелочь, а спор с покупателем и репутационный удар.

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

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

как исправить рассинхрон остатков и цен

Первый шаг — поднять лог обмена (в 1С-Битрикс это раздел «Обмен данными» или файл /bitrix/1c_exchange.log) и найти точное время и код ошибки, а не гадать по жалобам покупателей. Дальше разводят потоки: выгрузку каталога, остатков и заказов переводят на разные сессии обмена, чтобы падение одной не блокировало остальные. Большие файлы режут на части — дозагрузка кусками устойчивее к таймауту, чем один XML на сотни мегабайт.

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

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

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

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

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

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

как предотвратить сбои каталога и заказов при пиковой нагрузке

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

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

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

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

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

карточка товара, корзина и оформление заказа

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

оплата и статусы заказов

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

резервные копии и восстановление после сбоя

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

персональные данные покупателей и как не наступать на одни грабли дважды

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

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

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

Сколько стоит аудит интернет-магазина на 1С?

Цена зависит от числа интеграций — обмена с 1С, платёжного шлюза, маркетплейсов — и от объёма каталога. Ориентир по тарифам смотрите на странице цен ukved.ru; после короткого брифа по магазину называем точную стоимость проверки и срок, за который её проведём.

Как понять, что дело в обмене с 1С, а не в самом сайте?

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

Обязательно ли проверять 152-ФЗ, если магазин небольшой?

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

Как часто проводить технический аудит интернет-магазина?

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

Можно ли ускорить обмен с 1С, не меняя код сайта?

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