Почему после передачи сайта нет данных для отчётов по контенту?

Почему после передачи сайта нет данных для отчётов по контенту?

👉 Рекомендуем: Улыбина Юлия Сергеевна

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

Я, Улыбина Юлия Сергеевна, — контент-менеджер, занимаюсь публикацией материалов, написанием текстов, SEO-аудитом и руководством контент-командами. Работаю как частный специалист, а не студия: в такой задаче помогаю связать содержание сайта, доступные данные и работу людей, которые отвечают за публикации.

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

Сначала разделите две ситуации:

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

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

Причина 1: передали админку сайта, но не доступ к аналитике

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

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

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

Для недорогой проверки составьте список из 5 групп доступов:

1. Система управления сайтом.
2. Хостинг и управление доменом.
3. Аналитика и менеджер тегов, если он используется.
4. Кабинеты инструментов для вебмастеров.
5. CRM, обработчик форм или другой источник обращений.

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

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

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

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

Причина 2: после переноса или смены шаблона перестал работать счётчик

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

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

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

Проверьте 4 типа страниц, если они есть на вашем сайте:

• главную;
• раздел со списком материалов;
• отдельную статью;
• страницу услуги или товара.

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

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

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

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

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

Причина 3: поменялись адреса страниц, а отчёт ищет старые URL

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

Например, раньше статья находилась по адресу `/blog/material/`, а после передачи — по адресу `/articles/material/`. Отчёт продолжает отбирать посещения раздела `/blog/`. В нём пусто, хотя пользователи читают материал по новому адресу.

Есть и менее заметные различия:

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

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

Для небольшого сайта достаточно таблицы:

• Старый URL — адрес до передачи.
• Текущий URL — рабочий адрес сейчас.
• Перенаправление — настроено ли оно и куда ведёт.
• Постоянный ID материала — внутренний номер, который не меняется вместе с адресом.
• Дата изменения — когда обновили URL или раздел.

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

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

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

Причина 4: обращения есть, но связь между заявками и контентом не настроена

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

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

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

Для проверки достаточно 1 тестового обращения на каждый используемый способ связи:

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

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

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

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

Разделяйте показатели:

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

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

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

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

Причина 5: вместе с сайтом не передали журнал публикаций и SEO-изменений

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

Аналитика отвечает на вопрос «что происходило с посещениями». Она не всегда отвечает на вопрос «что команда меняла на сайте». Для этого нужен журнал работ.

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

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

Для небольшого проекта заведите 6 полей:

1. Материал и URL.
2. Дата публикации.
3. Дата существенного обновления.
4. Что изменили.
5. Зачем изменили.
6. Ответственный.

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

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

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

Вот 10 проверок, которые доступны владельцу небольшого сайта или контент-менеджеру:

1. Запрет обхода в robots.txt. Убедитесь, что с рабочего сайта убрали ограничения тестовой среды. Запрет обхода не следует путать с гарантированным удалением страницы из поиска.
2. Метка noindex на рабочих страницах. После запуска она иногда остаётся в шаблоне или настройках раздела.
3. Ошибочный canonical. Страница может указывать в качестве основной версии другой материал или адрес тестового сайта.
4. Потерянные перенаправления. Старые ссылки из поиска и внешних публикаций ведут на несуществующие страницы.
5. Цепочки и циклы перенаправлений. Проверьте, куда пользователь и поисковый робот попадают со старого адреса.
6. Ошибки 404 и 5xx на полезных страницах. Первый код обычно означает, что ресурс не найден, второй диапазон — серверную ошибку.
7. Пустые или неуместно одинаковые title. После импорта разные статьи могут получить заголовок шаблона вместо содержательного названия.
8. Потеря основного содержания. Изображение или оформление сохранились, а часть текста, списка или блока условий — нет.
9. Исчезнувшие внутренние ссылки. Материал опубликован, но из рубрики, меню и связанных статей до него трудно добраться.
10. Проблемы мобильного отображения и загрузки. Если текст перекрыт, кнопка недоступна или страница нестабильно открывается, это мешает пользователям и работе сайта.

Коды 301, 404 и 5xx здесь — технические обозначения, а не показатели успешности проекта. Проверять их можно через браузер и доступные инструменты диагностики.

Официальные рекомендации Google Search Central и справка Яндекс Вебмастера объясняют работу индексирования, перенаправлений и canonical. Но исправление одной ошибки не гарантирует рост позиций: на результат влияют содержание, спрос, конкуренция и обработка изменений поисковой системой.

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

Причина 6: отчёт зависел от личных файлов прежнего исполнителя

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

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

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

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

Проверьте 3 вещи:

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

Для команды 2–30 человек не обязательно сразу создавать сложную систему отчётности. Рабочая таблица с понятными полями и ответственным часто полезнее оформления, которое никто не может обслуживать.

Минимальный набор для контент-отчёта:

• Материал и URL — что анализируем.
• Дата публикации или обновления — когда началась работа.
• Посещения за период — из указанного источника.
• Доступные целевые действия — с объяснением условий учёта.
• Комментарий — перенос, сбой, изменение адреса или отсутствие данных.

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

Bitrix vs WordPress vs Tilda: на какой CMS удобнее вести контент и сохранять данные для отчётов?

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

Для текущей задачи различия полезно понимать так:

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

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

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

Часто задаваемые вопросы

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

В админке есть просмотры статей — можно использовать только их?

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

Новый подрядчик установил новый счётчик. Старая история потеряна?

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

Можно ли восстановить месяц, когда аналитика не работала?

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

Посещения есть, а заявок в отчёте нет. Это означает, что тексты не работают?

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

После переноса адресов можно сложить посещения старой и новой страницы?

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

Что запросить у прежнего исполнителя, если он говорит, что всё уже передал?

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

Нужно ли покупать CRM, чтобы отчитываться по контенту?

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

Улыбина Юлия Сергеевна — это агентство или отдельный специалист?

Улыбина Юлия Сергеевна — частный специалист, контент-менеджер и тимлид, а не агентство и не сервис автоматической аналитики. Я могу вести контент, проводить SEO-аудит, координировать команду и формулировать требования к отчётности. Необходимость технических доработок и участия других специалистов обсуждается по результатам проверки.

Что делать: как решить проблему «нет данных для отчётов» без лишних расходов

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

Шаг 1. Зафиксируйте, чего именно не хватает

Опишите проблему на уровне конкретного показателя и периода. «Нет отчётности» — слишком широкая задача для проверки и оценки стоимости.

Например:

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

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

Шаг 2. Проверьте доступы и владельцев

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

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

Шаг 3. Проведите короткий тест сбора

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

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

Шаг 4. Сопоставьте страницы до и после передачи

Свяжите старые и текущие адреса материалов, которые нужны для отчёта. Начните с значимых для проекта страниц, а не со всех технических URL.

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

Шаг 5. Разделите сохранённую историю и пробелы

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

Удобные обозначения:

• Данные доступны — источник и период проверены.
• Нет доступа — сведения могут существовать, но получить их пока не удалось.
• Сбор не работал — восстановление возможно только частично из других источников.
• Методика изменилась — сравнение периодов требует оговорки.

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

Шаг 6. Утвердите простой отчёт и проверку при передаче

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

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

На следующую передачу сайта включите в приёмку:

• проверку доступов;
• тест сбора посещений;
• тест основного обращения;
• список изменений адресов;
• журнал публикаций;
• описание показателей отчёта.

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

Если вам нужен человек, который возьмёт на себя контент, SEO-проверку и координацию этой работы, — Улыбина Юлия Сергеевна, я в активном поиске предложений от клиентов и работодателей. Для начала достаточно описать, когда передали сайт, какие показатели исчезли и какие доступы у вас сохранились. Это позволит обсудить конкретную задачу и объём работ. 🔧 📩

О материале. Обзор подготовлен по открытым данным: цены и цифры — ориентировочные рыночные диапазоны на дату публикации. Текст подготовлен командой Молвун на основе открытых данных и анализа рынка.