ホームページの保守費用の相場：払いすぎ・足りなすぎの見分け方

ホームページの保守に毎月払っている金額は高いのか安いのか。中小企業の Web 担当・経営者の方に向けて、この記事は「保守費用の相場はいくらか」と「自社の保守が払いすぎか、足りなすぎか」の2つに答えます。結論から言うと、ネットに出ている相場（小〜中規模のサイトで月5,000円〜5万円ほど、大規模や SEO・広告運用まで含むものはそれ以上）は各社の目安で、その幅を裏づける調査の件数・時期は示されていません。だから金額を比べるより、WordPress と PHP のバージョン、ドメインの名義、作業の記録の3つで中身を確かめるほうが確実です。そのための確認リスト、自分で動かせる確認用のスクリプト、乗り換えのときに渡してもらうもののリストを載せます。

保守費用の相場は小〜中規模で「月5,000円〜5万円ほど」。ただし幅を裏づける調査の件数・時期は示されていない

各社の記事に出ている保守費用は、小〜中規模のサイトなら、だいたい月5,000円から5万円ほどの幅に収まります。大規模なサイトや、SEO・広告運用まで含む保守はそれより高くなります（下の表）。ただ、これらの記事には、相場の幅のもとになった調査の件数・集計の時期が書かれていません。

制作会社や比較サイトが出している目安を並べると、次のとおりです（2026年10月15日に各ページで確かめた内容）。

出しているところ	書かれている月額の目安	数字の根拠の書き方
PRONI アイミツ（2026年6月更新）	最低限の管理は5,000〜1万円ほど、更新・バックアップ・セキュリティ対策を含むと1万〜5万円ほど	題に「取引実績で見る」とあり、同サービスで取引のあった個別の料金事例を載せているが、相場の幅のもとになった件数・集計期間の記載はない
＠SOHO（2026年9月更新）	小規模は5,000〜1万5,000円ほど、中規模は2万〜5万円ほど、大規模は5万〜20万円以上	規模別の幅そのものの根拠の記載なし
Fyve（2026年7月更新）	5,000円前後は維持管理が中心、1万〜2万円は不具合の修正・バックアップ・軽微な修正まで、3万〜5万円は更新代行や月次レポートまで、5万円超は SEO や広告運用まで	書き手が実務で見てきた範囲、と明記

この表から読み取れるのは「月額の差は、作業の範囲の差」ということです。月5,000円の保守と月3万円の保守では、そもそも約束している作業が違います。相場の数字に自社の月額を当てはめて「高い・安い」を決めるのは、中身の違う商品の値札を比べるのと同じです。

そこでこの記事では、金額ではなく中身で判定します。物差しにするのは、WordPress.org と php.net が出している公式のサポート期限、ドメインの登録の記録、保守会社の作業の記録です。どれも自社で確かめられます。

月額の中身を分ける：固定費と作業費

保守の月額は、サーバー・ドメイン・SSL 証明書などの固定費と、人が手を動かす作業費に分けると判断しやすくなります。固定費は自社の請求書や契約で金額が分かるので、残りが作業にいくら払っているかになります。

まず、自社の保守契約に何が入っているかを書き出します。次の表を印刷するか表計算ソフトに写して、契約書・見積書・請求書を見ながら埋めてください。

項目	月額に入っているか	上限（回数・時間）	応答の約束（何営業日以内など）	名義は誰か
サーバー代
ドメイン代
SSL 証明書
WordPress 本体の更新				―
プラグイン・テーマの更新				―
PHP のバージョンの切り替え				―
バックアップ（頻度・保存先・何世代）				―
復元の練習				―
死活の監視・改ざんの監視				―
文言・画像の差し替え				―
障害の対応（夜間・休日を含むか）				―
月次の作業報告				―

埋めてみて空欄が多いなら、それ自体が問題です。何をしてもらうために払っているのかが、契約の上で決まっていないことになります。

新しいページの追加、デザインの変更、機能の追加は、保守の月額に入るか別料金（スポット）になるかが契約によって分かれる項目です。月額に入っていると思い込んで依頼し、あとから見積もりが来て揉めないよう、境目を書面で確かめておきます。

作業1時間あたりいくら払っているかの試算（例）

固定費を引いた残りを、作業の時間で割ると、作業1時間あたりの金額が出ます。次は仮の数字での例です。相場を示すものではないので、自社の請求書と作業報告の数字に置き換えて使ってください。

前提（すべて仮の数字）は、保守の月額1万5,000円、サーバー代が年1万8,000円、ドメイン代が年4,000円で、どちらも保守の月額に含まれているとします。作業は、更新が月1回30分、文言の差し替えが年4回で各1時間、バックアップの確認が月1回15分とします。

// code/cost-per-hour.mjs（抜粋）
const monthlyFee = 15000; // 保守の月額（税込）
const serverPerYear = 18000; // サーバー代（年額）
const domainPerYear = 4000; // ドメイン代（年額）
const workHoursPerYear = [
  { item: "WordPress・プラグインの更新（月1回×0.5時間）", hours: 12 * 0.5 },
  { item: "文言・画像の差し替え（年4回×1時間）", hours: 4 * 1 },
  { item: "バックアップの確認（月1回×0.25時間）", hours: 12 * 0.25 },
];
const workFee = monthlyFee * 12 - (serverPerYear + domainPerYear);
const hours = workHoursPerYear.reduce((sum, w) => sum + w.hours, 0);
console.log(`作業1時間あたり: ${Math.round(workFee / hours).toLocaleString()}円`);

Node.js で実行した結果は次のとおりです。

年額: 180,000円
うち固定費（サーバー・ドメイン）: 22,000円
作業に払っている分: 158,000円
  WordPress・プラグインの更新（月1回×0.5時間）: 6時間
  文言・画像の差し替え（年4回×1時間）: 4時間
  バックアップの確認（月1回×0.25時間）: 3時間
報告された作業時間の合計: 13時間
作業1時間あたり: 12,154円

この数字が高いか安いかは、それだけでは決められません。保守には「何かあったときにすぐ動ける体制」を押さえておく意味もあるからです。ただ、作業の報告がほとんどないのに月額が高い、あるいは報告にある作業が更新ボタンを押すだけ、という場合は、次の節以降の確認に進む理由になります。

「足りなすぎ」を見分ける物差しは、公式のサポート期限

保守が足りているかは、WordPress と PHP のバージョンが公式のサポート期限の内側にあるかで判定できます。「アップデート対応込み」と書かれた保守でも、PHP が古いまま放置されていれば、作業は足りていません。

WordPress は「最新の系列の最新版」だけが安全とされている

WordPress.org のリリース一覧によると、2026年10月15日の時点で最新は 7.1.3（2026年10月6日公開）です。7.1 は2026年8月19日、7.0 は2026年5月20日に出ています。同じ日に 7.0 系にも 7.0.7 が出ていますが、一覧のページには「7.1 系の最新版だけが安全に使え、積極的に保守されている」という趣旨の一文があります。

古い系列にも修正が出ることはあります。それでも、公式が安全と言っているのは最新の系列の最新版です。保守会社に「いまのバージョンは何で、次はいつ上げるか」を聞く理由はここにあります。

PHP は 8.2 が2026年12月31日で終わる

WordPress は PHP というプログラムの上で動いています。この PHP にも、開発元の php.net が決めたサポート期限があります。php.net の方針は、最初のリリースから2年は通常のサポート、そのあと2年はセキュリティの修正だけ、合わせて4年で終わりです。

PHP の系列	最初のリリース	セキュリティ修正の終わり	2026年10月15日の状態
8.1 以前	―	終了済み	修正が出ない
8.2	2022年12月8日	2026年12月31日	あと2か月半で終わる
8.3	2023年11月23日	2027年12月31日	セキュリティ修正のみ
8.4	2024年11月21日	2028年12月31日	通常のサポート中（2026年12月31日まで）
8.5	2025年11月20日	2029年12月31日	通常のサポート中

「WordPress は動いている」と「安全」は別の話

WordPress の開発チームのハンドブック（2026年8月19日更新）によると、WordPress 7.0 と 7.1 が対応する PHP は 7.4 から 8.5 までです。PHP 7.2 と 7.3 への対応は 7.0 で打ち切られ、その方針は2026年1月9日に告知されています。

ここで気をつけたいのは、WordPress 7.1 が PHP 7.4 でも動くという点です。PHP 7.4 から 8.1 は、php.net のセキュリティ修正がすでに止まっています。WordPress を最新にしていても、下の PHP が古ければ、そこに見つかった弱点は直りません。

判定の基準をまとめると、次のとおりです。

状態	判定
WordPress が 7.1 系の最新版、PHP が 8.3 以上、有効なプラグインに更新待ちがない（サイトヘルスのステータスに出ない）	足りている
WordPress と PHP は上の条件を満たすが、有効なプラグインに更新待ちがある	足りていない（更新待ちのプラグインに弱点の修正が含まれていることがある）
WordPress は最新、PHP が 8.2	2026年12月31日までに切り替えの予定が要る
WordPress は最新、PHP が 8.1 以下	足りていない（PHP 側の修正が止まっている）
WordPress が 7.0 以前の系列	足りていない（公式に安全とされる版ではない）
バージョンを保守会社が答えられない	確かめる必要がある

自分で確かめる：管理画面と、外から見える情報

払っている保守が効いているかは、WordPress の管理画面と、外から見える情報で確かめられます。保守会社に聞く前に一度自分で見ておくと、答えが正しいかを判断できます。

管理画面で見る

WordPress の管理画面で「ツール」→「サイトヘルス」→「情報」を開きます。WordPress.org の説明書によると、「WordPress」の欄にいまの WordPress のバージョン、「サーバー」の欄に PHP などサーバーの設定、有効なプラグインの欄にプラグインごとのバージョンと自動更新の有無が出ます。同じ画面の「ステータス」には、古い PHP や更新待ちのプラグインが「致命的な問題」として出ることがあります。

管理画面に入れない、つまり自社に管理者のアカウントがない場合は、それも確認の結果です。乗り換えや連絡がつかなくなったときに困る典型なので、後の節の手順で手当てします。

外から見る（確認用のスクリプト）

SSL 証明書の期限、ネームサーバー（DNS をどこで管理しているか）、ドメインの登録者と期限は、サイトの外からでも分かります。次のスクリプトは Node.js（バージョン18以上）で動きます。自社のサイトか、確認の許可をもらったサイトにだけ使ってください。

// code/site-check.mjs
// 使い方: node site-check.mjs example.jp [PHPのバージョン 例: 8.1]
import tls from "node:tls";
import dns from "node:dns/promises";
import net from "node:net";

const host = process.argv[2];
// 8.2.29 のような3桁の版も、8.2 のように2桁にそろえて引く
const phpVersion = process.argv[3]?.split(".").slice(0, 2).join(".");

// PHP のサポート期限（php.net/supported-versions.php、2026-10-15 時点）
const phpSecurityEnd = {
  "8.2": "2026-12-31",
  "8.3": "2027-12-31",
  "8.4": "2028-12-31",
  "8.5": "2029-12-31",
};
const daysUntil = (date) => Math.floor((date - Date.now()) / 86400000);

// 1. SSL 証明書の期限
function checkCert() {
  return new Promise((resolve, reject) => {
    const socket = tls.connect(443, host, { servername: host }, () => {
      const cert = socket.getPeerCertificate();
      socket.end();
      resolve(cert);
    });
    socket.setTimeout(10000, () => reject(new Error("timeout")));
    socket.on("error", reject);
  });
}

// 2. JP ドメインの WHOIS（whois.jprs.jp の 43 番ポート）
function whoisJp() {
  return new Promise((resolve, reject) => {
    let data = "";
    const socket = net.connect(43, "whois.jprs.jp", () => socket.write(`${host}/e\r\n`));
    socket.setTimeout(10000, () => reject(new Error("timeout")));
    socket.on("data", (chunk) => (data += chunk));
    socket.on("end", () => resolve(data));
    socket.on("error", reject);
  });
}

const cert = await checkCert();
const certEnd = new Date(cert.valid_to);
console.log(`SSL 証明書の期限: ${certEnd.toISOString().slice(0, 10)}（あと ${daysUntil(certEnd)} 日）`);
console.log(`SSL 証明書の発行元: ${cert.issuer.O ?? cert.issuer.CN}`);

const ns = await dns.resolveNs(host).catch(() => []);
console.log(`ネームサーバー: ${ns.length ? ns.join(", ") : "取得できず（サブドメインなど）"}`);

const res = await fetch(`https://${host}/`, { method: "HEAD", redirect: "manual" });
console.log(`server ヘッダー: ${res.headers.get("server") ?? "なし"}`);
console.log(`x-powered-by ヘッダー: ${res.headers.get("x-powered-by") ?? "なし（外からは PHP のバージョンが見えない）"}`);

if (host.endsWith(".jp")) {
  const text = await whoisJp();
  const pick = (label) => text.split("\n").find((line) => line.includes(label))?.trim() ?? `${label}: 見つからず`;
  console.log(pick("[Registrant]"));
  console.log(pick("[Expires on]") === "[Expires on]: 見つからず" ? pick("[State]") : pick("[Expires on]"));
}

if (phpVersion) {
  const end = phpSecurityEnd[phpVersion];
  if (!end) {
    console.log(`PHP ${phpVersion}: サポート終了済み（php.net の一覧にない）→ 更新が必要`);
  } else {
    console.log(`PHP ${phpVersion}: セキュリティ修正は ${end} まで（あと ${daysUntil(new Date(end))} 日）`);
  }
}

2026年10月15日に、このブログのドメイン（hand-off.jp）に対して、PHP のバージョンに 8.1 と 8.2 をそれぞれ渡して実行した結果です。PHP のバージョンは判定の例を見せるために引数で渡した仮の値で、スクリプトが検出したものではありません。登録者名の行は、この記事では伏せています。

$ node site-check.mjs hand-off.jp 8.1
SSL 証明書の期限: 2027-01-12（あと 89 日）
SSL 証明書の発行元: Google Trust Services
ネームサーバー: jack.ns.cloudflare.com, melina.ns.cloudflare.com
server ヘッダー: cloudflare
x-powered-by ヘッダー: なし（外からは PHP のバージョンが見えない）
[Registrant]                    （伏せています）
[Expires on]                    2027/10/31
PHP 8.1: サポート終了済み（php.net の一覧にない）→ 更新が必要

$ node site-check.mjs hand-off.jp 8.2
（上と同じ行は省略）
PHP 8.2: セキュリティ修正は 2026-12-31 まで（あと 77 日）

読み方の要点は3つです。1つ目は [Registrant] の行で、ここに自社の名前ではなく制作会社や保守会社の名前が出たら、ドメインは自社のものになっていません。2つ目はネームサーバーで、どの会社のサービスで DNS を管理しているかが分かり、乗り換えのときに誰に設定を変えてもらうかの手がかりになります。3つ目は x-powered-by で、ここが「なし」なのは異常ではなく、あえて隠していることがあるので、PHP のバージョンは管理画面で確かめてください。

.com などの .jp 以外のドメインは、このスクリプトの WHOIS の部分は動きません。登録している会社（レジストラ）の画面か、その会社の WHOIS の検索で登録者と期限を確かめます。

「払いすぎ」を見分ける：作業の記録と突き合わせる

払いすぎかどうかは、契約にある作業が実際に行われた記録があるかで判断します。記録がない作業は、行われていないものとして扱うのが安全です。

保守会社に、直近3か月分の作業の記録を出してもらい、次の点を確かめます。

確かめること	記録にあるべき中身	記録がないときの読み方
更新	何を、どの版から、どの版に上げたか（WordPress 本体・プラグイン・テーマ・PHP）	「更新しました」だけでは、何が最新になったか分からない
バックアップ	取得した日、保存先、何世代残しているか	保存先がサイトと同じサーバーだけなら、サーバーの障害で一緒に消える
復元の練習	最後に復元を試した日と結果	一度も試していないバックアップは、戻せるかが分からない
監視	止まった・改ざんされたときに誰に何分で知らせが行くか	監視の設定先が保守会社だけだと、自社は気づけない
問い合わせ・修正	依頼の日、対応の日、かかった時間	依頼が年に数回なら、作業込みの高いプランは見合わない可能性

依頼する作業が年に数回しかないのに、毎月の作業が多く含まれる高いプランに入っている場合は、「更新・バックアップ・監視だけの保守」と「作業はスポットで頼む」の組み合わせに切り替える余地があります。逆に、記録を見たら毎月それなりの作業があり、PHP の切り替えまで計画されているなら、月額が相場の目安より高くても、払いすぎとは言えません。

プランを見直す前に、契約の解約の条件を確かめておきます。最低の契約期間、解約の予告期間（何か月前に申し出るか）、途中で解約したときの費用、解約したときに何を渡してくれるか、の4つです。とくに最後の「何を渡してくれるか」が書かれていない契約は、乗り換えのときに揉めやすいので、次の更新のときに書き足してもらうよう頼みます。

WordPress を放置すると何が起きるか

更新されないまま放置された WordPress は、知られた弱点を突く攻撃の的になります。そしてその影響は、自社の中だけでは終わらないことがあります。

IPA（情報処理推進機構）が2026年1月29日に公開した「情報セキュリティ10大脅威 2026」の組織編では、4位に「システムの脆弱性を悪用した攻撃」が入っています。更新されていない WordPress やプラグイン、サポートの切れた PHP は、まさにこの「脆弱性」にあたります。同じ一覧の2位は「サプライチェーンや委託先を狙った攻撃」で、取引先から見れば、自社も「委託先」や「取引の相手」の1つです。

IPA の「2024年度 中小企業における情報セキュリティ対策に関する実態調査」（2024年10月〜2025年1月、中小企業の経営層・情報システム担当者へのWebアンケート 4,191件、2025年5月27日公開）では、取引先から情報セキュリティ対策の要請を受けている企業は1割強でした。要請を受けた企業のうち、セキュリティの体制を整えている企業の59.8%が「対策が取引につながった」と答え、整えていない企業では24.2%でした。ISMS を取っている企業では73.9%、取っていない企業では30.3%です。

ホームページはこの話の一部にすぎません。それでも、取引先や採用の応募者が最初に見る場所であり、改ざんされれば見た人に被害が及びます。保守を見直すときは、月額の大小だけでなく、「取引先に説明できる状態か」という目でも見てください。

制作会社・保守会社と連絡がつかないときの手順

連絡がつかなくなったら、まずドメインとサーバーが誰の名義かを確かめ、期限が近いものから手を打ちます。サイトの中身より先に、ドメインとサーバーの期限切れを防ぐのが優先です。

手順

1. ドメインの登録者と期限を確かめる。.jp なら前の節のスクリプトか、JPRS の WHOIS の検索で見られる。
2. サーバーの契約の名義と、支払いをしている人を確かめる。自社の請求書やカードの明細に、サーバー会社の名前で引き落としがあるかを見る。
3. WordPress の管理者のアカウントが自社にあるかを確かめる。ないなら、サーバーの契約が自社名義であれば、サーバー会社に WordPress の管理者を作り直す方法を問い合わせる。
4. 連絡を試みた記録を残す。電話・メールの日時、送った内容を残し、返事がないときは書面（内容証明郵便など）で、移管やアカウントの引き渡しを求める。
5. 期限が近いものから手当てする。ドメインやサーバーが数週間で切れるなら、名義の問題より先に、更新の手段を探す。

名義と、取れる手の関係は次のとおりです。

ドメインの登録者	サーバーの名義	取れる手
自社	自社	自社で移管・乗り換えを進められる。新しい保守先を決めて引き継ぐ
自社	制作会社	ドメインは自社で動かせる。サイトの中身（ファイルとデータベース）の引き渡しを求める
制作会社	自社	ドメインの登録者の変更を求める必要がある。期限が近いなら更新の手当てを先に
制作会社	制作会社	自社だけでは動かせない。引き渡しを書面で求める。契約書の該当の条項を確かめ、必要なら弁護士に相談する

JP ドメインの移し方（指定事業者の変更）

JPRS の説明によると、.jp のドメインを別の会社（指定事業者）に移すときは、登録者が今の事業者に認証コード（AuthCode）を確認し、今の事業者が JPRS に発行を依頼する流れです。そのあと移し先の事業者に申し込み、JPRS が今の事業者に確認し、登録者の意思が確かめられて承認されると完了します。

注意点は3つあります。AuthCode の有効期限は、JPRS が生成した日の翌日を1日目として35日後の23時59分59秒までで、切れたら手続きをやり直します。移す前に、ドメインにかかっている指定事業者変更ロックやレジストリロックを外しておく必要があります。開始から終了まで数日かかることがあるので、期限の直前に始めないことです。

いずれも、手続きを進められるのは登録者です。登録者が制作会社の名前になっていると、自社からは AuthCode を求められません。だから手順の1番目に、登録者の確認を置いています。

.com などのドメインの移し方

.com などのドメインの移管は、ICANN の Transfer Policy（2024年2月21日版）の決まりに沿います。登録から60日以内、前回の移管から60日以内は、移管を断られることがあります。登録者を変えたあとは60日の移管のロックがかかり、事前に外す選択（オプトアウト）を認めている会社もあります。名義の変更と移管を続けて行う場合は、この60日の順番を先に確かめてください。

新しい保守先を探す

自社名義のものがそろっていれば、新しい保守先に引き継げます。乗り換え先の探し方の1つとして、Handoff の企業向けの入口では、ホームページを持つ企業が保守の乗り換えの相談を無料で出せます。いまの保守会社が保守を手放す場合は、その会社が制作者向けの入口から、お客の名前や URL を伏せたまま引き継ぎを出せます。

乗り換え・引き継ぎで渡してもらうものリスト

乗り換えで後から困るのは、「アカウントは渡されたが、何がどこにあるかの説明がない」という状態です。次のリストを今の保守会社に渡し、項目ごとに「渡せる・渡せない・名義の変更が要る」を書いてもらいます。

区分	渡してもらうもの	確かめる点
ドメイン	登録している会社、登録者名、期限、AuthCode（移す場合）	登録者が自社か
DNS	ネームサーバー、すべてのレコードの一覧（A・CNAME・MX・TXT）	メール（MX）や認証の TXT が抜けていないか
サーバー	契約の名義、管理画面のログイン、プランと期限	支払いを誰がしているか
ファイル	FTP や SSH の接続先とログイン	自社用のアカウントを作ってもらえるか
データベース	接続先、名前、ログイン	バックアップと一緒に渡してもらえるか
WordPress	自社用の管理者のアカウント	制作会社のアカウントは引き継ぎのあとに外す
バックアップ	直近のフルバックアップ（ファイルとデータベース）	新しい環境で復元できるか
有料のテーマ・プラグイン	製品名、ライセンスの名義と期限	制作会社の名義のライセンスは移せないことがある
改変した箇所	子テーマや独自のコードの場所と説明	本体を更新すると消える改変がないか
フォーム・メール	問い合わせの送信先、送信に使っているメールの設定（SPF・DKIM）	送信先に退職者や制作会社のアドレスがないか
計測・検索	Google アナリティクス・Search Console の権限	自社のアカウントがオーナーになっているか
外部サービス	地図・予約・決済などの契約名義	解約で止まるサービスがないか
契約書	制作と保守の契約書、仕様書	著作権の帰属と、改変してよいかの定め

契約書で見ておきたい著作権の定め

乗り換えたあとに新しい保守先がサイトを手直しする場合、もとの制作物の著作権が誰にあるかが関わってきます。著作権法第61条2項は、著作権を譲る契約で、第27条（翻訳権、翻案権等）と第28条（二次的著作物の利用に関する原著作者の権利）に定める権利が譲る対象として特に書かれていないときは、これらの権利は譲った側に残ったものと推定する、と定めています。

つまり「著作権は発注者に譲渡する」とだけ書かれている契約だと、手直しにかかわる権利が制作側に残っていると推定される余地があります。契約書の該当の条項を確かめ、判断に迷う場合は、契約書を持って弁護士などの専門家に相談してください。この記事は個別の契約について判断するものではありません。

見積もり・契約の更新のときに聞く質問

保守の見直しや乗り換えの見積もりでは、金額の前に次の質問をします。答えがはっきりしているかどうかが、保守の中身の確かさを表します。そのままメールに貼って使えるひな形です。

件名: ホームページの保守の内容についての確認

いつもお世話になっております。保守の契約の見直しにあたり、以下を教えてください。

1. 現在の WordPress と PHP のバージョン、次に上げる予定の時期
   （PHP 8.2 のセキュリティ修正は 2026年12月31日で終わると php.net に出ています）
2. 月額に含まれる作業と、別料金になる作業の境目
3. 直近3か月の作業の記録（何をどの版に上げたか）
4. バックアップの頻度・保存先・世代数と、最後に復元を試した日
5. 障害のときの連絡先と、何時間以内に対応を始めるか
6. ドメイン・サーバー・有料ライセンスの名義
7. 解約するときに渡していただけるもの（アカウント・バックアップ・説明書き）
8. 解約の予告期間と、途中で解約するときの費用

お手数ですが、◯月◯日までにご回答いただけますと助かります。

答えの読み方の目安を添えておきます。1に版の番号で答えられない、3の記録が出てこない、6で名義が保守会社のものばかり、という場合は、月額がいくらであっても見直しを考えてよい状態です。反対に、1〜8にすぐ具体的に答えられる保守会社なら、目安より高い月額にも理由があると考えられます。

明日からやること

• 管理画面の「ツール」→「サイトヘルス」→「情報」で、WordPress と PHP のバージョンを確かめる
  • PHP が 8.1 以下なら、セキュリティ修正はすでに止まっているので、すぐに切り替えを頼む
  • PHP が 8.2 なら、2026年12月31日より前に切り替える予定を聞く
• ドメインの登録者と期限を WHOIS で確かめ、自社の名前になっているかを見る
• 保守の中身の表を埋め、空欄を保守会社に聞く
• 上の質問のひな形を、いまの保守会社に送る
• 乗り換えを考えるなら、渡してもらうものリストを先に渡しておく