Almost every "should we redesign?" conversation I join starts in the wrong place. Someone shows the homepage, someone says it looks dated, someone else says the last redesign was five years ago, and within ten minutes the group is discussing agencies and budgets. Nobody has yet established whether the thing that is actually broken is the design, the platform, the content, or the fact that no one has been allowed to edit the site since 2023.
Those four problems carry wildly different price tags. Getting the diagnosis right is worth more than getting the vendor right, and unlike the vendor decision, you can do the diagnosis yourself in about twenty minutes.
01 · Three doors, not twoRefine, replatform, rebuild: pick the smallest one that works.
"Revise or rebuild" is a false binary that pushes organizations toward the expensive option, because "revise" sounds like doing nothing while "rebuild" sounds like taking it seriously. The missing middle is replatforming, and in my experience it is the correct answer more often than either extreme.
Refine
Improve in place. Content rewrites, navigation changes, template fixes, performance work, accessibility remediation, conversion tuning. No migration, no new platform, no blank page.
Replatform
Move the foundation, keep the thinking. Same content, same information architecture, mostly the same design intent, rebuilt on a supported and maintainable platform your team can actually use.
Rebuild
Start from strategy. New audience model, new information architecture, new content, new design, new platform. The full sequence, in that order.
The reason replatforming gets overlooked is a misunderstanding about where website cost lives. The expensive part of a website project is almost never the code. It is deciding what the site should say, who it is for, and how it should be organized. If those decisions are still right, you do not need to pay to make them again. Carry them across and spend the money on the foundation.
02 · The distinction that decides itStructure and surface fail differently.
Nine dimensions matter, and they split cleanly into two groups. The split is not about importance, it is about whether the problem can be fixed without touching the foundation.
Structural: you cannot edit your way out of these
- Platform and infrastructure. Is your CMS current and supported? Can you get security updates? Is there a market of people who can maintain it, or one retiring contractor?
- Security. HTTPS everywhere, patched dependencies, sensible authentication, a plan for the day something goes wrong.
- Content model. Can staff create a new program page without a developer? Can a piece of content appear in two places without being copied? This is the most under-diagnosed dimension on this list.
- Accessibility foundation. Semantic markup, focus states, keyboard operation, contrast tokens. Template-level accessibility is structural. Missing alt text is not.
Surface: painful, visible, and usually fixable in place
- Design and brand. Whether it looks like you, and whether it looks current.
- Navigation and UX. Whether people can find the thing they came for.
- Content quality. Whether the words are accurate, current, and written for the reader.
- Performance. Load speed, especially on a phone on a mediocre connection.
- Findability. Search visibility, and now whether answer engines can quote you.
Here is why the split matters in practice. A site can score badly on every surface dimension and still be a refine, because all five are editable. A site can look perfectly fine and still be a rebuild, because the content model has calcified to the point where nobody has published anything in eighteen months. Averaging all nine into one number hides exactly the information you need.
Before you look at a single design reference, answer one question: can a staff member publish a new program page today, alone, without breaking anything? If the answer is no, you have a structural problem, and no amount of visual redesign will solve it.
03 · The diagnosticScore nine dimensions. Get a real verdict.
Answer honestly rather than diplomatically. The model weights the four structural dimensions separately from the five surface ones, and the verdict comes from the relationship between the two scores rather than from a single average. The logic is explained under the result so you can argue with it, which you should.
Refine, replatform, or rebuild?
Nine dimensions, four levels each. About twenty minutes if you check a few things as you go, three minutes if you already know. Everything runs in your browser and nothing is sent anywhere.
Your verdict will appear here, with the reasoning behind it and a recommended sequence. The model looks at structural and surface health separately, because a site can be ugly and healthy, or handsome and unmaintainable.
Score the dimensions above and your three weakest, with what to do about each, will be listed here.
One caution about the result. The diagnostic tells you what the site needs. It does not tell you what your organization can absorb this year. A correct rebuild verdict during a leadership transition or a capital campaign is still the wrong project to start. In that case take the refine actions now, protect the structural dimensions from getting worse, and plan the bigger move for a window where the organization can actually make decisions.
04 · Both errors are expensiveThe two ways this decision goes wrong.
Rebuilding when you should have refined
In the projects I get called into, this is the more common and more expensive error. A rebuild consumes staff attention for months, resets your search history, and frequently launches with less content than the site it replaced because nobody budgeted for migration. Worst of all, it postpones the fixes that would have helped: the mobile donation flow, the eligibility page nobody can find, the accessibility failures sitting in your templates.
The tell is a project justified by appearance and calendar age rather than by a capability the site cannot deliver. Around 25% of nonprofits plan a redesign within two years. The survey does not ask why, but in my experience a good number of those projects are driven by the calendar rather than by a problem.
Refining when you should have rebuilt
The less common error, and it fails quietly. You spend two years making incremental improvements on a foundation that cannot support them, each fix costing more than the last because the platform fights you. The signal is a rising ratio of effort to result: work that would take a day on a healthy site takes a week, and the team stops proposing improvements because they know what the answer will be.
The other tell is security. An unsupported CMS is not a deferred cost, it is an accumulating liability, and nonprofits hold exactly the kind of data that makes a breach a mission problem rather than an IT problem.
View as table
| Measure | % |
|---|---|
| WordPress.org | 55% |
| Squarespace | 7% |
| Wix | 6% |
| Drupal | 2% |
| Plan a redesign within two years | 25% |
| Have designed for visual and hearing impairments | 26% |
Justify the project with a capability, not an adjective. "We cannot publish a program page without a developer" is a fundable reason. "It looks tired" is a reason to fix the design, which is a fraction of the cost and a fraction of the risk.
05 · Whatever the verdictSequence the work so nothing gets orphaned.
Three sequencing rules apply regardless of which door you go through, and each one prevents a specific failure I see repeatedly.
Content decisions come before design decisions
Design against real content or you will design against optimism. If I had to name one thing that puts a website project behind schedule, it is content that is still being written when the build is finished. Do the content inventory first, decide what dies, and write the important pages before anyone opens a design tool.
Fix the mobile giving path before anything decorative
The 2026 M+R Benchmarks make this unavoidable. Mobile is 52% of nonprofit website traffic but only 28% of revenue, and mobile donation pages convert at 8% against desktop's 11%, dropping to 4% for small organizations. That gap is one of the largest pools of recoverable value on a nonprofit site, and it tends to be a form problem rather than a design problem.
Build accessibility into the templates, not into a remediation phase
The 2026 WebAIM Million found 95.9% of home pages with detectable WCAG failures, averaging 56.1 errors per page, and both numbers got worse year over year. Six failure types account for 96% of errors, and almost all of them are template-level decisions: contrast, form labels, empty links and buttons. Fix them once in the template and they stop recurring. Fix them page by page and you will be doing it forever.
06 · Making the decision stickThe playbook, by role.
Your job is to keep the decision anchored to capability rather than taste, and to protect the organization from a project it cannot absorb.
Write the one sentence before you write the RFP
"By next June we need to be able to ______, and today we cannot." If you cannot finish that sentence with something concrete, you are not ready to scope a project. That sentence also becomes the acceptance criterion, which is the thing most nonprofit website contracts are missing.
Bring structural and surface scores to the board separately
A single "our website scores 62" invites a debate about taste. Two numbers invite a decision: the foundation is at 40 and the surface is at 75, therefore we are replatforming and keeping the content. Board conversations improve immediately when the diagnosis is legible.
Check the organizational window, not just the site
A correct rebuild verdict is still the wrong project during a leadership change, a capital campaign, or a merger, because a rebuild is mostly a decision-making project. Take the refine actions, stop the structural decline, and schedule the larger move for a window when people can decide.
Your job is to ask the three questions that separate a real proposal from an expensive one.
"What can we not do today that this lets us do?"
If the answer is about appearance, the project is a design refresh and should be priced as one. If the answer is "staff cannot publish without a developer" or "we cannot take a recurring gift on a phone", you are looking at a real capability gap.
"Who maintains this in year three, and what does that cost?"
Websites are operating expenses wearing a capital expense costume. Ask for the annual maintenance figure alongside the build figure. A cheap build on an exotic platform often ends up the most expensive option, and it usually presents as the thriftiest.
"What happens to our existing content and search history?"
Ask specifically about content migration and URL redirects. Sites that launch without a redirect map lose accumulated search visibility overnight, which is expensive and entirely avoidable. Organic search still accounts for 39% of nonprofit site visits, so there is real ground to lose.
Your job is the content inventory, and it starts before any vendor is selected.
Inventory everything into keep, rewrite, or kill
Every URL, with traffic and last-updated date beside it. Most nonprofit sites can retire a surprising share of their pages with no loss, and doing this first shrinks every subsequent estimate you receive. It is also the single most useful artifact you can hand a vendor.
Write your ten most important pages before design starts
Real content, not lorem ipsum and not a promise. Designing against actual words surfaces structural problems early, when they are cheap, rather than at launch, when they are not.
Own the redirect map personally
Old URL to new URL, every row, signed off before launch. This gets delegated and then dropped more often than any other launch task, and it is the one whose absence you feel for a year afterward.
Your job is to establish whether the foundation is genuinely failing or merely unfamiliar.
Separate "old" from "unsupported"
A mature platform on a current version with patched dependencies is not a problem, it is an asset. An unsupported version, an abandoned theme, or a plugin stack nobody can update is a different situation. Document which one you actually have before anyone recommends a migration.
Count how many people can maintain this
If the honest answer is one contractor or one staff member, that is a structural risk regardless of how the site performs today. A maintainable platform with a real labor market beats a technically elegant one that only your developer understands.
Fix accessibility at the template layer
Contrast, form labels, empty links, empty buttons, missing alt text, and missing document language account for 96% of detected failures across the WebAIM Million. Most are template decisions. Fix them once in the components and they stop recurring on every new page.
Get a second opinion before you scope the project.
We will run the diagnostic with you, look at what your team can actually maintain, and tell you plainly which of the three doors you are standing in front of. If the answer is refine, we will say so, and that conversation costs nothing.
Sources and method: CMS share, redesign planning, and accessibility design figures from the 2026 Nonprofit Tech for Good report, as compiled in Nonprofit Tech for Good's 2026 website statistics. Traffic, conversion, and mobile revenue figures from M+R Benchmarks 2026. Accessibility failure rates from the 2026 WebAIM Million, an automated analysis of the top one million home pages. The three-door model, the structural and surface split, and the weighted diagnostic are Socient's own, developed across client engagements. This is an independent article.