We audited 50 school district websites last week. Here's what we found:

Metric Result
Running WordPress Multisite 38 (76%)
Average Lighthouse mobile score 41
Average plugins per site 23
Working search 12 (24%)
Mobile-optimized 18 (36%)
ADA compliant 7 (14%)
Updated in last 6 months 22 (44%)

These are the websites that 5 million families use to find bus schedules, school closures, lunch menus, and teacher contact information. They deserve better.

I've spent the last decade building web platforms, and I've never seen a sector where the gap between what users need and what they get is this wide. School district websites aren't e-commerce stores or SaaS marketing pages. They're critical public infrastructure. When a parent can't find the snow day announcement at 6 AM on their phone, that's a real failure with real consequences. When a Spanish-speaking family can't find the free lunch application, kids go hungry.

This article breaks down exactly why K-12 websites are stuck, what a modern replacement architecture looks like, and the actual cost math that makes the switch a no-brainer.

Table of Contents

School District Websites Still on WordPress Multisite: The $30K Fix

The Four Problems Killing K-12 Websites

School district websites don't fail for one reason. They fail because four problems compound on each other, and nobody has the bandwidth to untangle them.

The IT Staff Crisis

Here's a number that should shock you but won't surprise anyone who works in education: the average school district IT team is 2-3 people. These 2-3 humans are managing 20-50 school websites PLUS email, the student information system (SIS), the learning management system (LMS), the network infrastructure, and somewhere around 10,000 devices (Chromebooks, teacher laptops, interactive whiteboards, printers).

There is zero bandwidth for website management. Zero.

I talked to an IT director at a mid-size district in Texas last year. He told me his team hadn't touched the WordPress Multisite installation in eight months. Not because they didn't care -- because they were drowning in Chromebook repairs, Google Workspace migrations, and a ransomware scare that ate three weeks of everyone's life.

The result? Sites go unupdated for months. Broken links accumulate. Outdated information stays live. The assistant principal who retired two years ago is still listed as the main contact. The lunch menu shows September 2023. The enrollment form links to a 404.

This isn't laziness. It's a resource allocation crisis. When you force IT staff to choose between keeping the network running and updating the website, the website loses every time.

The Teacher Content Update Breakdown

Teachers want to update their class pages. They genuinely do. They want to post the syllabus, share homework assignments, and put up announcements about the science fair.

But WordPress is too complex for non-technical staff. I don't mean that condescendingly -- I mean the WordPress admin interface was designed for people who build websites, not people who teach third-grade math. The Gutenberg editor, the plugin conflicts, the media library, the taxonomy system, the revision history... it's a lot.

So here's what actually happens:

  1. Teacher tries to update their page
  2. Something breaks (wrong template, formatting issue, accidentally deleted a widget)
  3. Teacher emails IT
  4. IT has a 3-week backlog
  5. Teacher gives up
  6. Teacher posts everything on Google Classroom instead

Now the official school website is irrelevant to daily school communication. Parents end up juggling 3-5 different apps: the school website (for the stuff that's still there), Google Classroom (for actual assignments), ParentSquare (for announcements), Remind (for quick messages), and maybe a Facebook group for good measure.

And they still can't find the bus schedule.

This fragmentation is maddening for families. It's especially brutal for parents who aren't tech-savvy or who have kids at multiple schools in the district. The school website should be the single source of truth. Instead, it's the one place nobody looks.

ADA Compliance as a Ticking Lawsuit

This one keeps superintendents up at night -- or it should.

School districts are increasingly targets of ADA lawsuits for inaccessible websites. And the settlements aren't cheap. A single ADA lawsuit can cost a district $30,000 to $100,000+ in legal fees and remediation costs. In 2024, the DOJ finalized rules specifically requiring state and local government websites (including school districts) to meet WCAG 2.1 Level AA compliance, with deadlines starting in April 2026 for larger entities.

Now think about WordPress Multisite with 50 school sites. That's 50 potentially non-compliant sites. Each one maintained by a different person (or nobody). Each one with a different set of plugins, a different template configuration, different image alt text habits (or lack thereof), and different approaches to heading hierarchy.

Auditing 50 sites individually? Remediating 50 sites individually? That's hundreds of hours of work. And it has to be done again every time someone adds content, because one teacher uploading a PDF without proper tagging or an image without alt text puts that school's page back out of compliance.

Here's what a multi-tenant architecture gives you: one compliant codebase means all 50 schools are compliant automatically. The components enforce accessibility. The heading structure is correct by default. Image uploads require alt text. PDFs get flagged if they're not tagged. You fix an accessibility issue once, and it's fixed everywhere.

Translation Failure Is an Equity Crisis

In diverse school districts, 30-50% of families speak a language other than English at home. Spanish, Vietnamese, Arabic, Mandarin, Haitian Creole -- it depends on the community, but the numbers are significant.

And their school websites? English only.

These families can't find enrollment information. They can't navigate the free and reduced lunch application process. They can't figure out the transportation routes. They miss events, deadlines, and opportunities.

This isn't a nice-to-have. Title VI of the Civil Rights Act requires school districts receiving federal funding to communicate effectively with limited-English-proficient (LEP) parents. An English-only website is a compliance risk on top of being an equity failure.

Let's look at the cost of fixing this:

Solution Annual Cost
WPML on WordPress (50 sites × $199/yr) $9,950/year + ongoing translation costs
Finalsite No real multi-language support
Google Translate widget Inaccurate, breaks layout, ADA nightmare
Next.js + next-intl + batch translation ~$110 one-time for 5 languages

That $110 figure isn't a typo. With a properly internationalized Next.js application using next-intl, you extract all content strings, run them through a translation API at roughly $22 per language, review with native speakers, and you're done. Add a language as your community needs it. The routing handles /es/schools/lincoln-elementary automatically.

The Google Translate widget that half these districts are using? It produces grammatically broken translations, breaks the page layout, creates accessibility issues, and -- critically -- it doesn't translate content inside images or PDFs. It's a band-aid that signals to families: "We don't care enough to do this properly."

Why WordPress Multisite Was the Wrong Bet

To be fair, WordPress Multisite wasn't an unreasonable choice in 2014-2016. It was free (ish). It could technically run multiple sites from one installation. There was a huge ecosystem of plugins. And districts could find WordPress developers.

But here's what happened over the next decade:

  • Plugin sprawl: Each site accumulated plugins for things the core couldn't do. SEO, forms, calendars, accessibility overlays (which don't actually work, by the way), translation, caching, security. Our audit found an average of 23 plugins per site. That's 23 potential security vulnerabilities, 23 things that can conflict, 23 things that need updates.
  • PHP version debt: Many of these installations are running on PHP versions that are end-of-life. Updating PHP risks breaking plugins. Not updating PHP is a security hole.
  • The Gutenberg mess: WordPress's shift to the block editor broke workflows for teachers who had just barely learned the classic editor. Many districts are still running the Classic Editor plugin, which is itself aging out.
  • Performance death spiral: WordPress serves server-rendered HTML from a MySQL database for every request. Add WooCommerce (yes, some schools run merch stores), BuddyPress, or any heavy plugin, and you're looking at 3-5 second load times. On mobile over a school parking lot's cell connection? Forget it.
  • Security surface area: WordPress powers 43% of the web, which makes it the #1 target for automated attacks. A single compromised plugin across your multisite? Every school site is exposed.

WordPress Multisite was the pragmatic choice a decade ago. It's technical debt now.

The Vendor Trap: Finalsite, Blackboard, and SchoolPointe

The alternative that most districts consider is a K-12 website vendor. Finalsite is the big name. There's also Blackboard (now Anthology), SchoolPointe, Apptegy (Thrillshare), and a few others.

These platforms solve some problems. They handle hosting. They provide templates. They have some accessibility features. But they come with serious trade-offs:

Cost: Finalsite for a district with 45 schools runs $135,000 to $360,000 per year. That's not a one-time cost. That's recurring. Every year. Forever. If you want to leave, you're starting from scratch -- there's no easy export of your content and structure.

Inflexibility: You get what they give you. Need a custom integration with your SIS? That'll be a professional services engagement. Want to change how the calendar works? Submit a feature request and wait. Your district has a unique bilingual program that needs custom routing? Sorry, that's not in the template.

Performance: I ran Lighthouse audits on several Finalsite-hosted district websites. Scores ranged from 35 to 62 on mobile. These are marketing websites, essentially -- server-rendered pages with heavy JavaScript bundles, third-party tracking scripts, and unoptimized images. They're not fast.

Lock-in: This is the big one. Your content lives in their CMS. Your URLs are structured their way. Your data model follows their schema. Three years in, switching costs are enormous. They know this. That's the business model.

I'm not saying these vendors are evil. They provide a real service for districts that have zero technical capacity. But if you have the option to invest in infrastructure you own, the math points overwhelmingly in that direction.

School District Websites Still on WordPress Multisite: The $30K Fix - architecture

The Fix: Multi-Tenant Next.js Architecture

Here's what we actually build. One application. Deployed once. Serving every school in the district.

/                          → District homepage
/schools/[slug]            → School homepage (45 schools)
/schools/[slug]/calendar   → School-specific events
/schools/[slug]/staff      → Staff directory
/schools/[slug]/staff/[id] → Teacher's class page
/[lang]/schools/[slug]     → Translated version (es, vi, ar, zh, ht)
/portal                    → Parent portal (auth required)
/admin                     → Teacher/staff content portal

45 schools = 45 programmatic routes from one codebase. One deployment. One place to fix bugs. One place to enforce accessibility. One place to add features.

The Tech Stack

Framework:     Next.js 15 (App Router)
CMS:           Headless (Sanity or Payload CMS)
Auth:          Supabase Auth + Row-Level Security
i18n:          next-intl
Hosting:       Vercel (or Cloudflare Pages)
Search:        Algolia or Typesense
Accessibility: axe-core in CI/CD pipeline

Teacher Portal

This is the piece that changes everything for daily operations. Teachers log in with their district Google account (SSO via Supabase Auth). They see their class page. They can:

  • Update their syllabus (rich text editor, not WordPress Gutenberg)
  • Post homework assignments with file attachments
  • Add announcements
  • Update office hours and contact info

That's it. No sidebars, no widgets, no plugin settings, no "are you sure you want to update?" confirmations. A focused interface that does four things well.

Row-Level Security (RLS) in Supabase means teachers can only edit their own content. No admin oversight needed. No IT tickets.

-- Supabase RLS policy: teachers can only update their own class page
CREATE POLICY "Teachers can update own content"
  ON class_pages
  FOR UPDATE
  USING (auth.uid() = teacher_id);

Parent Portal

Parents authenticate and see a personalized view based on their enrolled children. Bus route for their kid. Lunch menu for their school. Upcoming events filtered to relevant schools. Teacher contact info for their child's current teachers.

No more digging through 45 school sites to find information about your three kids at three different schools.

Accessibility by Default

The component library enforces WCAG AA. Every <Image> component requires alt text. Heading hierarchy is enforced by the page template. Color contrast is validated at build time. Focus management is handled in the navigation components.

We run axe-core in the CI/CD pipeline. Every pull request gets an accessibility audit. If it fails, it doesn't deploy. Period.

This matters when you have 200 teachers adding content. You can't train 200 people on accessibility. You can build a system that makes non-compliance structurally impossible.

Performance

Next.js with static generation means school pages are pre-rendered at build time and served from a CDN. A parent in the school parking lot on a 3G connection gets the page in under a second. Lighthouse scores consistently hit 90+.

We're talking about the difference between a 41 Lighthouse score (WordPress Multisite average from our audit) and a 95. That's not an incremental improvement. It's a different experience.

The Math That Makes This Obvious

Let's do the three-year total cost of ownership for a district with 45 schools:

Solution Year 1 Year 2 Year 3 3-Year Total
Finalsite $135-360K $135-360K $135-360K $405K-$1,080K
WordPress Multisite (maintain existing) $30-50K $30-50K $30-50K $90-150K
Next.js Multi-Tenant (build + host) $60-100K + $540 $540 $540 $61-101K

The Next.js hosting cost is $45/month on Vercel Pro, or even less on Cloudflare Pages. That's $540/year for a platform serving 45 schools. The WordPress hosting alone is typically $500-1,500/month for a managed multisite installation.

Break-even versus Finalsite: 3-6 months. Break-even versus ongoing WordPress maintenance: year one.

And here's what the WordPress cost column doesn't capture: the IT staff time. Those 2-3 IT people spending 10-15 hours a week on website firefighting? That's $30-50K in salary allocation that could go toward literally anything else. Chromebook management. Cybersecurity. Actually getting a full night's sleep.

The $60-100K build cost for the Next.js platform is a one-time investment. You own it. No annual license. No per-school fees. No vendor lock-in. Add a 46th school? It's a new entry in the CMS, not a sales call.

What the Migration Actually Looks Like

We're not going to pretend this is trivial. Migrating 45 school websites is a project. Here's how it breaks down:

Weeks 1-3: Discovery and Content Audit

  • Inventory all existing content across 45 sites
  • Identify what's actually current vs. what's abandoned
  • Map the information architecture
  • Interview IT staff, teachers, and parents about pain points

Weeks 4-8: Platform Build

  • Multi-tenant Next.js application with headless CMS integration
  • Teacher portal with Supabase Auth
  • Component library with baked-in accessibility
  • i18n setup with next-intl
  • CI/CD pipeline with automated accessibility testing

Weeks 9-12: Content Migration and Training

  • Automated content migration scripts (WordPress REST API → headless CMS)
  • Manual content review and cleanup
  • Teacher training (30-minute sessions -- if it takes longer, the UX needs work)
  • Parent portal soft launch

Weeks 13-14: Launch

  • DNS cutover
  • Redirect mapping (every old URL gets a 301)
  • Monitoring and support

Total timeline: 14 weeks. That's one semester. You can launch over winter break when traffic is lowest.

The key insight: you're not rebuilding 45 websites. You're building one website that serves 45 schools. That's an order-of-magnitude reduction in complexity.

If your district is exploring this kind of migration, we've done this work before. Reach out and we can walk through the specifics for your district size and needs. You can also check our pricing page for ballpark ranges on projects like this.

FAQ

How much does a school district website redesign cost? It depends on the approach. Vendor platforms like Finalsite run $135,000-$360,000 per year for a 45-school district. Maintaining an existing WordPress Multisite costs $30,000-$50,000 per year in IT time, hosting, and development support. A custom multi-tenant Next.js build runs $60,000-$100,000 as a one-time investment with roughly $540/year in hosting. Over three years, the custom build is the cheapest option by a wide margin -- and you own the platform.

Is WordPress Multisite good for school districts? It was a reasonable choice in 2014-2016, but it's become a liability. The plugin sprawl, security surface area, poor mobile performance, and inability to enforce accessibility across 50 sites make it a poor fit for modern K-12 requirements. Each site in the network can drift in different directions, and with 2-3 IT staff managing everything else in the district, nobody has time to keep it maintained. Districts running WordPress Multisite from 2016 are carrying significant technical debt.

What are the ADA compliance requirements for school district websites? The DOJ finalized rules in 2024 requiring state and local government websites -- including public school districts -- to meet WCAG 2.1 Level AA standards. Larger entities face deadlines starting April 2026. Non-compliance can result in lawsuits with settlements ranging from $30,000 to over $100,000 in legal fees and remediation. The key challenge for districts is that compliance isn't a one-time fix -- every piece of content added must maintain compliance, which is why building accessibility enforcement into the platform itself is the only sustainable approach.

How do you handle multiple languages on a school website? With a Next.js application using next-intl, internationalization is built into the routing structure. Each language gets its own URL prefix (/es/, /vi/, /ar/), which is better for SEO and accessibility than a Google Translate widget. Content translation for 5 languages costs roughly $110 using translation APIs with native-speaker review. Compare that to WPML on WordPress at $199/year per site ($9,950/year for 50 sites), and the savings are dramatic. More importantly, the translations are accurate, properly formatted, and don't break the page layout.

Can teachers update their own pages without IT support? Yes -- that's the entire point of the teacher portal. Teachers authenticate with their district Google account, see a simplified editor for their class page, and can update their syllabus, post assignments, add announcements, and update contact info. Row-Level Security ensures they can only edit their own content. No IT tickets, no 3-week backlog, no giving up and posting everything to Google Classroom instead. If the editing interface requires a training session longer than 30 minutes, we consider that a UX failure and redesign it.

How long does it take to migrate a school district website? For a 45-school district, expect a 14-week timeline: 3 weeks for discovery and content audit, 5 weeks for platform build, 4 weeks for content migration and training, and 2 weeks for launch. The best time to launch is over winter or summer break when website traffic is lowest. Content migration is partially automated using the WordPress REST API to extract content into the new headless CMS, but manual review and cleanup is necessary since much of the old content is outdated.

What's better for school websites: Finalsite or a custom build? Finalsite makes sense for districts with absolutely zero technical capacity and budget for ongoing licensing. For districts that can invest in a one-time build, a custom multi-tenant Next.js platform costs less over three years ($61-101K vs. $405K-$1.08M), performs better (Lighthouse 95+ vs. 35-62), offers full ownership of content and infrastructure, and provides flexibility for custom integrations with SIS, LMS, and other district systems. The trade-off is that you need a development partner for the initial build and ongoing feature development.

Why are school district websites so slow on mobile? Most district sites run WordPress with 20+ plugins, each adding JavaScript and CSS to every page load. The server-rendered pages require a database query for every request. Images are often unoptimized. There's no CDN, or the CDN is misconfigured. Add a shared hosting environment and you're looking at 3-5 second load times. On a mobile connection in a school parking lot, it's even worse. A statically generated Next.js site serves pre-built HTML from edge servers worldwide, typically loading in under one second. That matters when a parent is checking for a snow day at 6 AM on their phone.

Do school districts own their website if they use a vendor like Finalsite? No. Your content lives in their CMS, structured according to their data model, hosted on their infrastructure. If you decide to leave, you're essentially starting over. There's no clean export of your content, templates, or configuration. This lock-in is by design -- it's what makes the recurring revenue model work. With a custom build using a headless CMS like Sanity or Payload, you own every piece of content, every line of code, and every deployment configuration. You can switch hosting providers, change your front-end framework, or bring development in-house without losing anything.

Your district website is the front door for 10,000 families. If that front door doesn't open on a phone, doesn't speak their language, and doesn't let teachers update their own pages -- it's failing everyone it's supposed to serve.