Author: Douglas Choate

Short answer: Wix, Squarespace, Webflow, and the other SaaS website builders have gotten quite good. For some organizations they’re the right choice. The place the comparison usually turns is five years in, when an organization needs the site to do something the platform doesn’t support and realizes how much of the site belongs to the vendor. This piece walks through the tradeoffs before you sign up for another year.

The comparison that matters

If you’re on Wix or Squarespace today, or weighing Webflow for a new build, the pitch is easy to understand. Drag, drop, publish. No code. No hosting to manage. No plugin updates to track. For many small organizations, that really is the whole job.

WordPress is a different shape from proprietary website builders like Wix, Squarespace, and Webflow. Open source, self-hosted, thousands of plugins, more choices to make up front. The underlying question, whether you frame it as open source vs closed source or self-hosted vs SaaS, is the same one: who owns the site at the end.

The usual sales conversation focuses on the first few weeks. Which is easier to set up, which has better templates, which launches faster. That’s the wrong window. The conversation that matters is what the site looks like three, five, or ten years in, once the organization has grown, staff has turned over, compliance expectations have shifted, and the site needs to do something the vendor didn’t plan for.

Where SaaS builders work well

Before the tradeoffs, better to be clear about what Wix, Squarespace, and Webflow do well.

A one-person operation that just needs a professional-looking site. A small business with a five-page brochure site and no plans to change it. A nonprofit with no technical staff and a volunteer webmaster. A restaurant. A therapist. A freelance photographer.

For any of those, a SaaS builder is often the right answer. Templates are solid. Hosting is included. The learning curve is real but not brutal. The monthly fee usually looks cheaper in year one than paying for hosting, a developer, and a custom theme.

If that describes your situation, and will still describe it in three years, pick a template and ship.

Trouble starts when the shape of your organization changes, or when the site needs to do more than it did on day one.

Five questions that tend to settle it

1. If you leave, what do you get to keep?

The quiet part of the SaaS deal. Most organizations don’t think about it until they need to.

When you cancel Wix, Squarespace, or Webflow, you don’t get to download a working website. You get some exported content. The design is built on the vendor’s proprietary template system and doesn’t move. Your custom interactions, forms, and integrations stay behind. Rebuilding the same site on another platform is, in practice, building a new site from scratch.

WordPress sits on the other side of this. Content is in a standard format. The theme is code you own. The site is a set of files and a database you can move to any host in the world. Leaving is a migration project, not a rebuild.

This is what SaaS vendor lock-in means in practice: a concrete difference in what you walk away with at the end of the contract.

2. What does it cost over five years?

SaaS pricing looks cheap in month one. Add it up over five years and the picture changes.

A Webflow site with reasonable traffic and a few integrations typically lands between $50 and $300 a month. Squarespace commerce plans sit in a similar range. Add transaction fees, plugin add-ons, extra user seats, and the number grows from there.

Over five years, the subscription ends up somewhere between $3,000 and $18,000, not counting any design or content work along the way.

WordPress has a different cost shape. Hosting is commodity, usually $20 to $100 a month for organizations of this size. The initial build costs more, typically, because it’s custom. The ongoing cost is predictable, vendor-independent, and doesn’t compound the same way.

Neither is automatically cheaper. The point is that SaaS pricing is structured to grow with your success. Self-hosted WordPress isn’t.

3. Can your site grow beyond the template?

Every SaaS builder has a ceiling. Wix’s is low. Squarespace’s is slightly higher. Webflow’s is higher still. All of them have one.

If your organization grows into needing a custom donation flow, a program finder, a member portal, a multilingual site, or an integration with your CRM that the vendor doesn’t support, you’re stuck. You can sometimes hack around it with embedded third-party tools. You usually can’t add the feature natively.

WordPress has, functionally, no ceiling. The plugin ecosystem covers almost every case. Custom development is always available. You aren’t asking a vendor for permission to add a feature.

For a small org that will never need any of that, the ceiling doesn’t matter. For an org that’s growing or might grow, it matters more than almost anything else on this list.

4. Who controls your content and your data?

This matters more for nonprofits, schools, and any organization handling donor, student, or member information.

On a SaaS builder, your content and often your form data live inside the vendor’s infrastructure. You have access through their interface. You can export some of it, some of the time, in some of their formats. What you can’t do is independently audit, back up, or move the data on your own terms.

On WordPress, content and data live in your database, on your hosting, under your control. You can back it up however you want. You can hand it to a compliance auditor without asking anyone. You can move it to a different host in a weekend.

For an organization whose data touches donor records, student info, or sensitive program details, this shows up in compliance conversations, privacy policies, and sometimes insurance coverage. It’s the sort of thing that doesn’t feel urgent until a board member asks a hard question.

5. How does it handle accessibility, SEO, and integrations?

The slow-burn stuff that determines whether the site keeps working over the years.

Accessibility. WordPress has a dedicated accessibility team and a mature ecosystem of auditing tools. Webflow has made progress but still requires manual discipline from the builder. Wix and Squarespace generate accessibility gaps out of the box that the site owner often can’t fix without switching templates. WebAIM’s annual audit is the benchmark most of the field uses here.

SEO. All modern builders produce sites that can rank. WordPress’s depth of SEO plugins (Yoast, Rank Math) and the maturity of its schema support give it a ceiling the SaaS builders don’t have. If being found on Google is central to your work, this matters.

Integrations. Every SaaS builder lists integrations on a marketing page. WordPress’s integrations are distributed across thousands of plugins, which is both a strength and a hassle. Short version: if the integration exists anywhere, it probably exists for WordPress. SaaS builders support what their vendor has chosen to support.

A note on headless CMS

You’ll occasionally see “headless CMS vs WordPress” framed as the modern comparison (Contentful, Sanity, Strapi, Cloudflare’s EmDash). For most small organizations and nonprofits, this is the wrong shelf.

Headless CMS platforms are powerful, but they require a development team to build and maintain the front-end separately. They solve a problem that large product companies have and most service organizations don’t. Unless you have a technical team on staff, headless is a significant commitment with narrow upside.

The tradeoffs side by side

Factor	Wix / Squarespace	Webflow	WordPress	Headless CMS
Learning curve	Low	Medium	Medium-high	High
Data / content portability	Poor	Limited	Full	Full
Customization ceiling	Low	Medium	None	None
Total cost over five years	Medium-high	Medium-high	Variable	High
Accessibility maturity	Variable	Manual	Mature	Depends on build
Vendor lock-in	High	High	None	None
Best fit	Simple small sites	Design-led small/medium sites	Orgs with a long horizon	Product companies with dev teams

Where this leaves you

If your organization is small, not growing, and the site will stay simple, Squarespace or Wix is likely the right call. That’s an honest read.

If your organization expects to grow, handles sensitive data, plans to still be operating in ten years, or needs customization beyond what a template provides, the lock-in and ceiling questions get sharper. WordPress doesn’t win the first month. It tends to win year three onward.

The question worth asking before you renew another SaaS plan: what does the exit look like, and is it acceptable?

If the answer is “start over,” that’s useful information to have before signing for another year.

Local SEO matters even when your nonprofit doesn’t sell anything locally. A claimed Google Business Profile, consistent contact info across the web, and a handful of geographic content cues are enough to get most nonprofits showing up for donors, grantmakers, and partners searching by region. None of it takes a developer.

Why local still matters when you don’t have a storefront

Most nonprofits hear “local SEO” and assume it’s for restaurants. Local SEO is also for the foundation program officer typing “youth mental health nonprofits [city]” into Google at 2pm on a Tuesday. It’s for the donor searching “environmental nonprofits [state]” before deciding where to give. It’s for the reporter checking your organization is actually based where you say it is before writing you into a story.

Google treats roughly 46% of all searches as having local intent, per its own data. For a mission-driven organization in any defined geography, the implication is the same. If you don’t show up for local queries in your space, you’re invisible to a meaningful chunk of the people looking for you.

Where local SEO matters less

Not every nonprofit needs to care about this equally.

National organizations with no regional programming can treat local SEO as a nice-to-have. Pure online service providers with a nationwide audience won’t gain much. Orgs whose funding comes entirely from federated national campaigns or corporate partnerships usually have enough pipeline without it.

If that describes you, skim this piece and move on.

If you run programs in a defined area, employ local staff, receive funding from regional foundations, or want to partner with other organizations nearby, the rest of this matters.

Five questions that settle what to do

1. Does local SEO actually matter without a storefront?

For most place-based nonprofits, yes.

Foundation program officers search geographically when vetting grantees. Major donors look for local organizations to give to. Journalists and bloggers verify location before naming you. Partner orgs and vendors filter by region. Job candidates use city-based searches. Board prospects research where they’d be serving.

Google’s local results (the map pack at the top of many searches) sit above everything else. If you’re not in there, that’s a gap competitors are happy to fill.

2. What should be in your Google Business Profile?

The single most important local SEO task for most nonprofits. Claim your profile at google.com/business. It’s free.

Fill in every field. Legal name exactly as it appears in other places. Full street address. Phone that actually gets answered. Categories that match your work (there are nonprofit-specific options). Hours, even if they’re “By appointment only.” Service areas if you deliver programs beyond your office. A short, plain description of what you do. Photos (staff, program participants with permission, events, building).

Post to your profile occasionally. A Google Business Profile with no posts and two photos looks abandoned. A profile with monthly posts looks active. Google ranks active profiles higher.

3. What about NAP consistency?

NAP stands for Name, Address, Phone. The rule: these three fields must match exactly across every place your org shows up online.

Your website footer. Your Google Business Profile. Your Candid/GuideStar profile. Your LinkedIn page. Your Facebook page. Any directory listings, nonprofit registries, charity aggregators. Past press releases that link back to you.

Mismatches tank local rankings. “123 Main St” on your site and “123 Main Street” on Google is a mismatch. “617-555-1234” and “(617) 555-1234” is a mismatch. “Youth Alliance” and “The Youth Alliance” is a mismatch.

The fix is tedious. An afternoon with a spreadsheet. Worth doing.

4. How does local content help?

Google reads your site to figure out where you operate. Pages that mention specific neighborhoods, local partners, state-level context, and regional programs tell Google you’re a regionally relevant result.

Don’t stuff neighborhood names into every page. Write naturally. If your programs run in a specific district, say so where it’s relevant. If you partner with the county school system, name it. If you hold events in a particular venue or part of town, mention the location.

One program page written with specific local context beats ten generic pages about “youth empowerment” in terms of local signal.

5. What other geographic signals matter?

Three things move the needle beyond the basics.

Backlinks from local sources. Links from your city or county government, area .edu domains, regional foundations, neighborhood associations, and local news sites tell Google you’re part of the local web. A single link from your area’s largest publication covering your program is worth more than a hundred generic directory listings.

Reviews from local people. Google Business Profile reviews affect local ranking. Ask program participants, partners, and board members to leave honest reviews. Don’t fake them. Google catches fake reviews and the penalties are real.

Schema markup. Structured data markup (specifically the NonprofitOrganization Schema.org type) helps Google display rich information about your org in search results. This usually needs a developer or a plugin, but it’s a one-time setup that pays off indefinitely.

Local ranking factors ranked by effort and impact

Factor	Effort	Impact	Who does it
Claim and optimize Google Business Profile	Low	High	Staff
NAP consistency across directories	Low	High	Staff
Local content (neighborhoods, partners)	Medium	Medium	Staff
Post regularly to Google Business Profile	Low	Medium	Staff
Earn locally-sourced backlinks	High	High	Staff + PR
Collect reviews	Low	Medium	Staff
NonprofitOrganization schema markup	Medium	Low to medium	Developer

Where this leaves you

Local SEO is one of those things nonprofits can neglect for years and not realize what they’re missing. The fixes are mostly free, mostly DIY, and mostly boring.

Start with the Google Business Profile. Then fix NAP consistency across every place your org appears online. Then look at your program pages and add specific local context where it’s honest. Those three steps put most place-based nonprofits ahead of their peers, because their peers haven’t done any of it either.

The question worth asking this week: search your organization’s name on Google and look at what shows up on the right side of the results page. If there’s no profile, or if it’s incomplete, that’s the first hour of work.

Sources and further reading

• Google Business Profile help
• Moz Local Search Ranking Factors
• BrightLocal Local Consumer Review Survey
• Schema.org NonprofitOrganization

Page speed affects both SEO rankings and donation conversion, but the gains most nonprofits need come from three or four concrete fixes. The rest is noise. This piece walks through what’s worth doing, what isn’t, and when to call for help.

Why this matters now

Google has treated page speed as a ranking signal in some form for over a decade. In 2021 it started weighing Core Web Vitals directly, and mobile performance has only grown in importance since.

For a small nonprofit, the honest version is this. Page speed isn’t the most important thing about your website, but it’s one of the easier things to get wrong. A slow site quietly erodes two things you care about: Google rankings and donation completions. The fixes aren’t technical gymnastics. Most are an afternoon of work, some of which a staff member can do without a developer.

Where speed matters most

Not every page on your site carries the same weight.

The donation page matters most. Google’s mobile speed research pegs the bounce rate increase at roughly 32% going from a 1-second to a 3-second load, and 90% going from 1 to 5. For a nonprofit pulling in donors mostly via email campaigns and social posts, those are mobile-first visits on variable networks. A donation page that takes five or six seconds to load on a phone is losing real revenue.

The homepage matters almost as much. First impression, usually mobile, often on a weak connection.

Program and service pages that pull in search traffic are next. Google rewards faster pages, and ties often break on speed.

Internal staff pages and deep archives matter less. If nobody’s clicking on them, they don’t need to be fast.

Five questions that settle what to do

1. Does page speed actually move the needle on donations?

Yes, and it’s a slope rather than a cliff.

The Google benchmark shows bounce rates rising sharply past three seconds. A donation page that loads in two seconds keeps more of the traffic you paid to get there. A donation page that loads in seven loses a meaningful share of it.

The effect is real. It’s also not the only thing affecting conversion. If your donation page is slow but also has a confusing four-step flow, fix the flow first. Speed amplifies a good experience and compounds a bad one.

2. How do you measure it?

Two free tools cover most of what a nonprofit needs.

PageSpeed Insights gives you a score and a breakdown of Core Web Vitals for mobile and desktop. It’s Google’s own tool using Google’s own criteria, so the numbers correlate with what affects ranking.

GTmetrix gives a second opinion and better visualization of which specific files are slow.

Run both against your homepage and your donation page. If both tools come back green, stop worrying and go work on copy.

If either is yellow or red, focus on the three Core Web Vitals numbers: Largest Contentful Paint (how fast the main thing appears), Interaction to Next Paint (how fast the page responds when a visitor clicks), and Cumulative Layout Shift (how much stuff jumps around while loading). These are what Google is actually measuring.

3. What’s usually making a nonprofit site slow?

Four things, in roughly this order of likelihood.

Oversized images. The single most common issue. A homepage with a 4MB hero photo that should be 200KB. Staff uploading phone photos directly into the media library. Stock images pasted in at full resolution. This alone can turn a fast site into a slow one.

Plugin bloat. WordPress sites accumulate plugins the way garages accumulate boxes. Each one loads scripts, styles, sometimes tracking. A small nonprofit site running 40 plugins is carrying weight it doesn’t need.

Cheap or shared hosting. On the cheapest hosting tier, your site shares a server with hundreds of others. When a neighbor has a traffic spike, your site slows. This matters less than people assume, but it’s real.

Tracking scripts and embeds. Facebook pixel, Google Analytics, HubSpot, a chat widget, three different form providers. Each one adds load time. Most nonprofits run more of these than they need.

Notice what’s not on this list: your theme, in most cases. Unless your theme was custom-built badly or dates from 2015, the theme is rarely the bottleneck.

4. What can you fix without a developer?

More than most staff assume.

1. Compress images before uploading. Use TinyPNG or Squoosh. Aim for hero images under 200KB and content images under 100KB. This is the biggest single win for most nonprofit sites.
2. Audit your plugins. Deactivate anything you haven’t actively used in six months. If nothing breaks after a week, delete it. Page builders installed for one page and never removed are common culprits.
3. Install a caching plugin. If you don’t have one, add WP Rocket (paid) or W3 Total Cache (free). Default settings are usually fine. This alone often moves PageSpeed Insights scores 15 to 25 points.
4. Remove tracking scripts you don’t use. Check your analytics. If a pixel hasn’t fired in six months, it’s weighing the site down for no reason.
5. Limit custom fonts. Every font family and weight adds load. Two weights of one font is plenty for most sites.

None of these need code. A marketing manager can do them in an afternoon, assuming someone with admin access is available.

5. When should you bring in technical help?

If you’ve done the above and the site is still slow, the remaining issues usually fall into three buckets.

Hosting. Moving from shared hosting to managed WordPress hosting (Kinsta, WP Engine, Pressable) often produces a clear speed jump. Expect $30 to $100 per month instead of $5 to $20. For most nonprofits with real traffic, this is worth it.

Theme or page builder bloat. Some themes, particularly older “mega” themes, load huge amounts of code regardless of what’s on the page. Replacing a bloated theme is real work and needs a developer.

Database or code-level issues. Sites that have run for many years accumulate database cruft, orphaned settings, and unused tables. This usually shows up as slow “Time to First Byte.” A developer can clean it in a day or two.

At that point you’re looking at real engagement, not an afternoon of cleanup. Most nonprofits cross this line only once every several years.

Investments ranked by effort and impact

Fix	Effort	Impact	Who does it
Image compression	Low	High	Staff
Plugin audit	Low	Medium	Staff
Caching plugin	Low	High	Staff
Remove unused trackers	Low	Low to medium	Staff
Trim custom fonts	Low	Low	Staff
Hosting upgrade	Medium	Medium to high	Staff with guidance
Theme replacement	High	High	Developer
Database cleanup	Medium	Medium	Developer

Where this leaves you

Most nonprofit sites are slow for ordinary reasons. Usually big images. Sometimes plugin bloat. Occasionally old tracking scripts nobody removed. Fixing those is cheap and fast and usually enough.

If your homepage loads in under three seconds on mobile, your donation page in under two, and your Core Web Vitals come back green, you’re doing better than most nonprofits. If you’re nowhere near that, the list above is where to start before anyone begins talking about redesigns or rebuilds.

The question worth asking: when was the last time someone on your team ran your site through PageSpeed Insights? If the answer is “never” or “more than a year ago,” that’s the first thing to do this week.

---

Not sure where your site stands? Start a conversation.

---

Sources and further reading

• Google PageSpeed Insights
• GTmetrix
• Google mobile page speed benchmarks
• Core Web Vitals (web.dev)