Ошибки при работе со страницами Wagtail чаще всего возникают не потому, что CMS сложная. Обычно причина проще: администратор не проверил, где находится страница, какой у неё статус, есть ли на неё ссылки, кто её уже редактировал и что произойдёт после публикации, перемещения или удаления.
В Wagtail страница — это не просто текст с картинками. Она находится в дереве страниц, может участвовать в меню, иметь собственный адрес, SEO-поля, дочерние страницы, связанные блоки и опубликованную версию.
Поэтому со страницами нужно работать не со страхом, а с пониманием. Исправить опечатку — одно. Переместить страницу услуги, изменить её URL или удалить старый раздел — совсем другое. В первом случае вы редактируете содержимое. Во втором — влияете на структуру сайта.
Эта статья поможет понять, где администраторы и редакторы чаще всего ошибаются при работе со страницами Wagtail и как избежать проблем до того, как они станут видны пользователям.
Статья полезна администраторам сайта, редакторам, контент-менеджерам и сотрудникам компании, которые работают со страницами в Wagtail: создают новые материалы, редактируют существующие, скрывают страницы, снимают их с публикации, перемещают по структуре или удаляют.
Также материал будет полезен руководителям и владельцам сайтов. Он помогает понять, почему для сайта на Wagtail важны не только доступы в админку, но и правила работы: кто создаёт страницы, кто проверяет изменения, кто публикует и когда нужно обращаться к разработчику.
В Wagtail страницы организованы в виде дерева. Это одна из ключевых идей CMS. У страницы может быть родительский раздел, вложенные страницы, собственный адрес, статус публикации и набор полей, которые зависят от конкретного проекта.
Например, страница услуги может находиться внутри раздела «Услуги», новость — внутри раздела «Новости», статья базы знаний — внутри раздела «База знаний». Это не порядок ради порядка. От положения страницы могут зависеть адрес, навигация, хлебные крошки, логика раздела и внутренняя структура сайта.
Кроме текста и изображений, у страницы могут быть SEO-поля, настройки отображения, блоки, связанные материалы, кнопки, формы или другие элементы. В одном проекте набор полей может быть простым, в другом — более сложным. Wagtail настраивается под конкретный сайт, поэтому админка не всегда выглядит одинаково.
Важно: если вы меняете текст или изображение — это обычное редактирование. Если вы меняете место страницы в структуре, адрес, статус публикации или удаляете страницу — это уже изменение структуры сайта. Такие действия нужно проверять внимательнее.
Одна из типовых ошибок — воспринимать все действия в админке одинаково. Кажется: раз всё делается в одном интерфейсе, значит, риск примерно одинаковый. На практике это не так.
Обычное редактирование — это когда вы исправляете текст, заменяете изображение, обновляете ссылку, добавляете абзац, меняете подпись или корректируете блок внутри страницы. Такие действия обычно безопаснее, хотя и их стоит проверять перед публикацией.
Изменение структуры — это другой уровень ответственности. К нему относятся создание новой страницы, перемещение страницы в другой раздел, снятие с публикации, удаление, изменение URL, работа с дочерними страницами и изменение важных настроек.
Например, исправить опечатку в описании услуги — обычная редакторская задача. А переместить опубликованную страницу услуги из одного раздела в другой — структурное изменение. Оно может повлиять на адрес страницы, меню, внутренние ссылки и SEO.
Именно здесь часто возникают проблемы. Администратор думает: «Я просто навёл порядок». А сайт в это время получает новые адреса, потерянные ссылки и неожиданные пустоты в навигации. Порядок, конечно, дело хорошее. Но в структуре сайта лучше сначала думать, потом двигать мебель.
В Wagtail новая страница создаётся внутри определённого раздела дерева страниц. Если выбрать неправильную родительскую страницу, новый материал окажется не там, где должен быть.
Например, статью базы знаний можно случайно создать внутри раздела «Услуги», а страницу услуги — внутри старого архивного раздела. В админке она будет существовать, но в структуре сайта появится путаница.
Такая ошибка может повлиять на адрес страницы, отображение в навигации, хлебные крошки и логику раздела. Иногда страница не появляется там, где её ждёт редактор. Иногда, наоборот, появляется в неожиданном месте.
Перед созданием страницы стоит проверить не только название будущего материала, но и раздел, внутри которого вы его создаёте. Особенно это важно на больших сайтах, где есть похожие ветки: «Услуги», «Направления», «Решения», «База знаний», «Блог», «Документы».
Подробный порядок создания страницы лучше смотреть в отдельной инструкции. Здесь главное правило простое: сначала проверьте место в дереве, потом создавайте страницу.
Перемещение страницы в Wagtail может выглядеть как обычное наведение порядка. Но по последствиям это не всегда простое действие.
Если страница уже опубликована, на неё могут вести ссылки из меню, других страниц, поисковой выдачи, рекламных кампаний, писем, PDF-презентаций или внешних сайтов. При перемещении может измениться её место в структуре, а в некоторых проектах — и адрес.
Также нужно учитывать дочерние страницы. Если вы перемещаете не отдельную страницу, а раздел, вместе с ним может переехать целая группа вложенных материалов.
Перед перемещением стоит проверить, где страница находится сейчас, есть ли у неё дочерние страницы, изменится ли URL, участвует ли страница в меню и есть ли на неё важные ссылки. Если страница получает поисковый трафик или используется в коммерческих материалах, перемещение лучше согласовать с ответственным за сайт, SEO-специалистом или разработчиком. Подробнее
Ещё одна распространённая ошибка — создавать новую страницу вместо того, чтобы обновить существующую.
Например, на сайте уже есть страница «Поддержка сайта», но редактор создаёт новую страницу «Техническая поддержка сайта» с почти тем же смыслом. Потом появляется «Сопровождение сайта», «Поддержка и сопровождение» и ещё одна «Комплексная поддержка». В итоге даже сотрудникам компании сложно понять, какая страница главная.
Дублирующие страницы вредят структуре сайта. Пользователь теряется, редакторы обновляют не тот материал, а поисковым системам сложнее понять, какая страница должна отвечать на конкретный запрос.
Перед созданием новой страницы стоит поискать похожие материалы в админке. Если тема уже раскрыта, возможно, лучше обновить существующую страницу, расширить её или изменить угол подачи нового материала.
Новая страница нужна тогда, когда у неё есть самостоятельная задача, отдельная аудитория, отдельный интент или понятное место в структуре сайта.
На сайте с большим количеством материалов легко открыть похожую, но не ту страницу. Особенно если названия отличаются одним словом: «Доставка», «Доставка по России», «Доставка из Китая», «Доставка — старая версия», «Доставка тест».
Ошибка кажется простой, но последствия могут быть неприятными. Администратор меняет текст, публикует страницу, а потом выясняется, что обновилась не та версия. Нужная страница осталась старой, а другая получила чужой текст.
Перед редактированием полезно проверить название страницы, раздел в дереве, URL, статус публикации и вид страницы на сайте. Если есть сомнения, лучше открыть страницу на сайте или посмотреть её через предпросмотр.
Лишняя минута проверки часто экономит час исправлений.
В Wagtail страница часто состоит из блоков. Это могут быть текстовые блоки, изображения, карточки, кнопки, формы, блоки преимуществ, списки связанных материалов, CTA или другие элементы, настроенные под проект.
Проблема в том, что не каждый блок выглядит важным с первого взгляда. Редактор может решить: «Это лишнее, удалю». А потом оказывается, что вместе с «лишним» исчезла кнопка заявки, блок с преимуществами, форма обратной связи или список связанных материалов.
Если непонятно, за что отвечает блок, не стоит удалять его «для чистоты». Лучше сначала посмотреть страницу в предпросмотре, уточнить назначение блока или временно сохранить изменения как черновик.
Особенно осторожно нужно работать с блоками, которые повторяются на важных коммерческих страницах. Иногда они являются частью продуманной структуры: ведут пользователя к заявке, помогают ориентироваться или связывают страницу с другими разделами сайта.
Редакторы часто готовят текст в Word, Google Docs, старом сайте, мессенджере или почте, а потом вставляют его в Wagtail. Само по себе это нормально. Проблема начинается, когда вместе с текстом переносятся лишние стили.
На странице могут появиться разные размеры шрифта, неправильные заголовки, странные отступы, кривые списки, лишние пробелы или невидимое форматирование. В редакторе всё может выглядеть терпимо, а на сайте — уже не очень.
После вставки текста нужно проверить форматирование. Заголовки должны быть заголовками, списки — списками, ссылки — ссылками. Не стоит вручную имитировать дизайн внутри текстового поля, если для этого в проекте предусмотрены отдельные блоки.
Хорошая практика — использовать структуру, заложенную в Wagtail-проекте. Если для цитаты, карточки, предупреждения или CTA есть отдельный блок, лучше использовать его, а не собирать всё вручную в одном текстовом поле.
Копирование страниц может быть удобным. Например, если нужно создать похожий материал с такой же структурой. Но это действие часто переносит старые проблемы в новую страницу.
| Что может скопироваться | Чем это опасно |
|---|---|
| Старые SEO-поля | Новая страница получит неподходящий title или description |
| Устаревшие ссылки | Пользователь попадёт на старые или неправильные материалы |
| Старые изображения | На странице останутся чужие иллюстрации или подписи |
| CTA и кнопки | Заявка может уйти не туда или вести на неподходящий сценарий |
| Лишние блоки | Страница будет перегружена ненужными элементами |
| Неподходящий URL | Адрес страницы может не соответствовать новой теме |
| Внутренние настройки | Новая страница унаследует логику старой |
Копировать страницу можно, но после этого её нужно тщательно очистить и проверить. Важно посмотреть не только видимую часть страницы, но и настройки, SEO-поля, URL, ссылки, изображения и блоки.
Иначе получится не новая страница, а старая в другом пальто. Сайт такое терпит, пользователь — не всегда.
В Wagtail сохранение и публикация — не одно и то же. Это важный принцип, который нужно понять с самого начала.
Редактор может сохранить изменения как черновик, посмотреть их, доработать и только потом опубликовать. Пока изменения не опубликованы, пользователь на сайте может видеть старую версию страницы.
Типовая ситуация: администратор изменил текст, нажал сохранение, открыл сайт и не увидел изменений. Он решает, что «Wagtail не обновляет страницу». На деле изменения могли остаться в черновике.
Бывает и обратная ситуация: редактор хотел просто сохранить промежуточный вариант, но случайно публикует страницу с недописанным текстом, временным заголовком или пометкой «потом допишем». Пользователю не нужно знать, что «Маша потом вставит нормальную картинку».
Перед нажатием кнопки публикации нужно понимать, какое действие вы выполняете: сохраняете черновик, отправляете на проверку, публикуете или обновляете уже опубликованную страницу.
Предпросмотр нужен не для красоты. Он помогает увидеть страницу до того, как её увидят пользователи.
В редакторе страница может казаться нормальной, но на сайте проявятся проблемы: слишком длинный заголовок, неправильное изображение, пустой блок, сломанный список, неработающая ссылка, лишний отступ или временный текст.
Перед публикацией стоит проверить первый экран, заголовки, изображения, ссылки, блоки, формы, кнопки и общий вид страницы. Если есть возможность, полезно посмотреть страницу на мобильном экране, особенно если это важная страница услуги, посадочная страница или материал для рекламы.
Не каждая правка требует большой проверки. Но чем важнее страница, тем внимательнее должен быть предпросмотр. Особенно это касается главной страницы, страниц услуг, разделов с заявками и материалов, которые идут в рекламу или рассылку.
Если со страницами работает несколько человек, могут возникать конфликты. Один редактор подготовил черновик, второй изменил блок, третий опубликовал старую версию, четвёртый потом пытается понять, кто сломал страницу. Обычно все «ничего не трогали». Это древняя традиция любой админки.
Чтобы избежать таких ситуаций, нужны простые правила: кто отвечает за раздел, кто вносит изменения, кто проверяет страницу, кто имеет право публиковать и где фиксируются важные правки.
Wagtail подходит для командной работы, но сама CMS не заменяет редакционный процесс. Если несколько человек работают с одним разделом, лучше заранее определить ответственность, чем потом восстанавливать историю по обрывкам переписки.
Скрытие страницы из меню, снятие страницы с публикации и удаление страницы — разные действия.
В зависимости от настроек проекта страница может не отображаться в навигации, но продолжать открываться по прямой ссылке. Это важно понимать, если материал больше не должен быть доступен пользователям.
Например, страница акции, старого тарифа, временного предложения или внутреннего раздела может исчезнуть из меню, но остаться доступной по URL.
Перед тем как считать страницу «убранной с сайта», нужно проверить, что именно было сделано: она скрыта из меню, снята с публикации, удалена или просто перемещена.
Если задача — временно убрать страницу из навигации, скрытие может быть подходящим вариантом. Если задача — сделать страницу недоступной для пользователей, нужно проверять статус публикации и настройки конкретного проекта.
Удаление — крайнее действие. Его не стоит использовать каждый раз, когда страница временно не нужна или требует переработки.
Если материал устарел, но может пригодиться позже, безопаснее снять страницу с публикации, заменить содержимое, скрыть из меню или подготовить новую версию. Удаление стоит применять тогда, когда понятно, что страница действительно больше не нужна и её удаление не создаст проблем.
Важно: не удаляйте опубликованную страницу только потому, что она временно не нужна. Сначала проверьте ссылки, трафик, дочерние страницы и возможную замену.
Перед удалением опубликованной страницы нужно проверить, есть ли на неё ссылки с других страниц, попадает ли она в меню, есть ли у неё поисковый трафик, используется ли URL в рекламе, рассылках или документах, есть ли у неё дочерние страницы и нужна ли замена или редирект.
Если удалить страницу без проверки, пользователи могут попасть на ошибку, а команда — получить срочную задачу по восстановлению. И, как обычно, срочная задача появится в пятницу вечером. Сайты обладают врождённым чувством драматургии.
В Wagtail дерево страниц работает как структура. Если у страницы есть дочерние страницы, удаление может затронуть не один материал, а целый раздел.
Например, у страницы «База знаний» могут быть вложенные категории и статьи. У страницы «Услуги» — отдельные услуги. У страницы «Документы» — подразделы и файлы. Если удалить родительскую страницу, последствия могут оказаться шире, чем ожидалось.
Перед удалением нужно проверить, есть ли у страницы дочерние материалы. Если есть, важно понять, что с ними должно произойти: их нужно сохранить, переместить, снять с публикации, заменить или удалить вместе с разделом.
Хорошее правило: если вы не уверены, удаляете страницу или целую ветку, остановитесь и проверьте структуру. Дерево страниц удобно именно потому, что показывает связи. Им нужно пользоваться.
Если каждый пользователь может редактировать, удалять, перемещать и публиковать любые страницы, риск случайных изменений растёт. Не потому что сотрудники плохие или невнимательные. Просто система без ограничений рано или поздно провоцирует ошибку.
Права доступа лучше выдавать по роли и зоне ответственности. Одному сотруднику достаточно редактировать новости. Другому — страницы базы знаний. Третьему — проверять и публиковать материалы. Полные права администратора нужны не всем.
Это особенно важно для сайтов, где работают разные отделы: маркетинг, HR, продажи, редакция, поддержка, руководство. Чем больше людей в админке, тем важнее разграничение прав.
Слишком широкие права часто выдают не потому, что так правильно, а потому что «так быстрее». Но потом это «быстрее» превращается в вопрос: «Кто это опубликовал?»
Wagtail позволяет выстраивать работу с пользователями и группами, но конкретная настройка зависит от проекта. Если права сейчас выданы слишком широко, стоит обсудить их пересмотр с разработчиком или администратором системы.
Ещё одна частая ошибка — отсутствие ответственного за итоговую страницу. Один сотрудник пишет текст, второй загружает изображения, третий правит заголовок, четвёртый публикует. Потом выясняется, что на сайте опубликована не финальная версия.
Для небольшого сайта это может казаться лишней формальностью. Но как только страниц становится больше, без правил начинается путаница.
Минимальный порядок может быть простым: один человек готовит текст, другой проверяет смысл, третий следит за оформлением, ответственный администратор публикует страницу, а владелец раздела проверяет результат после публикации.
Это не бюрократия ради бюрократии. Это способ избежать ситуации, когда все участвовали, но никто не отвечает.
Если на сайте меняют структуру, URL, статус публикации или удаляют страницы, такие действия лучше фиксировать. Хотя бы в задаче, таблице, CRM или рабочем чате.
Это помогает, когда нужно понять, почему страница пропала из меню, почему старая ссылка перестала работать или кто изменил важный раздел.
Не нужно превращать работу с сайтом в архив Министерства всего на свете. Но важные изменения должны оставлять след. Особенно если сайт влияет на заявки, продажи, поддержку клиентов или поисковый трафик.
Простая запись «сняли с публикации старую страницу услуги, заменили ссылкой на новую» может сэкономить много времени при разборе проблемы.
Если каждый пользователь может редактировать, удалять, перемещать и публиковать любые страницы, риск случайных изменений растёт. Не потому что сотрудники плохие или невнимательные. Просто система без ограничений рано или поздно провоцирует ошибку.
Права доступа лучше выдавать по роли и зоне ответственности. Одному сотруднику достаточно редактировать новости. Другому — страницы базы знаний. Третьему — проверять и публиковать материалы. Полные права администратора нужны не всем.
Это особенно важно для сайтов, где работают разные отделы: маркетинг, HR, продажи, редакция, поддержка, руководство. Чем больше людей в админке, тем важнее разграничение прав.
Слишком широкие права часто выдают не потому, что так правильно, а потому что «так быстрее». Но потом это «быстрее» превращается в вопрос: «Кто это опубликовал?»
Wagtail позволяет выстраивать работу с пользователями и группами, но конкретная настройка зависит от проекта. Если права сейчас выданы слишком широко, стоит обсудить их пересмотр с разработчиком или администратором системы.
Ещё одна частая ошибка — отсутствие ответственного за итоговую страницу. Один сотрудник пишет текст, второй загружает изображения, третий правит заголовок, четвёртый публикует. Потом выясняется, что на сайте опубликована не финальная версия.
Для небольшого сайта это может казаться лишней формальностью. Но как только страниц становится больше, без правил начинается путаница.
Минимальный порядок может быть простым: один человек готовит текст, другой проверяет смысл, третий следит за оформлением, ответственный администратор публикует страницу, а владелец раздела проверяет результат после публикации.
Это не бюрократия ради бюрократии. Это способ избежать ситуации, когда все участвовали, но никто не отвечает.
Если на сайте меняют структуру, URL, статус публикации или удаляют страницы, такие действия лучше фиксировать. Хотя бы в задаче, таблице, CRM или рабочем чате.
Это помогает, когда нужно понять, почему страница пропала из меню, почему старая ссылка перестала работать или кто изменил важный раздел.
Не нужно превращать работу с сайтом в архив Министерства всего на свете. Но важные изменения должны оставлять след. Особенно если сайт влияет на заявки, продажи, поддержку клиентов или поисковый трафик.
Простая запись «сняли с публикации старую страницу услуги, заменили ссылкой на новую» может сэкономить много времени при разборе проблемы.
Представим обычную ситуацию. Компания обновляет раздел услуг. Администратор находит старую страницу, решает, что она больше не нужна, и снимает её с публикации. Или удаляет, потому что «чего ей висеть».
На первый взгляд всё логично. Старую страницу убрали, порядок навели.
Через некоторое время выясняется, что на эту страницу вели ссылки из меню, нескольких статей, старой PDF-презентации, рекламного объявления и поисковой выдачи. Пользователи переходят по ссылкам и не находят нужную информацию. Часть попадает на ошибку, часть уходит с сайта.
Дальше начинается срочное восстановление. Нужно понять, что удалили, была ли копия, куда вели ссылки, есть ли новая страница, нужен ли редирект, что делать с рекламой и как объяснить ситуацию руководителю.
Проблема возникла не потому, что Wagtail плохой. Проблема в том, что действие казалось локальным, а на деле затронуло структуру сайта.
Перед удалением, снятием с публикации, перемещением или изменением URL нужно проверять роль страницы. Особенно если страница опубликована давно, участвует в меню, получает трафик или используется в коммерческих материалах.
Перед обычной правкой текста не всегда нужен большой чек-лист. Но если вы меняете важную страницу, её статус, место в структуре или адрес, проверка обязательна.
| Что проверить | Почему это важно |
|---|---|
| Правильную ли страницу вы открыли | Чтобы не изменить похожую, но другую страницу |
| В каком разделе она находится | Чтобы понимать её место в структуре сайта |
| Опубликована ли страница | Чтобы понимать, видят ли её пользователи |
| Есть ли дочерние страницы | Чтобы не затронуть целый раздел |
| Изменится ли URL | Чтобы не сломать старые ссылки |
| Есть ли ссылки на страницу | Чтобы пользователи не попадали на ошибку |
| Нужно ли обновить SEO-поля | Чтобы страница не потеряла смысл в поиске |
| Кто отвечает за публикацию | Чтобы избежать случайных изменений |
| Нужно ли обращаться к разработчику | Чтобы не пытаться решить техническую задачу через редактор |
Чем важнее страница, тем внимательнее проверка. Главная страница, страницы услуг, посадочные страницы, разделы заявок, документы и материалы с поисковым трафиком требуют особенно аккуратной работы.
Если сомневаетесь, лучше сохранить изменения как черновик, показать ответственному и только потом публиковать. Это дольше на несколько минут, но спокойнее для всех.
Администратор Wagtail может многое делать самостоятельно: менять тексты, изображения, ссылки, блоки, публиковать материалы, снимать страницы с публикации, работать с доступными SEO-полями.
Но не все задачи относятся к обычному администрированию. Иногда требуется разработчик.
К разработчику стоит обращаться, если нужно изменить тип страницы, добавить новый блок, изменить шаблон, настроить поведение меню, восстановить удалённую страницу, разобраться с ошибками после перемещения или удаления, настроить редиректы, изменить права пользователей или проверить влияние изменений на формы и интеграции.
Также разработчик нужен, если задача звучит примерно так: «Мы хотим, чтобы эта страница работала по-другому». Не просто текст другой, не просто картинка другая, а именно поведение, структура, логика или набор возможностей.
Например, администратор может обновить текст на странице услуги. Но если для новой услуги нужен другой шаблон, калькулятор, форма заявки, связанный список статей или особая логика отображения — это уже задача разработки.
Поддержка Wagtail-сайта нужна не потому, что администратор «не справился». Просто часть задач действительно находится за пределами редакторской работы. Хорошая CMS даёт удобную админку, но не отменяет проектирование, разработку и техническое сопровождение.
Скорее всего, изменения сохранены как черновик, но не опубликованы. Также возможно, что вы редактировали не ту страницу или сайт показывает старую версию из-за настроек обновления или кэширования.
Проверьте статус страницы в Wagtail, откройте предпросмотр и убедитесь, что изменения действительно опубликованы.
Можно, но осторожно. При копировании могут перенестись старые SEO-поля, ссылки, изображения, CTA, блоки, настройки и неподходящий URL.
После копирования страницу нужно не только переписать, но и очистить от всего, что относилось к старому материалу.
Часто да. Скрытие из меню не всегда означает, что страница снята с публикации. Она может продолжать открываться по прямой ссылке.
Если страницу нужно полностью убрать с сайта, проверьте её статус публикации и настройки конкретного проекта.
Оба действия могут иметь серьёзные последствия.
Перемещение может изменить место страницы в структуре, навигацию и иногда URL. Удаление может полностью убрать страницу и затронуть вложенные материалы. Важно смотреть не на само действие, а на роль страницы в сайте.
Нет. Обычные текстовые правки, замена изображений и небольшие изменения контента обычно можно делать самостоятельно.
К разработчику стоит обращаться, если меняется структура, URL, шаблон, тип страницы, логика блоков, меню, формы, права доступа или поведение страницы.
Это зависит от настроек проекта, прав доступа, резервных копий и того, как именно была удалена страница.
Не стоит рассчитывать на восстановление как на обычный рабочий сценарий. Лучше перед удалением проверить страницу, её вложенные материалы, ссылки и возможные последствия. Удалять проще, чем потом спокойно объяснять, почему важная страница исчезла.
