withMission.techStart a conversation
Guide · Nonprofit web design

Planning a Nonprofit Website Redesign? Review What You Have First

A nonprofit website redesign almost never starts with evidence. It starts with a feeling: the site looks dated, a board member said so, the donate button is buried, nobody can update the events page without asking the person who built it. All of that may be true. None of it tells a designer what the site needs to do.

The argument of this guide is narrow and, we think, hard to escape: the most valuable thing you can do before hiring a designer, an agency, or a website builder is find out what your current site actually does. Not how it looks. What a visitor is asked to do on it, where they stop, what data each form creates, which pages earn the traffic you have, and how far the site has drifted from the organization you now run. That is a review, it takes weeks rather than months, and it is what turns a redesign brief from a wishlist into a specification.

Why nonprofit website redesigns disappoint

Redesigns disappoint in a specific, repeatable way, and it is worth naming because the mechanism is not mysterious.

The brief gets written from frustration with the old site rather than from observation of it. Frustration is a real signal and a poor requirement. It produces briefs made of adjectives — modern, clean, warm, mission-forward — plus a handful of features somebody admired on a peer organization's site. A designer given that brief will do exactly what a professional should do with it: make something that looks better. Looking better was never the problem.

Underneath the bad brief there is usually a bad assumption: that the website is a marketing asset, and the redesign is a marketing project. That assumption is a decade out of date. The audience marketing reaches best — the people discovering you for the first time, the people a story can be put in front of — is on social media now, on platforms built for exactly that, and your best marketing already happens there. The people who arrive at your website have mostly finished discovering you. They come to do something: give, register for a program, apply, sign up to volunteer, check that you are legitimate before writing a check, find the report a funder asked about. That makes the website an operational surface — the place where intent becomes a donation, a record, a relationship — and it means a redesign briefed as better marketing is aimed at the audience least likely to be on the site.

Then the new site inherits the old problems on a new template. If the donation flow lost people at the second step because it asked for an address before it explained what the gift funds, it will lose them at the second step of the new flow too, because nobody measured the first one. If three forms deposited submissions into an inbox nobody watches, the new forms will do the same thing with nicer input styling. The redesign changed the surface and left the mechanism intact.

The traffic damage is the part that hurts longest. A redesign is usually the single largest change a nonprofit will ever make to its URLs, and it routinely happens without anyone writing down which URLs existed. Pages that had quietly accumulated years of search traffic and inbound links — a program explainer, an old research summary, a resources page other organizations link to — get consolidated into a tidier information architecture and disappear. Six months later the organization notices the site is prettier and the inquiries are down, and the two facts get filed separately.

The last failure is the least discussed. Somewhere between the second and third round of stakeholder review, the site becomes an account of what the organization is proud of rather than an answer to what a stranger needs. Every department gets its section. The homepage becomes a compromise. And the actual question a first-time visitor arrives with — what do you do, who do you do it for, and what do you want from me — goes unanswered on the most expensive page the organization owns.

None of these are design failures. They are all failures of knowing what you had.

What to know about your current site before you hire anyone

There is a body of knowledge about your website that exists nowhere in your organization right now, and it can be assembled without a single design decision being made. This is the pre-redesign review, and six questions carry most of its weight.

Work from what is observable. The point of this exercise is not to collect opinions about the site — you already have plenty and they conflict. It is to write down what the site demonstrably does, and to be honest about the difference between what you have observed and what you are inferring.

  1. 01

    What is a visitor supposed to do next

    Take your five highest-traffic pages and, for each one, name the single next action the page is trying to produce. If a page has four equally weighted calls to action, it has none. If nobody on staff can name the intended action, a visitor cannot either. Do this before anyone opens a design tool, because the answer determines the page's structure and no amount of visual polish substitutes for it.

  2. 02

    Where the donation and signup flows lose people

    Walk every conversion flow yourself, on a phone, as a stranger would: donate, subscribe, register, volunteer, contact. Count the steps, the fields, and the moments where the flow leaves your domain and the branding changes. Then get the numbers — most donation platforms will tell you how many people started and how many finished. A flow that loses eight out of ten people at one identifiable step is a repair you can make in a fortnight, not a reason to rebuild the site around it.

  3. 03

    What data each form creates, and where it lands

    List every form on the site. For each one: what it captures, what system receives it, who reads it, and what happens next. This is the question that most often produces genuine surprise — forms mailing to a departed staff member's address, a newsletter signup that never reached the mail platform, an event registration that lives only in a plugin's database. A redesign is the moment these get rebuilt, which means it is either the moment they get fixed or the moment they get faithfully reproduced.

  4. 04

    Which content actually earns your traffic

    Pull twelve months of analytics and sort pages by entrances from search. The list will not match the site's navigation and it will not match what the organization is proudest of. Some of the best-performing pages will be old, ugly, and load-bearing. Those pages are assets with a URL attached, and the redesign's job is to carry them across intact — same URL where possible, same substance, better presentation.

  5. 05

    What the site says versus what the organization now does

    Read the site as if you had just been hired. Programs that ended are usually still described in the present tense; programs that now consume most of the budget are often missing entirely. Nonprofit sites drift because they are written once and organizations keep changing. This gap is the real reason most sites feel wrong, and it is a content problem wearing a design problem's clothing.

  6. 06

    What is holding the whole thing up

    Who controls the domain and the DNS. Who can log into the CMS. Which plugins or integrations are load-bearing. Where the donation platform ends and the site begins. What the analytics are actually measuring, and whether anyone has ever checked. Nothing in this list is glamorous and all of it becomes urgent in launch week, when the person who knows the answer is on leave.

CARE lens · All four

It is worth running the same pages past the four CARE questions before anyone redesigns them — how people connect, how their participation advances, how relationships persist between transactions, and how value flows back to sustain the work. A redesign scoped only around the last of those tends to produce a site that is very good at collecting a first gift and has nothing designed for the eighteen months afterwards.

See the CARE framework

Those six questions are, deliberately, a description of a Mission Surface Review. If you run them yourself with a couple of focused weeks and a willingness to write down uncomfortable answers, you have done the engagement and you should keep the money. If you do not have those weeks, this is the thing to buy — and buying it is cheaper and considerably more useful than buying a discovery phase from the agency that will also be bidding on the build.

The pre-redesign step

A Mission Surface Review answers the six questions above from the outside: what your pages ask a visitor to do, where the donation and signup flows lose people, what each form creates and where it lands, which URLs carry your traffic, and where the site's account of the organization has drifted from the present one. Findings are labelled observed or inferred, so the brief you hand a builder is evidence rather than assertion — and it is yours regardless of who ends up doing the work.

Start a Mission Surface Review

A website redesign checklist worth using

What follows is the checklist we would want in hand before, during, and immediately after a redesign. It is short on purpose. Most redesign checklists on the internet are content marketing for agencies and run to sixty items, which guarantees the six that matter get the same weight as choosing a font.

Before anyone designs anything

  • Take an analytics baseline and write it down: sessions, entrances by page, conversion counts for every form and donation flow, top search queries and landing pages. If analytics are broken or missing, fix that first — you cannot prove a redesign worked without a before.
  • Export a complete URL inventory. Crawl the site, take the XML sitemap, and pull the last twelve months of landing pages from analytics and Search Console. Three sources, because each one misses something different.
  • Mark every URL keep, redirect, or retire. Nothing goes in the retire column without someone looking at its traffic and inbound links first.
  • Record what each form does and where its submissions land, then decide which of those destinations is correct going forward.
  • Name a single decision-maker and a content owner. Redesigns stall in review, not in build, and consensus design is how a homepage becomes a compromise.
  • Write down what the site must not become. Non-goals are the only reliable defence against scope arriving one reasonable request at a time.

During the build

  • Build the 301 redirect map alongside the new information architecture, not after it. Every retired URL points to the closest genuine equivalent — never a blanket redirect to the homepage, which search engines treat as a soft 404 and visitors experience as being lost.
  • Carry metadata across. Page titles, descriptions, and heading structure on the pages that earn traffic were doing work; a new template that regenerates them from the page name discards it.
  • Migrate the content that performs before the content that flatters. Preserve substance on high-traffic pages even when the new design would prefer them shorter.
  • Keep the old site crawlable and available until launch, and keep the staging site out of the index — password protection, not a robots directive you will forget to remove.
  • Test forms and the donation flow on the staging site with real submissions, end to end, to the actual destination system. Confirm the receipt, the notification, and the record.
  • Check accessibility while it is still cheap to fix: keyboard navigation, focus states, colour contrast, alt text, form labels, and heading order. WCAG 2.2 AA is the standard to name in the contract.

Launch week and the ninety days after

  • Verify redirects against the full old URL inventory, in bulk, on the live site. Sampling is how the one page that mattered gets missed.
  • Submit the new sitemap, confirm the site is indexable, and watch crawl errors daily for the first two weeks.
  • Re-test every form and payment flow on the live site with a real card and a real email address. Staging is not production.
  • Confirm analytics and conversion tracking survived the migration. This breaks silently more often than anything else on the list.
  • Compare against your baseline at thirty, sixty, and ninety days. A modest dip in the first few weeks is normal; a sustained drop in entrances to specific pages is a redirect problem you can still fix.
  • Keep a punch list open for a month and expect to use it. A launch is the start of the last phase, not the end of the project.

Cost, process, and the project plan

Cost is the question everybody asks first and almost nobody answers honestly, so here is the honest version: the range is enormous, the range is real, and where you land inside it depends far more on content and integrations than on design.

We deliberately publish no figures here. A number on a page has seen none of your content, integrations, or data, and it anchors the wrong conversation. The tiers below describe what each level of engagement actually buys; if you want to know what organizations like yours are genuinely quoted, ask us and we will tell you honestly.

  • Template, self-managed

    Right for small teams

    A well-chosen platform theme, configured properly, with your own staff writing and migrating the content. Genuinely the right answer for a lot of small organizations, and it stops being right when your programs need structures a theme cannot express.

  • Small studio or freelancer, custom design

    Where most redesigns land

    Custom design on top of a standard CMS, a handful of page templates, basic integrations with your donation platform and mail tool, and some content help. This is where most nonprofit redesigns actually land, and the variance inside it is mostly the number of templates and the amount of writing.

  • Agency engagement with real scope

    For program-critical sites

    Research, content strategy, custom CMS modelling, CRM and payment integrations, accessibility conformance work, translation, and a managed launch. Justified when the site is a primary program delivery surface rather than a brochure — and it should come with measurable goals, because at this size nobody will remember what it was for.

What each tier costs for an organization like yours is a question we would rather answer than publish. Ask us what nonprofits your size are genuinely quoted — we will tell you plainly, before you have hired anyone, including us.

What actually drives the cost

  • Content. Not design, not development — content. Who writes and rewrites the pages is the single biggest determinant of both cost and timeline, and the most common cause of a redesign running six months late is that the organization assumed the agency was writing it and the agency assumed the reverse.
  • Number of distinct page templates. Every unique layout is designed, built, tested, and maintained. A site with six templates costs meaningfully less than one with sixteen and is usually easier for staff to use.
  • Integrations. Donation platform, CRM, event registration, mailing list, program portals. Each connection is scoped work, and a bespoke connection between two systems that were not designed to talk is where redesign budgets quietly go.
  • Volume of legacy content to migrate. A four-hundred-page site with fifteen years of history is a migration project with a design project attached, and pretending otherwise is how launch dates slip.
  • Accessibility and multilingual requirements. Both are worth paying for, both are cheaper specified upfront than retrofitted, and neither should be discovered after the design is approved.
  • Approval structure. Every additional reviewer adds rounds, and rounds are billable. A board that reviews the homepage twice is normal; a board that redesigns it by committee is a line item.
  • The part nobody budgets: the year after. Hosting, maintenance, plugin and platform updates, and someone's actual time to keep content current. A site with no maintenance owner is a site that will need redesigning again in three years.

The phases of a sane redesign process

  1. 01

    Evidence

    The review described above: what the current site does, what it earns, what its forms create, and where it loses people. Two to four weeks. Do this before you select a builder, and you can hand the same document to everyone who bids.

  2. 02

    Structure and content

    Information architecture, page inventory, and the writing. The longest and most underestimated phase. Assign every page an owner and a due date, and do not let design begin on templates whose content nobody has drafted.

  3. 03

    Design

    Templates, not pages: home, section landing, program, article, form, donate. Review designs against the next action each template is supposed to produce, which is a much better conversation than whether the green is right.

  4. 04

    Build and migrate

    Development, content loading, integrations, and the redirect map built in parallel. Forms and donation flows get tested against their real destination systems here, not in launch week.

  5. 05

    Pre-launch verification

    Accessibility pass, cross-device checks, redirect verification against the full old URL list, analytics and conversion tracking, and a content proofread by someone who has not read the pages twenty times.

  6. 06

    Launch and watch

    Ship, then monitor for ninety days against the baseline. Budget attention for this phase explicitly; it is the phase that gets cancelled when the project is late, and it is the one that catches the expensive mistakes.

A realistic project plan for a small nonprofit runs three to six months end to end, and the critical path is content, not code. Put the content deadlines on the plan first and schedule design and build around them, because the reverse — a build waiting on copy nobody was assigned — is the standard way these projects stall.

Two practical constraints belong on the plan before anything else. First, your organizational calendar: nobody should launch a website during a year-end giving push, a gala, or the week a major grant report is due. Second, the review windows. If your board sees the design once, put that date on the plan and make it real; if it sees the design whenever it asks, the plan is fiction.

One budget note that sits slightly outside the redesign itself. If part of the reason for rebuilding is that supporter data is scattered across systems that do not agree, a new website will not settle it, and the fix is usually cheaper than the redesign. That decision has its own method, which we wrote up separately in the guide to choosing a nonprofit CRM — same surfaces-first approach, applied to where the data lands rather than to how the page looks.

Writing the RFP and choosing a builder

Most nonprofit website redesign RFPs are feature wishlists. They describe a site the organization imagines, in the organization's internal vocabulary, and they ask vendors to price something nobody has specified. Every response comes back with a different set of assumptions, the bids are not comparable, and the selection ends up being made on chemistry and price — which is to say, on the two things that predict a redesign's outcome least well.

A review turns the same document into observed requirements. Instead of we want a modern, mobile-friendly site with better donation conversion, the RFP says: sixty-two percent of sessions are mobile; the donation flow loses seventy percent of visitors between step one and step two; these are the eleven URLs that produce most of our search traffic and they must survive with their inbound links intact; these four forms currently deposit data in places nobody reads and here is where each should go instead. Every bidder is now pricing the same job. The bids become comparable, and the shortlist stops being a popularity contest.

There is a second effect worth being explicit about. A vendor who receives that document behaves differently — the good ones get more precise and the ones who were planning to sell you a template get vaguer. You will learn more from how each agency responds to observed evidence than from anything in their portfolio.

What belongs in a website redesign RFP

  • Who you are and who the site is for, in two paragraphs, written for a stranger. If you cannot do this, the site cannot either.
  • What the current site demonstrably does: traffic, top entry pages, device split, conversion numbers for each flow, and the specific points where people leave. Label what is observed and what is inferred.
  • Goals stated as measurable outcomes rather than adjectives. More donations is not a goal; raising completion on the donation flow from its current rate is.
  • Scope: number of page templates, approximate page count, who writes the content, and who migrates it. Be explicit about the content responsibility. It is the most expensive ambiguity in the document.
  • Technical constraints and integrations: CMS preference or requirement, hosting, donation platform, CRM, mail platform, event tooling, and anything that cannot change.
  • Non-negotiables: WCAG 2.2 AA conformance, a complete 301 redirect map from your supplied URL inventory, metadata carryover on named pages, analytics and conversion tracking verified before launch, and full handover of accounts, credentials, and source at the end.
  • Your URL inventory, attached, with the keep, redirect, and retire decisions already made. Nothing signals a well-run project more clearly, and nothing protects your traffic better.
  • Budget range and timeline, both real. Withholding the budget does not get you a better price; it gets you proposals scoped for a different organization.
  • How you will evaluate, in what order, and by when. Then hold to it.

How to choose a web design agency

Portfolios are not evidence. Every studio worth hiring has beautiful work to show, and the difference between the good outcome and the expensive one shows up in operational questions the portfolio cannot answer. Ask these, and pay attention to which ones produce a practised answer.

  • Show us a nonprofit site you launched two or more years ago, and tell us what happened to its traffic and conversions afterwards. Portfolios are screenshots from launch day. The interesting question is what the site did in year two, and whether the agency knows.
  • Who writes the content, and what happens if we are late delivering ours? A studio that has thought about this has a process. One that has not will quote a timeline it has never met.
  • How do you handle URLs and redirects at launch? The answer should be immediate, specific, and mention a mapped inventory. Hesitation here is the single most predictive bad sign in the whole conversation.
  • What is your accessibility practice, and how is it tested? Manual keyboard and screen-reader testing, not only an automated scan.
  • Which parts of this scope do you think we do not need? A good partner will argue you out of something. A vendor will price everything you asked for.
  • What happens after launch, what does it cost, and what can our staff do without you? Ask specifically what you will be able to change yourselves.
  • Who owns the domain, the DNS, the hosting account, the CMS admin, and the design source files when we are done? The correct answer is you, in writing, in the contract.
  • What went wrong on your last project and what did you change afterwards? Everyone has one. Only some will tell you.

Red flags

  • The proposal arrives without questions

    A firm that can price your redesign from your RFP alone, with nothing to clarify, is pricing a template. The good responses come back with three awkward questions about your content and your integrations.

  • Discovery is the whole first phase, and they own it

    Discovery run by the firm that will bid on the build has an interested party holding the pen. It is not fraudulent and it is not neutral. Bring your own evidence and let discovery be short.

  • Nobody mentions redirects, migration, or analytics

    These are the three things that determine whether your traffic survives, and they are absent from a startling number of proposals. Their absence tells you what the firm considers its job to end at.

  • The nonprofit portfolio is all visual

    Beautiful mission-driven sites are easy to show and easy to build. Ask about the donation flow, the CRM connection, the program directory, the multilingual pages — the parts that make nonprofit sites hard.

  • The recommendation is a rebuild before anyone looked

    A full rebuild is sometimes right. It should never be the finding of a conversation that has not yet examined the current site. Anyone who reaches it in the first meeting reached it from their capacity, not your evidence.

  • Ownership is left vague

    Hosting on their account, the domain in their registrar, no source handover, and a maintenance retainer that is really the price of access. Settle ownership in the contract, not in year three when you want to leave.

Questions we get asked

How much does a nonprofit website redesign cost?
The honest answer is that any figure quoted before someone has seen your content, your integrations, and your data is a guess dressed as a price, which is why we publish none here. What we can tell you is the shape of the market: there are three tiers. A well-configured platform theme with staff-written content, at the bottom. A small studio or freelancer doing custom design on a standard CMS with a few integrations, in the middle — where most nonprofit redesigns actually land. And a full agency engagement with research, content strategy, CRM and payment integrations, accessibility conformance, and a managed launch, at the top. What moves you between and within tiers is mostly content and integrations, not design: who writes and rewrites the pages, how many distinct templates the site needs, how many systems have to connect, and how much legacy content must be migrated. If you want to know what organizations like yours are genuinely quoted, contact us and we will tell you plainly — before you have hired anyone, including us. And budget the year after launch too: hosting, maintenance, and someone's real time to keep content current. A site with no maintenance owner needs redesigning again in three years.
How long does a nonprofit website redesign take?
Three to six months is realistic for a small organization, and the critical path is content rather than code. Large sites with heavy migration, multilingual requirements, or a CRM integration run longer. The reliable cause of overrun is not development: it is pages nobody was assigned to write. Put content deadlines on the plan before design and build dates, name an owner per page, and schedule board and stakeholder review as fixed windows rather than open-ended availability. And avoid launching during year-end giving, a gala, or a major grant deadline — launch week needs attention from the same people those events consume.
Do we actually need a redesign, or just repairs?
Repairs more often than organizations expect, and this is the finding we deliver most frequently. If the donation flow loses people at one identifiable step, if the site describes programs that ended three years ago, if forms deposit data nowhere useful, if the homepage cannot say what the organization does — those are content, flow, and configuration problems. A rebuild does not fix them; it reproduces them on a new template at considerable expense. The honest signs that you do need a redesign are structural: the CMS prevents staff from making routine updates, the site cannot express the structures your programs now need, it fails on mobile in ways that cannot be patched, the platform is unmaintained or insecure, or the brand and the organization have diverged so far that no amount of page editing closes the gap. The way to tell the difference is to look before you decide.
What should be in a website redesign RFP?
Who you are and who the site is for, written for a stranger. What the current site demonstrably does — traffic, top entry pages, device split, conversion rates per flow, and the specific points where people drop out. Goals stated as measurable outcomes rather than adjectives. Scope: template count, approximate page count, and an explicit statement of who writes the content and who migrates it, which is the most expensive ambiguity an RFP can contain. Technical constraints and every integration. Non-negotiables: WCAG 2.2 AA, a complete 301 redirect map built from the URL inventory you attach, metadata carryover on named pages, verified analytics and conversion tracking at launch, and full handover of accounts, credentials, and source. A real budget range and a real timeline. And your evaluation criteria, in order. The difference between a wishlist and a specification is whether the requirements came from observation or from frustration.
Should we audit our website before redesigning it?
Yes, and it is the cheapest leverage available in the whole project. A review of the current site produces the things a redesign brief needs and a wishlist cannot supply: what each key page is asking a visitor to do, where each conversion flow loses people, what data every form creates and where it lands, which URLs earn your search traffic and inbound links, and how far the site's account of the organization has drifted from the present one. It also frequently establishes that the redesign is smaller than assumed, or unnecessary. Run it yourself if you have a couple of focused weeks — the method is in this guide. Buy it if you do not. What you should not do is let discovery be run by the firm that will also bid on the build.
Will a website redesign hurt our SEO?
It can, badly, and almost every case is preventable. The damage comes from changing URLs without mapping redirects, retiring pages that were quietly earning search traffic, regenerating page titles and descriptions from a new template, and losing analytics continuity so nobody can prove what happened. The prevention is mechanical: inventory every URL from three sources before you start — a crawl, the sitemap, and twelve months of analytics and Search Console data — mark each one keep, redirect, or retire with traffic and link data in front of you, build a one-to-one 301 map to genuine equivalents rather than a blanket redirect to the homepage, carry metadata across on the pages that matter, and verify the whole map against the live site in launch week. Expect a modest dip for a few weeks while search engines recrawl. A sustained drop in entrances to specific pages is a redirect problem, and it is still fixable if you kept the inventory.
Can we redesign the site ourselves?
Often, yes. A small organization with one capable, interested staff member and a good platform theme can produce a site that outperforms an agency build, because the person maintaining it understands both the tool and the mission. The failure mode is different from the agency failure mode: solo redesigns stall at seventy percent and live half-finished for a year. Two things make the difference. Do the review first, so you are working from evidence rather than taste. And treat the boring mechanics — the URL inventory, the redirect map, the form destinations, the analytics baseline — as non-optional, because they are exactly the parts a self-managed project skips and exactly the parts that cause lasting damage.

Get the brief before you get the quotes

A Mission Surface Review is the pre-redesign step: an observed account of what your site asks people to do, where the flows lose them, what your forms create, which URLs you cannot afford to lose, and the repairs worth making first. You leave holding the brief — and you can hand it to any designer or builder, ours or anyone else's. It is useful even if you never hire us for another thing, which is rather the point.

Start a Mission Surface ReviewWebsite and digital experience audit