Notes from the middle of the problem
I’ve sat in enough rooms where a website rebuild gets decided by default, because the old one is embarrassing, because a board member mentioned it, because someone got a quote and it seemed manageable, to know that most of these projects start without a clear idea of what they’re actually trying to fix.
That’s not a criticism. CLCs are busy, often short-staffed and battling multiple fronts. The website is rarely the most pressing thing. But it is the first thing many people see when they’re trying to figure out whether you can help them, and how to reach you, often at a point when they’re frightened, confused, or running out of options.
So before the project plan gets written, before the quotes go out, before anyone starts talking about platforms and plugins and colour palettes: some things worth thinking through carefully.
The website serves the client, not the centre
This sounds obvious. It isn’t, in practice.
Most CLC websites are built around the organisation’s logic: what services we offer, what our practice areas are, who our staff are, what our funding history looks like. This reflects how centres think about themselves, which is reasonable. It’s just not how someone in crisis thinks about finding help.
Someone being threatened with eviction is not searching for “tenancy law practice area.” They’re searching something like “can my landlord kick me out if I haven’t paid rent in a dispute.” Someone whose partner has taken their children is not browsing your family law page — they’re trying to find out if they have any rights and whether there’s anyone who can help them today.
The most useful thing a CLC website can do is speak directly to those moments. Not in legal language. Not in the language of a service system. In plain English, with short sentences, and a very clear answer to the question: can you help me, and how do I reach you?
If your website currently can’t do that well — and most can’t — that’s the problem worth solving. Everything else is secondary.
The content problem almost always gets left to the end
Here’s a pattern that repeats itself constantly in community sector website projects: most of the budget and attention goes to design and development. The content question — what will actually go on this site, and who is going to write or update it — gets deferred. Then, in the final weeks of the project, there’s a scramble to migrate old content or produce new copy quickly.
The result is usually a beautiful new site carrying the same unclear, outdated, legally uncertain content as the old one.
The reversal of this sequence — content before design, or at minimum in parallel — is not a complicated idea, but it requires someone with authority to insist on it. That might be the project manager, the principal solicitor, or the CEO. Whoever it is needs to understand that content is not copywriting. For a CLC, it means reviewing your legal information against current law, writing for people who are not lawyers, making genuine decisions about what your site should and shouldn’t try to answer, and removing things that are no longer true.
This is time-consuming. It is also the work that determines whether the rebuild was worth doing.
Accessibility isn’t a feature you add on
Under the Disability Discrimination Act 1992, failing to make your website accessible to people with disability is not just an oversight — it’s potentially a legal exposure. The practical standard to aim for is WCAG 2.1 Level AA: screen reader compatibility, keyboard navigation, readable contrast ratios, captions on video, clear form labels.
Many popular website templates fail basic accessibility tests out of the box. Many developers, if not explicitly asked, will not build to WCAG standards. Accessibility testing using automated tools is useful but not sufficient — it should be complemented by testing with people who use assistive technologies.
The people who most need CLC services are disproportionately likely to include people with disabilities, people with low digital literacy, people accessing from older devices on limited data. Building an inaccessible website is, in a meaningful sense, building a website that works for the people who need it least.
Make WCAG 2.1 AA compliance a contractual requirement. Ask for it in writing before you sign anything.
Who owns the site after the project ends?
This question catches more organisations than it should. It’s a quieter issue that rarely makes it into the early discussion.
When a web project closes, when the developer has been paid and the project is signed off, there are several things that need to have a clear owner: the domain name registration, the hosting account, the CMS administrator access, any third-party service accounts connected to the site. If any of these are sitting with a developer or a former staff member and there’s no documented process for transferring them, you have a problem waiting to happen.
Domain names lapse. Hosting bills go unpaid. A developer who did the work three years ago and has since started a different business becomes, over time, harder to reach. These are not hypothetical situations — they’re routine events in the community sector, and they’re almost entirely preventable with some basic documentation at the time of project completion.
Your board should be able to answer this question clearly before approving a website project: after this is done, who controls it, and what’s the handover process? The question of ongoing stewardship after the completion is often left untill it’s all too late.
When organisations rebuild without addressing that drift, they carry it forward into a more polished container.
Websites are not static objects. They age in the background. Plugins become outdated. Hosting arrangements outlive the staff member who set them up. Privacy policies stop reflecting how forms actually function. None of this happens dramatically. It happens incrementally.
If there is no clear ownership of maintenance and oversight after launch, the rebuild simply resets the cycle.
The platform conversation is not the most important conversation
Everyone has a view on WordPress. Some organisations are enthusiastic about it. Some have had bad experiences with it. The debate over whether to use WordPress, Squarespace, Webflow, or something else is a legitimate one — but it tends to consume more attention than it deserves, relative to the questions above.
What matters more than platform is maintainability. Whoever makes the platform decision should be asking: can the staff who will actually manage this site after launch do so without needing to call the developer? Can the site be kept secure and updated without specialist IT support? What happens to the site if the person who manages it now leaves?
A complex, highly customised WordPress site managed by one technically-proficient staff member is more fragile than a simpler site on a managed platform that multiple people can update. Simplicity is not a compromise — it is often the right answer.
A note for boards
Accessible website rebuilds are capital expenditure decisions. They warrant the same scrutiny as any other significant spend: multiple quotes, a clear brief, explicit approval, and defined success criteria.
They also warrant thinking about what the organisation is actually committing to. The cost of a website rebuild is not just the build cost. It includes content development, ongoing hosting and maintenance, periodic updates, and — eventually — the cost of doing it again. Organisations that treat the build cost as the full cost often find themselves with a site that works at launch and deteriorates steadily over the following two years.
Before approving a rebuild, a board should have clear answers to: what problem are we solving, who will manage this after launch, and what does success look like in twelve months? If those questions don’t have clear answers, the project is not ready to proceed.
The website is not the most important thing your centre does. But it is the door through which many people will try to reach the most important things you do. It’s worth getting right, which mostly means taking the time to understand the problem before proposing a solution.
Modernising a CLC website does not require a dramatic reinvention. In fact, the most effective rebuilds are often barely noticeable in tone. They feel more stable, not more corporate. They feel easier, not more sophisticated. The question is rarely whether a centre deserves a better website. It almost always does.
The more important question is whether the organisation is ready to treat its digital presence as part of its service model, something that requires care over time, rather than as a project to complete and close.
That distinction tends to determine whether the conversation comes back again in three years.
If your centre is reconsidering its digital foundations this year, it may be worth starting with a diagnosis rather than a design brief.
This piece reflects the author’s observations from work in the community legal sector. It does not constitute legal or procurement advice. For guidance specific to your centre, consult your state or territory peak body.