A nonprofit website often decides whether people trust the organization. Donors look for proof of credibility. Funders review programs and results. Partners look for data they can rely on. For many visitors, the website is the first contact with the organization. When the experience feels slow or crowded, confidence drops.
A well-known nonprofit organization in the United States ran into this problem during a major web update. The organization supports the sector with nonprofit information, research, and resources used by funders, foundations, and practitioners. With that level of visibility, the website had to be fast, reliable, and easy for staff to maintain.
Over time, the organization ended up running two separate sites. The main site lived on the primary domain. The blog, with a large archive, lived on a separate subdomain. Keeping them separate made life harder for visitors and staff. Content felt split, search results competed with each other, and publishing workflows got messy. The team decided to bring everything under one domain. That decision started as consolidation, then turned into a full rethink of how the site should work.
Why consolidation helps
Multiple domains are common in large nonprofits. Campaign sites, old program pages, and long running blogs tend to build up. The downside builds up too. Search performance gets split across domains. Visitors are unsure where to look. Staff spend time on tooling and workarounds instead of content.
The leadership team set a focused set of goals:
- Move the blog under the main domain
- Migrate more than 1,000 articles while protecting search performance
- Make publishing easier for editors
- Meet accessibility requirements for all audiences
- Improve security across the stack
- Connect forms to Salesforce and Pardot
Many nonprofits aim for the same results. The details of how this project handled them are what make it useful.
Templates built around real content
Early work focused on page templates that matched what the team actually published. Four templates covered most needs:
- Standard pages for blog posts, press releases, and general content
- Product pages for listings and pricing
- Guide pages with jump links so readers could move to sections quickly
- Labs pages for research and experimental work
Author profiles and blog listings were added to support editorial flow. This gave editors structure while still letting them publish different kinds of content without starting from scratch each time.
For nonprofits planning a redesign, the takeaway is practical. Identify the page types you publish most, then design those templates carefully. Templates keep layouts consistent and reduce editing time on every update.
Migrating a blog that kept changing
The blog migration was the hardest part. The archive held more than 1,000 posts built up over years. While the migration was in progress, editors kept publishing new posts on the old blog. The archive changed daily.
A one time migration would miss new posts. To avoid that, the development team built a small WordPress plugin called Easy Content Push. It let editors move only the newest posts into the new site without rerunning the full migration.
This avoided a content freeze and saved weeks of repetitive work. For nonprofits with long publishing histories, it is a strong example of how a small custom tool can remove a major bottleneck.
A late framework change
During development, the team reviewed the site build to improve search and performance. With a large archive, server rendered pages tend to be indexed more reliably than pages that rely heavily on client side rendering.
Late in the build, the team chose to rebuild the front end in Next.js. This improved how pages were served and indexed. Static generation allowed pages to be built ahead of time and cached, so visitors got fast page loads. When editors updated content in WordPress, the public site could regenerate automatically.
Even with the timing, the teams coordinated the rebuild and still met launch goals. The lesson for nonprofit leaders is straightforward. A hard call late in a project can protect search and performance for years.
Keeping publishing familiar for staff
The final setup used WordPress for content editing and Next.js for the public site. They ran separately and connected through APIs. Editors stayed in WordPress. Visitors got a fast site that stayed stable even when editors were working in the CMS.
This approach works well for teams that want modern performance without forcing staff into a new editing tool.
Search across the whole site
Visitors can now search across the entire site from one search box. Results include pages, blog posts, press releases, and news content. This replaced the older split experience across domains and helped people find what they needed faster.
For nonprofits with big archives, site wide search affects trust and engagement. People leave when they cannot find information quickly.
Accessibility treated as a requirement
Accessibility was planned from the start. Templates and interactions were tested against WCAG 2.2 AA. Automated checks were combined with manual testing. The delivery team and internal staff reviewed the site before launch.
The result was a site that more people could use without barriers.
Security built into delivery
Security work included two-factor authentication, restricted API access, and active monitoring. Backups and security updates were planned from the beginning. This protects donor trust and reduces operational risk.
What this project shows
Across the work, several choices stood out:
- One domain reduced confusion and brought search authority together
- Templates improved consistency and editor speed
- A small plugin handled ongoing publishing during migration
- Next.js improved search indexing and performance for a large archive
- Accessibility and security stayed in scope from day one
- Newsletter forms connected to Salesforce and Pardot
- Editors kept control over publishing
Together, these decisions produced a site built for growth, reliability, and day to day use by staff.
Pactical takeaways for other nonprofits
- Consolidate domains where possible so people know where to go
- Design templates around real publishing patterns
- Treat migration as its own workstream with time and ownership
- Make performance and search part of the build plan, not a late fix
- Keep accessibility and security in scope from day one
- Connect forms to CRM and email tools so leads flow without manual steps
- Add site-wide search so users can find content across the archive
Closing thought
After the redesign, the organization had one site to run, one place for content, and a setup that supported ongoing publishing without extra work for staff. The work described here reflects real delivery under real constraints, including scale, long running content, accessibility needs, and strict data handling.
If you are planning a similar rebuild and want to understand how this was delivered in practice, we can walk through the approach, the tradeoffs, and the decisions made along the way in a direct conversation