学区のウェブサイトはまだWordPress Multisiteで運用中: $30Kの解決策
先週、50の学区ウェブサイトを監査しました。以下が私たちの調査結果です:
| メトリクス | 結果 |
|---|---|
| WordPress Multisiteを実行中 | 38 (76%) |
| 平均Lighthouse モバイルスコア | 41 |
| サイトあたりの平均プラグイン数 | 23 |
| 動作する検索機能 | 12 (24%) |
| モバイル最適化 | 18 (36%) |
| ADA準拠 | 7 (14%) |
| 過去6ヶ月以内に更新 | 22 (44%) |
これらは500万世帯がバススケジュール、学校閉鎖、給食メニュー、教職員の連絡先を見つけるために使用するウェブサイトです。もっと良いものを必要としています。
私は過去10年間ウェブプラットフォームを構築してきましたが、ユーザーが必要とするものと実際に得られるものの間にこれほど大きなギャップがあるセクターを見たことがありません。学区のウェブサイトはeコマースストアやSaaSマーケティングページではありません。これらは重要な公共インフラストラクチャです。親が午前6時にスマートフォンで雪の日の発表を見つけることができない場合、それは本当の障害であり、実際の結果をもたらします。スペイン語を話す家族が無料の給食申請を見つけることができない場合、子どもたちは飢えてしまいます。
この記事は、K-12ウェブサイトが立ち往生している理由、最新の置き換えアーキテクチャがどのように見えるか、そしてスイッチを当たり前にする実際のコスト計算を詳しく説明しています。
目次
- K-12ウェブサイトを殺す4つの問題
- WordPress Multisiteが間違った賭けだった理由
- ベンダートラップ:Finalsite、Blackboard、SchoolPointe
- 解決策:マルチテナントNext.jsアーキテクチャ
- この明白な数学
- 実際の移行はどのようなものか
- FAQ

K-12ウェブサイトを殺す4つの問題
学区のウェブサイトは1つの理由で失敗するわけではありません。4つの問題が互いに複合し、誰もそれらを解き明かす帯域幅がないため失敗します。
IT スタッフ危機
ここに教育分野で働く誰もが驚かないが、あなたを驚かすべき数字があります:平均的な学区のITチームは2~3人です。これら2~3人の人間が20~50のスクールウェブサイトに加えて、メール、学生情報システム(SIS)、学習管理システム(LMS)、ネットワークインフラストラクチャ、および約10,000台のデバイス(Chromebook、教職員のラップトップ、インタラクティブホワイトボード、プリンター)を管理しています。
ウェブサイト管理に充てる帯域幅はゼロです。ゼロです。
昨年、テキサス州の中規模学区のIT部長と話をしました。彼は、彼のチームが8ヶ月間WordPress Multisiteインストールに一切触れていないと言いました。彼らが気にかけていなかったからではなく、Chromebookの修理、Google Workspace移行、そして3週間の誰もの人生を食い尽くした身代金ウェアの脅迫に溺れていたからです。
結果は何か?サイトは数ヶ月更新されないままになります。壊れたリンクが蓄積します。古い情報は生きたままになります。2年前に退職した副校長はまだ主要な連絡先として記載されています。給食メニューは2023年9月を表示しています。登録フォームは404にリンクしています。
これは怠惰ではありません。これはリソース配分の危機です。ITスタッフにネットワークを稼働させることとウェブサイトを更新することを選ばせると、ウェブサイトは毎回負けます。
教職員のコンテンツ更新の崩壊
教職員は自分のクラスページを更新したいと思っています。彼らは本当にそう思っています。彼らはシラバスをポストし、宿題の課題を共有し、理科展についての発表を貼り付けたいのです。
しかし、WordPressは非技術的なスタッフにとって複雑すぎます。わざとではなく、WordPressの管理インターフェイスはウェブサイトを構築する人向けに設計されたもので、3年生の数学を教える人向けではないということです。Gutenbergエディタ、プラグインの競合、メディアライブラリ、タクソノミーシステム、リビジョン履歴...それは多くのことです。
それで、実際に何が起こるのか:
- 教職員は自分のページを更新しようとします
- 何か壊れます(間違ったテンプレート、フォーマットの問題、誤ってウィジェットを削除)
- 教職員はITにメールを送ります
- ITには3週間のバックログがあります
- 教職員は諦めます
- 教職員は Google Classroom にすべてをポストします
今、公式の学校のウェブサイトは日々の学校の通信には関係ありません。親は最終的に3~5の異なるアプリをジャグリングしています:学校のウェブサイト(まだそこにある材料用)、Google Classroom(実際の課題用)、ParentSquare(発表用)、Remind(クイックメッセージ用)、そして良い測度のためのFacebookグループです。
そして彼らはまだバススケジュールを見つけることができません。
この断片化は家族にとって気が狂ってしまいます。複数の学校に子どもがいる学区の親、または技術に詳しくない親にとって、それは特に残酷です。学校のウェブサイトは唯一の真実の源である必要があります。代わりに、それは誰も見ない場所です。
ADA準拠は時限爆弾のような訴訟
このものは学監を夜中に起こさせます - またはそうするべきです。
学区は、アクセスできないウェブサイトについてのADA訴訟の標的がますます増えています。そして和解は安くありません。単一のADA訴訟は学区に弁護士費用と改善費用で$30,000から$100,000以上の費用がかかる可能性があります。2024年、DOJは州および地方自治体のウェブサイト(学区を含む)を含む、WCAG 2.1 Level AA準拠を要求し、より大きなエンティティのための4月2026年から始まる期限を持つルールを最終化しました。
今、50のスクールサイトでWordPress Multisiteについて考えます。これは50の潜在的に非準拠のサイトです。それぞれ異なる人(または誰も)によってメンテナンスされています。異なるプラグインのセット、異なるテンプレート構成、異なる画像alt textの習慣(またはその欠如)、および見出し階層へのアプローチが異なります。
50のサイトを個別に監査する?50のサイトを個別に改善する?それは数百時間の作業です。そして、誰かがコンテンツを追加するたびに再度行う必要があります。1人の教職員がalt textなしでPDFをアップロードするか、alt textなしで画像をアップロードすると、その学校のページは準拠から外れます。
マルチテナントアーキテクチャが与えるもの:1つの準拠したコードベースは50のすべての学校が自動的に準拠していることを意味します。コンポーネントはアクセシビリティを実施します。見出し構造はデフォルトで正しいです。画像のアップロードには alt text が必要です。PDFはタグが付けられていない場合はフラグが立てられます。アクセシビリティの問題を1回修正すると、すべての場所で修正されます。
翻訳の失敗は公平性の危機
多様な学区では、30~50%の家族が家庭で英語以外の言語を話しています。スペイン語、ベトナム語、アラビア語、標準中国語、ハイチのクレオール語 - それはコミュニティによって異なりますが、数字は重要です。
そして彼らの学校のウェブサイト?英語のみ。
これらの家族は登録情報を見つけることができません。彼らは無料および削減給食の申請プロセスをナビゲートすることができません。彼らは交通経路を理解することができません。彼らはイベント、期限、機会を見逃します。
これは素晴らしい持っているもの ではありません。公民権法のタイトルVIは、連邦資金を受け取る学区に、限定英語習熟度(LEP)の親と効果的に通信することを要求しています。英語のみのウェブサイトは、公平性の失敗であるのと同じくらい準拠リスクです。
このパッチを当てるコストを見てみましょう:
| ソリューション | 年間コスト |
|---|---|
| WordPress上のWPML(50サイト×$199/年) | $9,950/年+継続的な翻訳コスト |
| Finalsite | 本当の多言語サポートなし |
| Googleクイック翻訳ウィジェット | 不正確、レイアウトを破壊、ADAの悪夢 |
| Next.js + next-intl +バッチ翻訳 | 5言語のための約$110のワンタイム |
その$110の数字はタイプミスではありません。next-intlを使用して適切に国際化されたNext.jsアプリケーションを使用して、すべてのコンテンツ文字列を抽出し、翻訳APIを介して実行し、ネイティブスピーカーと一緒に確認し、完了です。コミュニティが必要なため、言語を追加してください。ルーティングは/es/schools/lincoln-elementaryを自動的に処理します。
これらの学区の半分が使用しているGoogleクイック翻訳ウィジェット?文法的に壊れた翻訳を生成し、ページレイアウトを破壊し、アクセシビリティの問題を作成し、重要なことに、画像またはPDF内のコンテンツを翻訳しません。それは家族への信号であるバンドエイドです:「私たちはこれを適切に行うのに十分なケアを行いません。」
WordPress Multisiteが間違った賭けだった理由
公平に言うと、WordPress Multisiteは2014~2016年には合理的な選択ではありませんでした。それはフリー(ish)でした。技術的には複数のサイトを1つのインストールから実行できました。プラグインの巨大なエコシステムがありました。そして学区はWordPress開発者を見つけることができました。
しかし、次の10年間に何が起こったのか:
- プラグイン拡散:各サイトはコアが実行できなかったものに対してプラグインを累積しました。SEO、フォーム、カレンダー、アクセシビリティオーバーレイ(実際には機能しません)、翻訳、キャッシング、セキュリティ。当監査では、サイトあたり平均23個のプラグインが見つかりました。それは23の潜在的なセキュリティ脆弱性、23の競合する可能性がある、23のアップデートが必要な機能です。
- PHPバージョンの債務:これらのインストールの多くは、生命の終わりを迎えたPHPバージョンで実行されています。PHPを更新するとプラグインを破壊するリスクがあります。PHPを更新しないことはセキュリティホールです。
- Gutenbergメス:WordPressのブロックエディタへのシフトは、クラシックエディタをようやく学んだばかりの教職員のワークフローを破壊しました。多くの学区はまだクラシックエディタプラグインを実行しており、それ自体が段階的に廃止されています。
- パフォーマンス死のスパイラル:WordPressはすべてのリクエストに対してMySQLデータベースからサーバーレンダリングHTMLを提供します。WooCommerce(はい、一部の学校はマーチストアを実行します)、BuddyPress、または重いプラグインを追加し、3~5秒のロード時間を見ています。学校の駐車場のモバイル接続を介して?忘れてください。
- セキュリティの表面積:WordPressはウェブの43%を強化し、自動化された攻撃の#1ターゲットにします。マルチサイト全体で単一の侵害されたプラグイン?すべての学校のサイトが公開されます。
WordPress Multisiteは10年前の実用的な選択でした。今はテクニカルデットです。
ベンダートラップ:Finalsite、Blackboard、SchoolPointe
ほとんどの学区が検討している代替案は、K-12ウェブサイトベンダーです。Finalsiteが大きな名前です。Blackboard(現在Anthology)、SchoolPointe、Apptegy(Thrillshare)、および他のいくつかもあります。
これらのプラットフォームはいくつかの問題を解決します。彼らはホスティングを処理します。彼らはテンプレートを提供します。彼らはいくつかのアクセシビリティ機能を持っています。しかし、彼らは深刻なトレードオフを伴います:
コスト:45の学校がある学区のFinalsiteは年間$135,000から$360,000で実行されます。これは一度のコストではありません。繰り返されるのです。毎年。永遠に。やめたい場合は、ゼロから始めています - コンテンツと構造の簡単なエクスポートはありません。
柔軟性がない:彼らが与えるものを得ます。SISを使用したカスタム統合が必要ですか?それは専門的なサービスの関与になります。カレンダーの動作方法を変更したいですか?機能リクエストを送信して待ちます。あなたの学区には、カスタムルーティングが必要なユニークなバイリンガルプログラムがありますか?申し訳ありませんが、それはテンプレートにはありません。
パフォーマンス:複数のFinalsiteで実行されている学区のウェブサイトでLighthouse監査を実行しました。スコアはモバイルで35から62の範囲でした。これらは本質的にマーケティングウェブサイトです - サーバーレンダリングされたページ、重いJavaScriptバンドル、サードパーティの追跡スクリプト、最適化されていない画像を備えています。彼らは速くありません。
ロックイン:これが大きなものです。あなたのコンテンツはそれらのCMSに存在します。あなたのURLは彼らの方法で構造化されています。あなたのデータモデルは彼らのスキーマに従います。3年で、スイッチングコストは莫大です。彼らはこれを知っています。それは事業モデルです。
これらのベンダーが邪悪だと言っているわけではありません。彼らはゼロの技術的能力を持つ学区に実際のサービスを提供します。しかし、あなたが自分が所有するインフラストラクチャに投資するオプションがあれば、数学はその方向に圧倒的に指しています。

解決策:マルチテナントNext.jsアーキテクチャ
これが私たちが実際に構築するものです。1つのアプリケーション。一度展開されました。学区のすべての学校を提供しています。
/ → 学区のホームページ
/schools/[slug] → 学校のホームページ(45の学校)
/schools/[slug]/calendar → 学校固有のイベント
/schools/[slug]/staff → スタッフディレクトリ
/schools/[slug]/staff/[id] → 教職員のクラスページ
/[lang]/schools/[slug] → 翻訳版(es、vi、ar、zh、ht)
/portal → 親ポータル(認証が必要)
/admin → 教職員/スタッフコンテンツポータル
45の学校 = 1つのコードベースから45のプログラムルート。1つの展開。バグを修正する1つの場所。アクセシビリティを実施する1つの場所。機能を追加する1つの場所。
テックスタック
Framework: Next.js 15 (App Router)
CMS: Headless (Sanity または Payload CMS)
Auth: Supabase Auth + Row-Level Security
i18n: next-intl
Hosting: Vercel (または Cloudflare Pages)
Search: Algolia または Typesense
Accessibility: axe-core in CI/CD pipeline
教職員ポータル
これは日々の操作のためにすべてを変えるピースです。教職員は地区のGoogleアカウント(Supabase Auth経由のSSO)でログインします。彼らは自分のクラスページを見ます。彼らができます:
- シラバスの更新(WordPressのGutenbergではなく、リッチテキストエディタ)
- ファイル添付付きの宿題課題のポスト
- 発表の追加
- オフィスアワーと連絡先情報を更新
それは全部です。サイドバーなし、ウィジェットなし、プラグイン設定なし、「更新するつもりですか?」確認なし。4つのことをうまく行う焦点を当てたインターフェース。
Supabaseの行レベルセキュリティ(RLS)は、教職員が独自のコンテンツのみを編集できることを意味します。管理者の監督は必要ありません。ITチケットはありません。
-- Supabase RLSポリシー:教職員は独自のクラスページのみを更新できます
CREATE POLICY "Teachers can update own content"
ON class_pages
FOR UPDATE
USING (auth.uid() = teacher_id);
親ポータル
親は認証し、登録済みの子どもに基づく個人用ビューを表示します。自分の子どもの路線バス。自分の学校の給食メニュー。関連する学校に絞られた次のイベント。現在の教職員の子どもの教職員の連絡先情報。
3つの異なる学校の3人の子どもについての情報を見つけるために45の学校サイトを掘り下げる必要はありません。
デフォルトでのアクセシビリティ
コンポーネントライブラリはWCAG AAを実施します。すべての<Image>コンポーネントは alt text を必要とします。見出し階層はページテンプレートによって実施されます。色のコントラストはビルド時に検証されます。フォーカス管理はナビゲーションコンポーネントで処理されます。
CI/CDパイプラインでaxe-coreを実行します。すべてのプルリクエストはアクセシビリティ監査を取得します。失敗した場合、デプロイされません。期間。
これは200人の教職員がコンテンツを追加している場合に重要です。200人の人にアクセシビリティについてトレーニングすることはできません。非準拠を構造的に不可能にするシステムを構築できます。
パフォーマンス
静的生成を備えたNext.jsは、学校のページがビルド時に事前生成され、CDNから提供されることを意味します。学校の駐車場で3G接続を使用している親は、1秒以下でページを取得します。Lighthouseスコアは一貫して90+を打ちます。
これは、41のLighthouseスコア(当監査からのWordPress Multisite平均)と95の間の違いについて話しています。それは増分改善ではありません。それは異なる経験です。
この明白な数学
45の学校がある学区の3年間の総所有コストを計算してみましょう:
| ソリューション | 1年目 | 2年目 | 3年目 | 3年間合計 |
|---|---|---|---|---|
| Finalsite | $135-360K | $135-360K | $135-360K | $405K-$1,080K |
| WordPress Multisite(既存を維持) | $30-50K | $30-50K | $30-50K | $90-150K |
| Next.js マルチテナント(ビルド+ホスト) | $60-100K + $540 | $540 | $540 | $61-101K |
Next.jsのホスティングコストは、Vercel ProまたはCloudflare Pagesでさらに少ないVercel Proで月$45です。それは45の学校を提供するプラットフォーム用の年$540です。WordPressのホスティングだけは通常、マネージドマルチサイトインストールの場合、月$500-$1,500です。
Finalsiteに対する損益分岐点:3~6ヶ月。継続的なWordPressメンテナンスに対する損益分岐点:1年目。
そして、ここで WordPressコスト列がキャプチャしないもの:IT スタッフの時間。週10~15時間をウェブサイトの消火に費やす2~3人のIT職員?これは、リソース配分の他にどこに使用できるのかについては$30-50Kの給与です。Chromebook管理。サイバーセキュリティ。実際に完全な夜の睡眠を取ることになります。
Next.jsプラットフォームの$60~100Kのビルドコストはワンタイムの投資です。あなたはそれを所有しています。年間ライセンスなし。学校ごとの料金なし。ベンダーロックインなし。46番目の学校を追加しますか?CMSの新しいエントリであり、営業電話ではありません。
実際の移行はどのようなものか
これが些細なことではないふりをするつもりはありません。45のスクールウェブサイトの移行はプロジェクトです。以下は分布を示しています:
1~3週目:ディスカバリーとコンテンツ監査
- 45のサイト全体の既存のコンテンツを在庫する
- 実際に現在のものと放棄されたものを特定する
- 情報アーキテクチャをマッピングする
- ITスタッフ、教職員、および親の痛みの点についてインタビューを実施
4~8週目:プラットフォームビルド
- headless CMS統合を備えたマルチテナントNext.jsアプリケーション
- Supabase Authを備えた教職員ポータル
- ベイク内アクセシビリティを備えたコンポーネントライブラリ
- next-intlでの i18n セットアップ
- 自動アクセシビリティテストを使用したCI/CDパイプライン
9~12週目:コンテンツ移行とトレーニング
- 自動コンテンツ移行スクリプト(WordPress REST API → headless CMS)
- 手動コンテンツレビューとクリーンアップ
- 教職員の研修(30分のセッション - それ以上かかる場合、UXを改善する必要があります)
- 親ポータルソフトローンチ
13~14週目:発売
- DNSカットオーバー
- リダイレクトマッピング(すべての古いURLが301を取得)
- モニタリングとサポート
合計タイムライン:14週間。これは1学期です。冬休みの間に発売できます。トラフィックが最も低い時です。
重要な洞察:45のウェブサイトを再構築していません。45の学校を提供する1つのウェブサイトを構築しています。これは複雑さのオーダー一桁の削減です。
あなたの学区がこのような移行を検討している場合、私たちは以前このタイプの仕事を行いました。お問い合わせして、学区のサイズとニーズについて詳細を見直してください。このようなプロジェクトの概算範囲について、価格ページも確認できます。
FAQ
学区のウェブサイトのリデザインにはどのくらいの費用がかかりますか? アプローチによって異なります。Finalsiteなどのベンダープラットフォームは、45校の学区の場合、年間$135,000~$360,000で実行されます。既存のWordPress Multisiteを維持するには、IT時間、ホスティング、および開発サポートで年間$30,000~$50,000かかります。カスタムマルチテナント Next.js ビルドは、概算で年$540のホスティングを備えたワンタイム投資として$60,000~$100,000で実行されます。3年間、カスタムビルドは大幅な差分で最も安いオプションです - そしてあなたはプラットフォームを所有しています。
WordPress MultisiteはK-12学区に適していますか? それは2014~2016年に合理的な選択でした。しかし、それはウェブサイト側に負債が蓄積され、セキュリティが増えていますが、依然としてプラグイン拡散、セキュリティ表面積、不十分なモバイルパフォーマンス、そして50のサイト全体にアクセシビリティを実施する能力のなさにより、現代のK-12要件には不適切になってきました。 2016年からWordPress Multisiteを実行している学区は、重大なテクニカルデットを携帯しています。
学区のウェブサイトのADA準拠要件は何ですか? DOJは2024年にWCAG 2.1レベルAA標準を満たすために、州および地方自治体のウェブサイト(公立学区を含む)を要求する規則を最終化しました。より大きなエンティティは、4月2026年から始まる期限に直面しています。非準拠は$30,000から$100,000以上の法務費用と改善費用の範囲の和解を伴う訴訟につながる可能性があります。学区の主な課題は、準拠が1回限りの修正ではないということです - 追加されたすべてのコンテンツは準拠を維持する必要があります。したがって、プラットフォーム自体にアクセシビリティ強制を構築することが唯一の持続可能なアプローチです。
学校のウェブサイトで複数の言語をどのように処理しますか?
next-intlを使用するNext.jsアプリケーションを使用すると、国際化はルーティング構造に組み込まれています。各言語は独自のURLプレフィックス(/es/、/vi/、/ar/)を取得し、これはGoogleクイック翻訳ウィジェットよりもSEOとアクセシビリティの面で優れています。翻訳APIを使用した5言語のコンテンツ翻訳は、ネイティブスピーカーレビューで大約$110で実行されます。WordPress上のWPMLと比較して、サイトあたり年$199(50サイトの場合$9,950/年)で、節約は劇的です。さらに重要なことに、翻訳は正確で、適切にフォーマットされ、ページレイアウトを破壊しません。
教職員はIT支援なしに独自のページを更新できますか? はい - それが教職員ポータル全体のポイントです。教職員は地区のGoogleアカウントで認証し、彼らのクラスページの簡素化されたエディタを見て、彼らのシラバス、ポスト課題、追加発表、および更新連絡先情報を更新できます。行レベルセキュリティはそれらが独自のコンテンツのみを編集できることを確保します。ITチケットなし、3週間のバックログなし、すべてGoogle Classroomへの投稿を諦めることはありません。編集インターフェイスが30分以上のトレーニングセッションを必要とする場合、私たちはそれをUX障害と見なし、それを設計し直します。
学区のウェブサイトの移行にどのくらい時間がかかりますか? 45校の学区の場合、14週間のタイムラインを予想します:ディスカバリーとコンテンツ監査で3週間、プラットフォームビルドで5週間、コンテンツ移行とトレーニングで4週間、ローンチで2週間です。最良のローンチ時間は、ウェブサイトのトラフィックが最も低い冬または夏の休日の間です。コンテンツ移行は、WordPress REST APIを使用してコンテンツを新しいheadless CMSに抽出することで部分的に自動化されていますが、古いコンテンツの多くが時代遅れであるため、手動レビューとクリーンアップが必要です。
学区のウェブサイトに最適なのはFinalsiteですか、カスタムビルドですか? Finalsiteは、技術的能力がまったくなく、継続的なライセンス予算がある学区に合理的です。一度のビルドに投資できる学区の場合、カスタムマルチテナント Next.js プラットフォームは3年で少ない費用($61-101K対$405K-$1.08M)で、より優れたパフォーマンス(Lighthouse 95+対35-62)、コンテンツとインフラストラクチャの完全な所有権、およびSIS、LMS、および他の学区システムへのカスタム統合の柔軟性を提供します。トレードオフは、初期ビルドと継続的な機能開発のために開発パートナーが必要ということです。
Finalsiteなどのベンダーを使用する場合、学区はウェブサイトを所有していますか? いいえ。あなたのコンテンツはそれらのCMS、彼らのデータモデルに従って構造化され、彼らのインフラストラクチャでホストされています。あなたが去ることを決定した場合、あなたは本質的にゼロから始めています。コンテンツ、テンプレート、または構成のクリーンエクスポートはありません。このロックインは設計による機能です - これが繰り返される収益モデルを機能させるものです。Sanityまたはペイロード CMSなどのheadless CMSを使用するカスタムビルドを使用して、あなたはコンテンツのすべての部分、コードのすべての行、すべてのデプロイ構成を所有しています。ホスティングプロバイダーを切り替えたり、フロントエンドフレームワークを変更したり、開発をハウスに持ち込んだりできます。何も失わずに。
あなたの学区のウェブサイトは10,000世帯の玄関です。その玄関がスマートフォンで開かない、彼らの言語を話しない、そして教職員が彼ら自身のページを更新させない場合 - それはそれが提供することになっているすべての人を失敗させています。