WordPress or Wagtail for your website redesign
Published

A website redesign also means organising content and making it easier to manage. Compare WordPress and Wagtail against your editing, integration and maintenance needs.
The choice between WordPress and Wagtail often arises when a website has become difficult to maintain. Pages have been built in different ways, content is duplicated and small changes require too many checks. A new look seems like the immediate answer, but these difficulties deserve attention too.
Before changing technology, understand where they come from. A poorly configured CMS, a confusing editorial structure and a project that has grown without direction can produce similar symptoms. Migrating everything without distinguishing them risks moving the same disorder into another dashboard.
Both tools can be part of a professional project. The choice depends on the content, the team's work and the functionality that needs to coexist with the website.
WordPress or Wagtail for editorial work
WordPress provides a familiar starting point for publishing content and extending a website through themes and plugins. It can be a very good fit for a corporate website, a blog or a set of pages with functionality the team already knows how to maintain.
Wagtail integrates into Django projects and lets you define a content structure suited to the website. It requires development to turn that foundation into a specific site. It is worth considering when publishing forms part of a platform with its own data models or processes.
The distinction is not “WordPress only has pages and Wagtail has data”. WordPress also supports custom content types. What you need to compare is how your required structure will be implemented and the effort involved in maintaining it.
A useful exercise is to ask a team member to publish representative content using the proposed dashboard. Consider how much they understand without help, what they could accidentally break and how many times they must enter the same information.
Define the content before the layout
Imagine a website with services, professionals and case studies. If every page repeats that data manually, correcting a job title or linking a project can require several edits. A clear content model lets you maintain information in the right place and reuse it on the pages that need it.
Wagtail offers StreamField, a system through which developers define content blocks that editors can combine. Its usefulness depends on those blocks being well designed: too many variations can make editing complicated again.
Visual freedom should serve a purpose. If publishers must choose from dozens of options to add a case study, the dashboard is passing them design decisions they probably should not have to make every time.
During a redesign, take time to decide which elements are different, what information they share and which relationships you need. That structure will often outlast a particular homepage composition.
The ecosystem helps and creates dependencies
A tool's extension catalogue can save development work, provided the feature fits and there is a reasonable way to maintain it. You do not need to build your own feature simply because it is technically possible.
Each extension also introduces a dependency. Find out who maintains it, whether it covers the whole requirement and what happens when it is updated alongside the rest of the site. Problems often arise when several components overlap or rely on undocumented behaviour.
Wagtail projects also have dependencies and maintenance. Using Django does not remove updates or automatically make an implementation simpler. The team should be able to explain why the architecture suits your website and who will support its evolution.
If the company already has a Django application, sharing technology can make technical work easier. That does not mean the public website and all business operations must live in one deployment: the separation depends on how they are used and maintained.
Performance and security need a concrete proposal
I would not consider speed settled by the name of the CMS. Images, queries, frontend resources, caching and hosting all contribute to the result. A simple page can perform poorly with a careless implementation in either tool.
Ask for the assessment to include real pages, a representative amount of content and mobile browsing. An empty demonstration homepage may hide what will happen on a listing, a search or an image-heavy page.
Security also needs clear responsibilities: who updates, which access each person retains, how changes are tested and how a backup is restored. A platform with fewer extensions may simplify certain tasks, but that does not replace well-maintained operations.
The useful comparison is between two complete proposals. One that includes updates and verified recovery does not offer the same thing as another whose maintenance is yet to be defined.
Redesigning also means preserving
Before moving content, identify which pages remain useful, which URLs receive visits and which forms or integrations the business needs. Decide what to retain, combine and retire.
The inventory should include images, documents, languages and relationships between pages. It is also worth identifying duplicates and outdated content. Importing them without review can give the new website much of the old site's debt from the start.
If addresses change, prepare a mapping from old URLs to their destinations. Migration requires checking links, forms and navigation as well as visual design. A CMS change should not be presented as an automatic improvement in search visibility.
The Bàsquet Manresa project shows a redesign that brings together club information and automates data updates. It illustrates a website's operational role alongside its visual presentation. The public case does not identify a migration from WordPress and should not be read as evidence of one.
Multiple languages add editorial work
A multilingual website needs more than a selector. The team must understand how versions relate, which content awaits review and how shared information is updated when the original changes.
Test that journey before approving the solution. Change a text in the source language and check how the need to review the others is shown. Also verify that a translation can use a natural expression without losing its relationship with the equivalent page.
Automated tools can support some of that work, but figures, quotations and commercial terminology need review. Consistency matters particularly when different languages describe the same service or result.
Cost, team and continuity
WordPress can reduce initial work when the scope fits an existing foundation. Wagtail requires development to configure content and presentation, and may suit projects where that adaptation accounts for a substantial part of the work.
Compare what each proposal includes: design, migration, content entry, languages, testing and maintenance. If one covers all of that and another only the new website, the price difference says little.
For a straightforward corporate website that the team manages well, retaining WordPress may be a sensible decision. If the structure and integrations call for custom development, it is worth assessing a Wagtail project. The change needs a reason that remains valid after launch.
A website redesign works when publishing becomes clearer and the company can sustain the site without relying on improvised solutions. The CMS contributes to that outcome, but structure, the editing experience and maintenance remain part of the project's work.