中小企業のWordPress保守・セキュリティ運用ガイド 更新・バックアップ・改ざん対応・月次チェックリスト【2026年10月版】

ホームページは、広告やSNS、検索から来た人が最後にたどり着く、お店の顔です。

サイトが改ざんされて怪しいページに飛ばされたり、検索結果に警告が出たりすれば、集客の努力は一気に台無しになります。

一方で、WordPressで作ったサイトは、作って終わりになりがちです。

制作会社に納品してもらったあと、次のような状態になっていないでしょうか。

• 誰も更新のボタンを押していない
• 管理者のパスワードが納品時のまま
• 退職した人のアカウントが残っている

中小企業では、珍しくない状況です。

この記事では、専任のウェブ担当者がいない会社でも回せるように、WordPressサイトの保守とセキュリティの運用を、何を、どの頻度で、誰がやるかに分けて整理します。

WordPress.orgとGoogleの公式情報、IPA（情報処理推進機構）とJPCERT/CCの公開情報は、2026年10月17日に開いて内容を確かめました。

最新のWordPressのバージョン番号は、記事の中では断定していません。管理画面や、WordPress.orgの公開情報で確認してください。

先に結論 保守で先に決める5つのこと

最初に、この記事の要点を表にまとめます。

工程	先に決めること	決めないと起きること
更新	本体のセキュリティ更新は止めない。プラグインの更新方法を決める	古い部品の弱点を突かれる
バックアップ	データベースとファイルの両方を、複数の場所に残す	戻したくても戻せない
アカウント	管理者は少人数にし、二要素認証を使う	パスワードの漏れで乗っ取られる
部品	使っていないプラグインとテーマは削除する	無効にしただけの部品が入口になる
外注	範囲、頻度、緊急時の対応を契約で決める	契約していても誰も見ていない

どの工程も、特別な技術は要りません。毎月決まった手順を続けることが中心です。

なぜWordPressの保守が集客の土台なのか

古いソフトウェアは狙われる

WordPressは、本体（コア）に加えて、テーマ（見た目のひな形）とプラグイン（機能を追加する部品）を組み合わせて動いています。

どの部品にも、あとから脆弱性（攻撃に悪用できる弱点）が見つかることがあります。

IPAの「企業ウェブサイトのための脆弱性対応ガイド」は、構築に使ったソフトウェアを最新版にして、修正プログラム（パッチ）をあてることを求めています。

WordPress.orgの「Hardening WordPress」でも、使っていないプラグインは削除し、本体や部品を最新にしておくよう案内されています。

2026年も本体の重大な脆弱性が出ている

2026年7月に、IPAが「WordPressの脆弱性対策について」という注意喚起を出しています。

項目	内容
通称	wp2shell（2件の脆弱性の組み合わせ）
識別番号	CVE-2026-60137 と CVE-2026-63030
影響を受ける版	6.9.0〜6.9.4、7.0.0〜7.0.1（前者は6.8.0〜6.8.5も対象）
修正された版	6.9.5、7.0.2（前者は6.8.6でも修正）
攻撃の条件	標準の構成なら、管理者権限などがなくても、遠隔からコードを実行される可能性が指摘された

WordPress.orgは2026年7月17日に7.0.2を公開し、対象の版を使うサイトに、自動更新の仕組みで強制更新を有効にしたと発表しています。

ただしIPAは、自動更新が無効になっていたり、失敗していたりする場合があるため、管理画面でバージョンを確認し、古いままなら手動で更新するよう呼びかけています。

つまり、自動更新を有効にすることと、更新されたかを確認することの、両方が必要です。

検索結果や広告にも影響する

サイトがハッキングされると、Googleの検索結果やブラウザに警告が表示されることがあります。

その内容は、Search Consoleの「セキュリティの問題」のレポートで確認できます。

警告が出ていれば、検索や広告で集めた人の多くは引き返してしまいます。保守は、集客施策の前提条件です。

保守の全体の流れ

毎月の確認の流れを図にしました。

更新、バックアップ、アカウント、部品、動作の順に見ると、抜けが出にくくなります。

担当を決める

担当	主な仕事	頻度
社内の責任者	月次の報告を受け取り、確認する	毎月
保守の担当（社内または外注先）	更新、バックアップ、点検の実施	毎月
経営者	契約の内容と、緊急時の連絡先の確認	定期の見直し

更新 本体・テーマ・プラグインを最新に保つ

WordPressの自動更新の基本

WordPress.orgの「Upgrading WordPress」によると、自動のバックグラウンド更新には、本体、プラグイン、テーマ、翻訳ファイルの4種類があります。既定の動きは次のとおりです。

種類	既定の動き（公式ドキュメントの記載）
本体のマイナー更新（セキュリティ修正など）	既定で有効
本体のメジャー更新	5.6以降に新規で入れたサイトは既定で有効。それ以前からあるサイトは、管理者が有効にしない限りマイナー更新のみ
翻訳ファイル	既定で有効
プラグイン・テーマ	管理者が項目ごとに有効にする

本体の自動更新は、設定ファイル（wp-config.php）の WP_AUTO_UPDATE_CORE で変えられます。

また、AUTOMATIC_UPDATER_DISABLED で、全ての自動更新を止めることもできます。ただし、マイナー更新などを止めることは、公式ドキュメントで強く非推奨とされています。

制作会社がこの設定を入れている場合もあるため、外注先に一度確認しておくと安心です。

プラグインとテーマの自動更新を有効にする

プラグインとテーマの自動更新は、WordPress 5.5で導入されました。

プラグインは「プラグイン」画面から、項目ごとに切り替えられます。テーマは「外観」画面でテーマの詳細を開き、1つずつ切り替えます。

公式ディレクトリ以外から入手した有料のプラグインなどは、販売元ごとに更新の仕組みが違います。

自動更新が使えるか、ライセンスキーの登録などが必要かを、販売元の案内で確認してください。

全部自動か、確認してから更新か

自動更新で、まれにデザインが崩れたり、フォームが動かなくなったりすることがあります。次のように分けると現実的です。

対象	更新の方針
本体のマイナー更新（セキュリティ修正）	必ず自動のまま。止めない
公式ディレクトリのプラグインとテーマ	基本は自動更新。月次の点検で表示崩れを確認する
問い合わせフォーム、ネットショップ、予約機能など、売上に直結するもの	外注先と相談し、自動か、検証後の手動かを決める。手動なら「何日以内に適用するか」も決める
本体のメジャー更新	自動か手動かを決める。手動なら担当者を決め、月次で適用する

更新前にやること

公式の「Upgrading WordPress」では、更新を始める前に、サイトのバックアップを取るよう勧めています。

更新のあとで表示がおかしくなった場合は、最初から入っているもの以外のプラグインをいったん全て停止し、1つずつ有効にして原因を探す方法が紹介されています。

PHPのバージョン サーバー側の土台も古くしない

WordPressはPHPというプログラム言語で動いています。本体を最新にしても、サーバーのPHPが古いままでは、安全とはいえません。

WordPress.orgの動作環境のページでは、2026年10月時点で次の環境が推奨されています。

項目	推奨
PHP	8.3以上
データベース	MySQL 8.0以上、またはMariaDB 10.11以上
通信	HTTPSに対応していること

同じページでは、PHP 7.4以上などの古い環境でもWordPressは動くものの、それらはサポート終了（EOL）しており、サイトが脆弱性にさらされるおそれがあると注意されています。

また、WordPress 7.0では、PHP 7.2と7.3のサポートが終了し、サポートする最低のバージョンがPHP 7.4になりました。

PHPが古いままだと、新しい版へ更新できない場合があります。サーバー側の対応が先に必要です。

更新のあとに確認すること

更新は、実行して終わりにしません。更新のあとに、画面を開いて確かめます。

確認する画面	見ること
トップページ	表示が崩れていないか、画像が出ているか
問い合わせフォーム	実際に送信して、メールが届くか
主要なサービスのページ	料金表や図が正しく表示されているか
スマートフォンの表示	メニューが開くか、文字が重なっていないか

問題があれば、直前に更新したものを特定し、外注先に連絡します。

更新を行う曜日と担当者を決めておくと、確認の漏れを防げます。

PHPを上げる手順

PHPのバージョンは、多くのレンタルサーバーで、管理画面から変更できます。古いテーマやプラグインが新しいPHPに対応していないと表示が崩れるため、次の順番で進めます。

1. 現在のPHPのバージョンを、サーバーの管理画面で確認する
2. バックアップを取る
3. テーマとプラグインを最新にする
4. 可能なら、本番とは別の確認用のサイトでPHPを上げて、動作を確かめる
5. 本番のPHPを上げ、トップページ、問い合わせフォーム、主要なページを確認する

バックアップと復元テスト

何をバックアップするか

WordPress.orgのバックアップの案内では、サイトを完全に元に戻すには、データベースとファイルの両方が必要だと説明されています。

種類	含まれるもの
データベース	投稿、固定ページ、コメントなど、管理画面で入力した内容
ファイル	本体、テーマ、プラグイン、アップロードした画像、設定ファイル

サーバーのファイルをダウンロードしただけでは、データベースは含まれません。

頻度と世代

公式の案内では、投稿の少ない小規模なサイトは週に1回、更新の多いサイトは毎日が目安とされています。

また、直近のバックアップを3〜5世代は残し、サーバー、クラウドストレージ、手元のパソコンなど、別々の場所に保管するよう勧めています。

実務の目安を表にしました。

項目	例
頻度	ブログやお知らせを週に数回更新するなら毎日。月に数回なら週に1回
世代	最低でも直近3〜5回分
保存先	サーバーの中に加えて、サーバー会社とは別のクラウドストレージ
更新前	本体のメジャー更新、PHPの変更、デザインの改修の前に、手動で1回

復元テストをしないバックアップはお守りにすぎない

公式の案内では、プラグインで自動化している場合でも、ときどき手動でバックアップを取って、仕組みが動いているか確かめるよう勧めています。

おすすめは、半年に1回ほど、確認用の環境にバックアップを戻してみることです。確認するのは、次の3点です。

• 戻したサイトで、トップページ、主要なページ、画像が表示されるか
• 管理画面にログインできるか
• バックアップの取得日時が、想定どおりか（いつの間にか止まっていないか）

外注している場合は、復元テストの実施と報告を契約に入れておくとよいでしょう。

管理者アカウントの守り方

強いパスワード

WordPress.orgの総当たり攻撃の対策のページでは、使い回さない長いパスワード、またはパスフレーズ（複数の単語をつなげた長い合言葉）と、パスワード管理ツールの利用を勧めています。

辞書に載っている単語や、個人の情報は避けます。

二要素認証とパスキー

二要素認証とは、パスワードに加えて、スマートフォンのアプリなどで確認する仕組みです。

同じページでは、管理者など強い権限を持つユーザーに有効にするよう勧めています。ただし、WordPress本体には二要素認証の機能が入っていないため、プラグインや外部の認証サービスで追加します。

フィッシング（偽のサイトでパスワードをだまし取る手口）に強いパスキーも挙げられています。指紋や顔、端末を使うログインの方式で、管理者1人につき2つ以上の認証手段を登録するよう案内されています。

ユーザー名と管理者の人数

同じページでは、「admin」というユーザー名を使わないこと、管理者の数を少なく保つこと、普段の作業には権限の低いユーザーを使うことが勧められています。

WordPressの権限グループの主なものは、次のとおりです。

権限グループ	できることの目安	向いている人
管理者	プラグイン、テーマ、ユーザー、設定まで全て	社内の責任者と保守の担当
編集者	他の人の投稿も含めた記事と固定ページの編集	お知らせやページの内容を管理する担当者
投稿者	自分の記事の作成と公開	ブログを書く社員
寄稿者	自分の記事の作成（公開はできない）	公開前に上長の確認を通したい書き手

記事を書くだけの人に管理者の権限を渡すと、パスワードが漏れたときの被害が大きくなります。役割に合った、最小限の権限にしましょう。

使わないユーザーを削除する

退職者や、制作のときに使った外部スタッフのアカウントが残っていないか、定期的に確認します。

ユーザーを削除するときは、その人が作った投稿やページを、全て削除するか、別のユーザーに引き継ぐかを選べます。記事を残したい場合は、必ず引き継ぐ側を選び、作業の前にバックアップを取ります。

ユーザーの棚卸しの進め方

手順	内容
1	ユーザーの一覧を開き、名前、権限、最後に使った時期を書き出す
2	社員名簿や外注先の一覧と突き合わせ、心当たりのない人を洗い出す
3	不要な人は、記事の引き継ぎ先を決めてから削除する
4	残る人の権限が、仕事の内容に合っているか見直す

棚卸しの結果は、日付とともに記録に残します。次回の月次の点検で、前回との差を見られます。

使っていないプラグインとテーマは無効化でなく削除

「Hardening WordPress」では、使っていないプラグインは削除し、プラグインやテーマは、WordPress.orgの公式ディレクトリか、よく知られた提供元からだけ入手するよう勧めています。

無効化と削除は違います。JPCERT/CCは2020年に、プラグイン「File Manager」の脆弱性について、無効にするだけでは対策が不十分で、更新かアンインストール（削除）を確実に行うよう注意喚起しました。

無効にしてもファイルはサーバーに残るため、攻撃の入口になりえます。

点検の手順

1. プラグインの一覧で、停止中のものを洗い出す
2. 「いつか使うかも」で残しているものは、バックアップを取ったうえで削除する
3. 有効なプラグインも、本当に使っているかを確認する（似た機能のものが複数入っていないか）
4. 長く更新されていないプラグインは、代わりのものへの切り替えを検討する
5. テーマも、使っているもの（子テーマなら親テーマも）以外は削除する

改ざん・ハッキングされたときの対応手順

気付くための仕組み

まず、Google Search Consoleにサイトを登録しておくことが重要です。

Search Consoleのヘルプによると、Googleがサイトのハッキングを疑った場合、確認済みの所有者に、Search Consoleからメールで通知が届きます。登録していなければ、警告に気付くのが遅れます。

通知が届く設定になっているか、メールが迷惑メールに振り分けられていないかも、確認しておきましょう。

「Hardening WordPress」では、ログを保管して確認することも勧めています。IPAの「安全なウェブサイトの運用管理に向けての20ヶ条」でも、ログを保管し、定期的に確認することが項目に挙がっています。

発覚したときの初動

最初に、何に気付いたか、いつか、最近何を変えたか（新しいプラグインの追加、テーマの編集など）を書き留めます。

外注先や専門業者に相談するときに、話が早く進みます。そのうえで、WordPress.orgの「FAQ My site was hacked」では、おおむね次の対応が示されています。

順番	対応	内容
1	調べる	セキュリティのプラグインや外部のチェックサービスでサイトを確認する。作業に使うパソコンが感染源のこともあるため、パソコンもウイルス検査する
2	窓口に確認する	同じサーバーを使う他のサイトにも影響していないか、サーバー会社に確認する
3	アクセス情報を全て変える	全ユーザーのパスワードをリセットする。FTPやSFTP、サーバーの管理画面、データベースの情報も見直す
4	感染した状態も保存する	掃除を始める前に、その時点の状態をバックアップする
5	本体を入れ直す	使っているのと同じバージョンの本体のファイルで置き換え、.htaccess などを確認する
6	掃除のあとに更新し、パスワードをもう一度変える	きれいになったことを確認してから、最新に更新し、パスワードを再度変更する

被害の前のきれいなバックアップから戻す方法もありますが、戻しただけでは、侵入の原因（古いプラグインや漏れたパスワード）が残ったままです。

原因を調べて塞がないと、繰り返し侵入されるおそれがあります。

Search Consoleで審査をリクエストする

Googleの検索結果に警告が出ている場合は、Search Consoleの「セキュリティの問題」のレポートを確認します。

ヘルプによると、レポートに挙がっている全ての問題を、全てのページで修正してから、「審査をリクエスト」を選びます。

リクエストには、問題の説明、修正のために行った手順、取り組みの結果を、明確に書きます。

審査には、数日から数週間かかります。問題が残ったままリクエストすると、次の結果が出るまでの時間が長くなる可能性があります。

決定の通知が届くまでは、同じリクエストを再送信しないでください。

脆弱性情報の集め方

IPAの20ヶ条では、利用しているソフトウェアの構成を把握し、脆弱性対策情報データベースの「JVN iPedia」などで情報を集めることが挙げられています。

WordPressのようなCMS（サイト作成ソフト）を使っているなら、次の情報源を確認する習慣をつけましょう。

• IPAの重要なセキュリティ情報
• JPCERT/CCの注意喚起
• WordPress.orgのニュース（セキュリティリリースの告知）

情報源	分かること
IPAの重要なセキュリティ情報	国内の利用者に向けた注意喚起と対策
JPCERT/CCの注意喚起	脆弱性の概要と、影響を受ける製品
WordPress.orgのニュース	セキュリティリリースの公開と、修正された版

重大な脆弱性が出たときは、自社サイトのバージョンが対象か、すでに更新されたかを、管理画面で確認します。

wp2shellのように強制更新が行われた場合でも、実際に更新されたかを、自分の目で確かめることが大切です。

保守を外注する場合に契約で決めること

保守を制作会社や保守サービスに任せるのは、合理的な選択です。ただし、契約しているから安心、とは限りません。

IPAの「企業ウェブサイトのための脆弱性対応ガイド」では、委託するときは契約の段階からセキュリティ対策を意識すること、社内の担当者と委託先の作業範囲と責任範囲を明確にすることが示されています。

運用を任せていても、サイトを運営する主体は自社です。契約や見積もりの段階で、次の項目を書面で確認しておきましょう。

項目	決めておくこと
対象範囲	本体、テーマ、プラグイン、PHP、サーバーの設定のどこまでを見るか
更新の頻度	通常の更新は月に何回か。緊急の脆弱性が出たら、何日以内に対応するか
更新の方法	自動更新にするもの、検証してから手動で更新するもの
バックアップ	頻度、世代数、保存場所、復元テストの頻度と報告
監視	改ざんの検知や、サイトが表示されているかの監視をするか
障害・改ざんのとき	連絡の手段と目安の時間。復旧作業が契約の範囲内か、別の扱いか
アカウント管理	外注先が使う管理者アカウントの扱い（担当者ごとに分ける、契約の終了時に削除）
報告	月次の報告の内容（更新した項目、バージョン、バックアップの状況、気付いた点）
契約の終了時	管理者権限、サーバーの情報、バックアップの引き渡し方法

見落としやすいのが、サーバーやドメインの契約者の名義です。外注先の名義のままだと、契約の終了時や、連絡が取れなくなったときに困ります。

自社の名義にするか、引き渡しの条件を決めておきましょう。

月次の保守チェックリスト

毎月1回確認するチェックリストです。外注している場合は、報告書と照らし合わせるのにも使えます。

毎月

区分	確認すること
更新	WordPress本体のバージョンを管理画面で確認した（最新か、セキュリティ更新が適用されているか）
更新	更新待ちのプラグインとテーマがない（手動更新にしているものも適用済み）
更新	自動更新の設定が、意図どおりになっている
部品	停止中のプラグインや、使っていないテーマがない（あれば削除した）
アカウント	ユーザーの一覧に、知らないユーザー、退職者、不要な外部スタッフがいない
アカウント	管理者の権限を持つ人が、必要最小限になっている
アカウント	管理者に、二要素認証かパスキーが設定されている
バックアップ	予定どおり取れている（日付を確認した）
検索	Search Consoleの「セキュリティの問題」に、問題が出ていない
動作	トップページ、問い合わせフォーム、主要なページが正常に動く（フォームは実際に送信して試した）
情報収集	IPAとJPCERT/CCで、使っているCMSやプラグインの注意喚起を確認した

3か月ごと

• サーバーのPHPのバージョンが、WordPress.orgの推奨（2026年10月時点で8.3以上）を満たしているか確認した
• 長く更新されていないプラグインがないか確認した
• サーバー会社、ドメイン管理会社、保守の外注先、バックアップの保存先の連絡先を一覧にし、最新にした

半年ごと

• 確認用の環境にバックアップを戻す、復元テストをした
• 管理者、サーバー、FTPなどのパスワードの管理状況を見直した
• 保守契約の内容と、実際の作業が合っているか確認した

売れるサイトはみな謙虚 保守は足さずに引く

ここまで、更新、バックアップ、アカウント、改ざん対応を説明してきました。最後に、サイト全体の作り方についての考え方を1つ紹介します。

「売れるサイトはみな謙虚」という考え方です。大きく見せる言葉や機能を足していくより、訪れた人が迷う要素を引いていくほうが、次の一歩を踏み出してもらえるという見方です。

保守にも引き算が効く

保守の負担を増やすのは、サイトに足し続けた部品です。

引くもの	引いたあとの状態
使っていないプラグインとテーマ	更新と点検の対象が減り、攻撃の入口も減る
似た機能のプラグインの重複	1つに絞られ、表示崩れの原因を探しやすい
退職者と不要な管理者	パスワードが漏れたときの被害が小さくなる
目立たないが動き続ける古い機能	点検の手間が減り、月次の確認が短く済む

謙虚な構成は守りやすい

部品が少なく、役割がはっきりしているサイトは、点検も、外注先への説明も簡単になります。

足すより引く。この姿勢が、保守を続けられる土台になります。

よくある質問

Q1. 自動更新を全て有効にして問題ありませんか

本体のセキュリティ更新は、止めずに自動のままにします。

プラグインとテーマは、基本は自動更新にして、売上に直結するものは、外注先と相談して検証後の手動にするなど、分けて決めると安全です。

Q2. バックアップは、レンタルサーバーの機能だけで足りますか

サーバーの機能に加えて、サーバー会社とは別の場所にも保管することが勧められています。

また、戻せるかを確かめる復元テストを、ときどき行ってください。

Q3. 二要素認証は、誰に設定すべきですか

管理者など、強い権限を持つユーザーが対象です。

WordPress本体には機能が入っていないため、プラグインや外部の認証サービスで追加します。

Q4. サイトが改ざんされたかもしれないとき、最初に何をしますか

気付いた内容と時刻、最近変えたことを書き留め、掃除を始める前に、その時点の状態を保存します。

そのうえで、全てのパスワードを変え、サーバー会社や外注先に連絡してください。

Q5. 保守を外注すれば、自社では何もしなくてよいですか

運用を任せても、サイトを運営する主体は自社です。

月次の報告を受け取り、更新、バックアップ、アカウントの状況を確認することは、自社の役割として残ります。

まとめ

• 本体のセキュリティ更新は止めない。プラグインとテーマも、基本は自動更新にし、月次で更新されたかを確認する
• PHPは推奨（2026年10月時点で8.3以上）を目安に、古いままにしない
• バックアップは、データベースとファイルの両方を、複数の世代と場所に残す。半年に1回は戻せるか試す
• 管理者は少なくし、二要素認証を設定し、不要なユーザーとプラグインは削除する
• Search Consoleに登録し、ハッキングされたときは、原因を直してから審査をリクエストする
• 外注するなら、範囲、頻度、緊急時の対応、引き渡しを契約で決める
• 足すより引く。部品を減らすことが、保守の負担を減らす

まずは今月、上のチェックリストを一度通してみるところから始めてみてください。

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。