Content-Managed Program Websites

Many of the websites I develop support programs that need more than a collection of static pages, but do not require the application architecture of a larger integrated platform.

These projects use Wagtail to give nontechnical staff control over website content while Django provides the underlying application framework. Rather than building each page independently, I develop reusable content types and components that allow editors to create and maintain pages within a consistent design system.

The goal is to balance editorial flexibility with structure. Content managers should be able to make routine updates without developer involvement, while the website continues to provide consistent presentation, responsive behavior, accessibility, and maintainable underlying code.

A significant part of the development work involves deciding which information should be treated as structured data rather than simply entered into a rich-text editor.

Reusable Wagtail components can represent common patterns such as cards, calls to action, images, project information, maps, news, and other program-specific content. Editors can combine these components to build pages without needing to understand HTML or the underlying frontend implementation.

Where information appears in multiple places, it can be maintained once and reused throughout the site. Structured content types can also generate listings and related content automatically, reducing the need to manually update several pages when information changes.

This approach provides editors with meaningful flexibility while allowing the application to enforce the parts of the design and content structure that should remain consistent.

Accessibility is incorporated into both the frontend implementation and the content-management experience rather than treated solely as a final testing step.

Templates and reusable components provide semantic HTML, logical heading structures, keyboard-accessible controls, appropriate image handling, descriptive links, responsive layouts, and visible focus behavior. WCAG 2.2 AA serves as the general accessibility target.

The CMS can also help prevent accessibility problems before content is published. Wagtail's accessibility checking and carefully designed editing interfaces give content managers feedback while limiting the need to manually reproduce complex markup.

Automated accessibility scans provide another layer of review after deployment, helping identify issues introduced as website content changes over time.

Not every editorial requirement fits naturally into a generic page editor, so these websites often include custom CMS functionality designed around the way content managers actually work.

Examples include interactive geographic maps whose highlighted regions and related content can be managed through Wagtail, structured project databases that automatically populate project listings, shared site-wide content, and reusable page components tailored to individual programs.

Editorial tools can also include draft sharing for review outside the CMS, broken-link auditing, search tools, and the ability to revert unpublished changes.

These features are implemented as part of the application rather than relying on content managers to assemble equivalent functionality manually on individual pages.

Public websites need ongoing safeguards beyond their visible content and design.

Consent-aware integrations allow analytics and third-party services to respect visitor privacy choices. Application-level protections can reject common automated requests for sensitive files and resources, while framework and dependency updates provide an additional layer of routine security maintenance.

Automated broken-link and accessibility scans help identify problems introduced as content evolves, while structured templates reduce the number of ways routine editorial changes can inadvertently affect the site's usability.

The objective is not simply to meet requirements at launch, but to make accessibility, privacy, and security easier to preserve as the website is maintained.

These websites are maintained as long-lived applications rather than delivered as static builds and left unchanged.

Development, staging, and production environments support review and testing before changes are released. Automated tests help protect application behavior, while database backups, logging, dependency maintenance, and deployment tooling support ongoing operation.

Static assets and uploaded media can be served through cloud storage and content delivery infrastructure, while the application itself and PostgreSQL database are deployed independently of those files.

This infrastructure allows both the software and the website's content to evolve without requiring the site to be rebuilt whenever program requirements change.

A successful CMS implementation has two audiences: the people visiting the website and the people responsible for keeping it accurate.

Many development decisions therefore happen behind the administrative interface. Field labels, help text, validation, available content components, preview behavior, shared content, and page relationships all influence whether the site remains manageable several years after launch.

The goal is not to provide editors with unlimited control over presentation. It is to give them control over the information they are responsible for while allowing the application to handle presentation, accessibility, responsive behavior, and other technical concerns consistently.