withMission.tech

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 most valuable thing you can do before hiring a designer or an agency is find out what your current site actually does, page by page and form by form. That is a review. It takes weeks rather than months, and it turns a redesign brief from a wishlist into a specification that agencies can price against each other.

01Why nonprofit website redesigns disappoint

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 a brief made of adjectives like modern, clean, warm, and mission-forward, plus a handful of features somebody admired on a peer organization's site. A designer given that brief will do what a professional should do with it and 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, people discovering you for the first time, is on social media now, 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 turns into a donation or a record, and 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 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 built up years of search traffic and inbound links get consolidated into a tidier information architecture and disappear: a program explainer, an old research summary, a resources page other organizations link to. Six months later the organization notices the site is prettier and the inquiries are down, and the two facts get filed separately.

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. The question a first-time visitor arrives with goes unanswered on the most expensive page the organization owns. What do you do, who do you do it for, and what do you want from me?

02What to know about your current site before you hire anyone

Some knowledge about your website exists nowhere in your organization right now, and you can assemble it without making a single design decision. That is the pre-redesign review, and six questions carry most of its weight.

Work from what is observable. You already have plenty of opinions about the site, and they conflict. Keep what you observed separate from 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. A page with four equally weighted calls to action has none, and 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.
  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, write down what it captures, what system receives it, who reads it, and what happens next. This question produces more surprises than any other: 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.
  4. 04

    Which content 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 has to carry them across intact, on the same URL where possible.
  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, and programs that now consume most of the budget are often missing entirely. Nonprofit sites drift because they are written once and organizations keep changing, and the drift 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.

03A website redesign checklist worth using

This is the checklist we would want in hand before, during, and just after a redesign. It is short on purpose. Most redesign checklists online are content marketing for agencies and run to sixty items, which guarantees the six that matter get the same weight as choosing a font. The search items, the URL inventory and the redirect map, are set out step by step in the guide to website redesign SEO.

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 until someone has looked at its traffic and inbound links.
  • 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 more often than in build.
  • 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. The guide to website redesign SEO covers how to build the map and verify it.
  • 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 throws that work away.
  • 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 with password protection rather than 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.

04Website redesign cost and process

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

We publish no figures here. A number on a page has seen none of your content, integrations, or data, and it anchors the wrong conversation.

  1. 01

    Template, self-managed

    Right for small teams

    A well-chosen platform theme, configured properly, with your own staff writing and migrating the content. It stops being right when your programs need structures a theme cannot express.

  2. 02

    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. The variance inside the tier is mostly the number of templates and the amount of writing.

  3. 03

    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. It should come with measurable goals, because at this size nobody will remember what it was for.

If you want numbers anyway, ask us what nonprofits your size are quoted. We will tell you plainly, before you have hired anyone, including us.

What actually drives the cost

  • Content, and who writes it. The most common reason a redesign runs six months late is that the organization assumed the agency was writing it and the agency assumed the reverse.
  • Every distinct page template is a layout someone designs, builds, tests, and maintains. A site with six costs 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 go.
  • 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 worth paying for and cheaper to specify up front than to retrofit.
  • 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 will need redesigning again in three years.

The phases of a redesign process

  1. 01

    Evidence

    The review described above, which takes two to four weeks. Do it before you select a builder, and 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 it. It is the phase that gets cancelled when the project runs late, and the one that catches the expensive mistakes.

The project plan

A realistic project plan for a small nonprofit runs three to six months end to end, with content on the critical path rather than code. Your organizational calendar goes on it early. Nobody should launch a website during a year-end giving push, a gala, or the week a major grant report is due.

So do 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.

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 usually costs less than the redesign. That decision has its own method in the guide to choosing a nonprofit CRM.

05How to choose a web design agency

Start with an RFP built from evidence

Most nonprofit website redesign RFPs are feature wishlists. They describe a site the organization imagines, in its own internal vocabulary, and ask vendors to price something nobody has specified. The bids come back on different assumptions and cannot be compared, so the choice gets made on chemistry and price, the two things that predict a redesign's outcome least well.

A review turns the same document into observed requirements. Instead of asking for a modern, mobile-friendly site, the RFP says that sixty-two percent of sessions are mobile, that the donation flow loses seventy percent of visitors between step one and step two, and that eleven named URLs carry most of the search traffic and have to survive. Every bidder is then pricing the same job.

The full guide, with a templateHow to write a nonprofit website redesign RFP

Questions to ask a web design agency

Every studio worth hiring has beautiful work to show. The difference between the good outcome and the expensive one shows up in operational questions a portfolio cannot answer. Ask these, and notice which ones get a practised answer.

  1. 01

    Show us a nonprofit site you launched two or more years ago. What happened to its traffic and conversions afterwards?

    Portfolios are screenshots from launch day. Year two is the interesting part, and so is whether the agency knows what happened in it.

  2. 02

    Who writes the content, and what happens if we are late with ours?

    A studio that has thought about this has a process. One that has not will quote a timeline it has never met.

  3. 03

    How do you handle URLs and redirects at launch?

    The answer should be immediate and specific, and mention a mapped inventory. Hesitation here is the most predictive bad sign in the whole conversation.

  4. 04

    What is your accessibility practice, and how do you test it?

    Manual keyboard and screen-reader testing, not only an automated scan.

  5. 05

    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.

  6. 06

    What happens after launch, what does it cost, and what will our staff be able to change without you?

  7. 07

    Who owns the domain, the DNS, the hosting account, the CMS admin, and the design source files when we are done?

    You do, in writing, in the contract.

  8. 08

    What went wrong on your last project, and what did you change afterwards?

    Everyone has one. Only some will tell you.

Red flags in a proposal

  1. 01

    The proposal arrives without questions

    A firm that can price your redesign from the 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.
  2. 02

    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.
  3. 03

    Nobody mentions redirects, migration, or analytics

    These decide whether your traffic survives, and a startling number of proposals leave them out. Their absence tells you where the firm thinks its job ends, which for a marketing scope is usually launch day.
  4. 04

    The nonprofit portfolio is all visual

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

    The recommendation is a rebuild before anyone looked

    A full rebuild is sometimes right. Anyone who reaches it in the first meeting reached it from their capacity, not your evidence.
  6. 06

    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.

06Questions we get asked

How much does a nonprofit website redesign cost?
Any figure quoted before someone has seen your content, integrations, and data is a guess dressed as a price, which is why we publish none here. The market has three tiers. At the bottom, a well-configured platform theme with staff-written content. In the middle, where most nonprofit redesigns land, a small studio or freelancer doing custom design on a standard CMS with a few integrations. At the top, a full agency engagement with research, content strategy, CRM and payment integrations, and a managed launch. What moves you between and within tiers is mostly content and integrations, not design. Budget the year after launch as well, including someone's real time to keep content current. If you want to know what organizations like yours are quoted, ask us.
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 pages nobody was assigned to write, so name an owner for every page and schedule board review as fixed windows. Avoid launching during year-end giving, a gala, or a major grant deadline, because 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 it 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 and configuration problems. A rebuild reproduces them on a new template at considerable expense. The 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, including traffic, top entry pages, and where each flow loses people. Goals stated as measurable outcomes rather than adjectives, a scope that says who writes and who migrates the content, every integration, and a real budget range and timeline. Then the 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 at launch, and full handover of accounts, credentials, and source. The full contents list and a fill-in template are in the guide to writing a nonprofit website redesign RFP.
Should we audit our website before redesigning it?
Yes. It is the cheapest step in the project and it shapes everything after it. A review of the current site produces what a redesign brief needs and a wishlist cannot supply: what each key page asks a visitor to do, where each conversion flow loses people, what data every form creates and where it lands, and which URLs earn your search traffic and inbound links. Run it yourself if you have a couple of focused weeks, since the method is in this guide. Buy it if you do not. Just do not hand it to 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 earning search traffic, letting a new template regenerate page titles and descriptions, and losing analytics continuity so nobody can prove what happened. The prevention is an inventory of every URL before you start and a one-to-one 301 redirect map to genuine equivalents, verified 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. The step-by-step method is in the guide to website redesign SEO.
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 one. Solo redesigns stall at seventy percent and live half-finished for a year. Do the review first, so you are working from evidence rather than taste. And treat the boring mechanics as required: the URL inventory, the redirect map, the form destinations, the analytics baseline. A self-managed project skips exactly those, and they are the parts that cause lasting damage.

Get the brief before you get the quotes

A Mission Surface Review answers the six questions above from the outside, with evidence you can check, and ranks the repairs worth making first. You leave holding the brief, and any designer or agency can build from it.

Website and digital experience audit