One Association, Twelve Chapter Websites: The Models That Actually Work

A prospective member searches for your association and lands on your Ohio chapter. The logo is a version you retired four years ago. The events page still lists a conference from 2023. There is a members-only login that does not connect to anything, and a donate button that goes to a personal payment account. Nobody at the national office knew any of it was there.

This is not an unusual story. Every federated association hits this, and most of them treat it as a design problem. It is a governance problem wearing a design problem's clothing, and solving it in the wrong order is why it keeps coming back.

Why It Happens, and Why Nobody Is the Villain

Chapters are usually run by volunteers with day jobs. Someone's nephew builds a site, or a board member buys a template on a weekend. It works well enough for a while. Then that volunteer rotates off, the password goes with them, the hosting renews on a credit card nobody can identify, and the site quietly drifts.

Notice there is no bad actor in that story. The chapter did nothing wrong. They had a need, no budget, and no offer from national. In the absence of an alternative, twelve independent decisions produced twelve independent websites, and every one of them was locally reasonable.

What Consolidation Is Worth

The benefits are easy to underestimate because the current costs never appear on a budget line.

• Brand credibility. A member cannot tell whether a chapter site is official. Neither can a prospect, a sponsor, or a journalist. Every inconsistent chapter site is a small withdrawal from the same account.
• Security exposure. Twelve unmaintained WordPress installs are twelve unpatched attack surfaces carrying your name. When one gets defaced or starts serving spam, the headline says your association, not the chapter.
• Data and privacy. If chapter sites collect member data on forms that email a volunteer's personal inbox, your organization has a data handling problem it does not know about and cannot document.
• Search cannibalization. Chapter sites compete with your own pages for the same terms, and thin duplicate content across a dozen domains does the whole federation no favors in search.
• Duplicated effort. Every chapter separately solving events, membership inquiries, and newsletter signup is the same problem paid for a dozen times, badly.

The Three Models, Honestly Compared

There are only really three answers, and the right one depends on your governance rather than your technology.

• One site, chapter sections. Chapters get a section of the national site, with a chapter-scoped editor role and templates they cannot break. Cheapest to run, strongest brand consistency, and the least autonomy. Works when chapters are administrative units rather than independently incorporated bodies.
• Multisite with shared templates. A shared installation where each chapter has its own site, its own domain if wanted, and its own administrators, all on one codebase and one update cycle. This is the model most federated associations should look at first. Chapters feel ownership, national keeps the security and the templates.
• Independent sites, shared toolkit. National publishes an approved theme and a hosting arrangement, chapters opt in. Preserves autonomy where chapters are legally separate and will not accept central control. Weakest consistency, and it only works if the offer is genuinely better than what a volunteer can arrange alone.

Choose on governance, not features. The technology question is downstream of one governance question: can national require anything of a chapter, or only offer? Answer that honestly before anyone opens a design tool, because a model that assumes authority you do not have will fail regardless of how well it is built.

The Offer That Actually Gets Adopted

Mandates fail in volunteer federations. What works is making the central option so obviously easier that opting out looks like extra work.

Make the good path the easy path. A chapter chair should be able to get a working site with their events, their board roster, and their contact form in an afternoon, without a budget request, without finding a developer, and without becoming the person responsible for updates for the next three years. When that is on the table, adoption is not a fight. The chapters that hold out are usually the ones with a genuinely different need, and those are worth listening to rather than overruling.

What to Do Before Any of This

Inventory what exists. Most national offices genuinely do not know how many chapter websites there are, what they run on, who controls the domains, or where the hosting is billed.

• List them. Every chapter URL you can find, including the ones nobody linked from your site.
• Find the registrar. Who owns the domain registration and when it renews. Expired chapter domains get bought by strangers, and that is a worse day than an outdated logo.
• Check the platform. What platform and version each one runs. A chapter site on a five-year-old install is the security item to handle first, ahead of any design work.
• Identify the human. Who has the passwords today, by name. If the answer is a volunteer who left in 2024, that site is already effectively abandoned.

That inventory usually takes a couple of days and it reliably produces at least one genuine surprise. It is also the document that turns a vague board conversation about branding into a specific, costed decision.

What Chapters Should Never Have to Build Themselves

Whichever model you pick, a few things belong at national permanently, because a volunteer should never be the last line of defense on them.

• Updates and patching. Chapters should not each be deciding when to apply a security release. That is the single strongest argument for a shared platform and it is the one that eventually convinces reluctant boards.
• Forms and data capture. If a chapter collects an email address, it should land in the same system as everything else, under the same retention rules, with the same unsubscribe handling. Twelve separate contact databases is a compliance problem waiting for a complaint.
• Member authentication. Members should not need a separate account for the chapter they belong to. If the chapter site cannot recognize a logged-in member, it will always feel like a different organization.
• Templates and brand assets. Not a PDF of brand guidelines nobody opens. Actual templates where the logo, colors, and typography are correct because they are built in and cannot be overridden by accident.

And what should stay local. Notice what is not on that list: content. Chapters should absolutely control their own events, their own board roster, and their own local news. Central control over infrastructure and local control over content is the split that works, and confusing the two is what makes chapters resist.

When Consolidation Is the Wrong Answer

If your chapters are separately incorporated, raise their own money, and have their own boards, a consolidation push can read as a takeover and cost you goodwill worth more than the brand consistency you gain. In that situation the shared-toolkit model is not a compromise, it is the correct answer, and pretending otherwise damages the relationship.

Equally, if you have three chapters and two of them are dormant, this is not a platform project. Fix the one active chapter's site and move on.

Where to Start

Do the inventory. Not the redesign, not the platform evaluation, not the RFP. Until you know how many sites carry your name, who controls them, and what they are running, every other conversation is speculation, and the inventory is the part you can start this week without spending anything.