EmDashでつくるWebサイト制作の、解説と検証ノート記事一覧

メディアが乗っ取られると何を失うか:SEOスパム改ざんと、追加機能を隔離する設計

オウンドメディアが改ざんされると、知らない間にスパムのページやリンク、転送を埋め込まれ、検索の評価、広告、読者の信用を順に失います。Google の公式ドキュメントで被害の形を整理し、EmDash 1.2.0 で「申告していない操作を追加機能にさせるとどうなるか」を実際に試しました。止まったことと、止まらなかったことを両方書きます。

この記事の目次

オウンドメディアが狙われると、多くの場合、画面が壊れるのではありません。見た目はそのままで、知らないページやリンク、別サイトへの転送が埋め込まれます。気付いたときには、検索結果に警告が付き、順位が落ち、広告が止まっています。

では EmDash なら防げるのか。答えは「入口の一つである追加機能(WordPress のプラグインにあたるもの)からの被害は、仕組みで小さくできる。ただし万能ではない」です。この記事では、被害の形を Google の公式ドキュメントで整理したうえで、EmDash 1.2.0 で実際に追加機能に「申告していない操作」をさせ、何が止まり、何が止まらなかったかを記録します。

メディアが改ざんされると、検索・広告・信用の順に失う

Google は検索のスパムポリシーで、「ハッキングされたコンテンツ」を、サイトのセキュリティの弱点を突いて許可なく置かれたコンテンツと定義しています。挙げられている型は次の 4 つです。

  • コードの埋め込み: 既存のページに、悪意のあるコードを仕込む
  • ページの追加: スパムや悪意のある内容のページを、サイトに新しく作る
  • 内容の改ざん: 既存のページに、目立たないようにリンクや文章を足す
  • 転送: 一部の訪問者を、スパムや有害なページへ転送する

日本語のサイトに関係が深いのが、Google が「日本語キーワードハック」と呼ぶ型です。ランダムな名前のフォルダに、自動生成された日本語のページが大量に作られ、偽ブランド品などへの誘導に使われます。Google の解説では、攻撃者が自分を Search Console(Google の検索管理ツール)の所有者に加え、サイトマップを書き換えて、スパムのページを早く検索に載せようとすることも書かれています。さらに、管理者が見たときだけ普通のページを返す手口(クローキング)もあります。担当者が自分のサイトを開いても、気付けないことがあるということです。

気付かないまま放置すると、失うものは次の順に広がります。

  1. 検索の評価: Google は、ポリシーに違反したサイトは順位が下がるか、検索結果に出なくなることがあると明記しています。
  2. 検索結果での見え方: 改ざんが疑われるページには「このサイトは第三者によってハッキングされている可能性があります」という表示が付き、ブラウザが警告画面を出すこともあります。表示を外すには、所有者が直して再審査を申し込む必要があり、Google のヘルプでは再審査に数日から数週間かかるとしています。
  3. 広告: Google 広告のポリシーでは、改ざんされたサイトへ誘導する広告は不承認になります。メディアの記事に広告で集客している場合、その間は集客も止まります。
  4. 読者の信用: 検索結果の警告を見た読者や取引先は、記事を開くのをためらいます。数字には表れにくい損失です。

記事が数百本あるメディアでは、知らないページが数十本増えても、管理画面の一覧だけでは気付きにくくなります。だからこそ「入られてから探す」より「入られても広がらない」仕組みが効いてきます。

WordPress では、追加機能 1 つの穴がサイト全体に広がる

WordPress の安全性を調べている Patchstack の 2026 年版の報告では、2025 年に WordPress の周辺で見つかった弱点は 11,334 件でした。そのうち 91% がプラグイン、9% がテーマで、WordPress 本体は 6 件です。また、46% は公表の時点で作者の修正が間に合っておらず、狙われやすい弱点が大量に悪用され始めるまでの時間は、中央値で約 5 時間とされています。

数が多いこと以上に問題なのは、広がり方です。Cloudflare は EmDash を発表した記事で、WordPress のプラグインには隔離がなく、サイトのデータベースとファイルに直接触れられると書いています。つまり、プラグインのどれか 1 つに穴があれば、そこから記事の本文も、新しいページの追加も、転送の設定も、サイトマップも、すべてに手が届きます。

WordPress では穴のあるプラグインから記事の本文・スパムページの追加・転送・サイトマップまで届き、検索の警告や広告の不承認につながる。EmDash では追加機能が隔離された環境にあり、承認した権限だけが外に届き、未承認の書き換え・申告外の通信・ページへの HTML 挿入は止まる
穴が 1 つあっても、EmDash では承認した範囲の外へは広がらない。ただし承認した権限と meta 情報は届く

EmDash は追加機能を箱に入れ、申告と承認を通った操作だけを外に出す

EmDash の追加機能は、サイト本体とは別の、隔離された実行環境(サンドボックス)で動きます。ここでは、メディアを運営する側から見た 4 つの点に絞ります。

  • 記事を書き換えられない。 記事を書く権限を承認していない追加機能には、記事を作る・直すための機能そのものが渡されません。保存の直前に本文を書き換える処理も、登録されずに読み飛ばされます。
  • 外に勝手に通信させない。 通信できるのは、追加機能が申告した宛先だけです。それ以外の宛先や、決められた窓口を通らない直接の通信は、箱の外に出る前に止まります。サイトの秘密情報(環境変数)も見えません。
  • ページにスクリプトを差し込めない。 公開ページに HTML やスクリプトを足す仕組みは、隔離された追加機能には使えません。足せるのは、検索エンジン向けの meta 情報など、決まった形のものだけです。
  • 承認は管理者がする。 管理画面から追加機能を入れられるのは、追加機能の管理権限を持つ管理者です。入れる前に、追加機能が求める権限の一覧が表示され、確認してから入れます。更新で権限が増えるときは改めて確認を求められ、承認するまで古い版のまま動きます。

承認の画面に出る権限のうち、メディアにとって特に意味が大きいものを挙げます。

権限

届く範囲

メディアにとっての意味

記事の書き込み(content:write)

記事の作成・更新・削除

どの記事でも書き換えられる

転送の書き込み(redirects:write)

転送ルールの変更

訪問者の行き先を変えられる

通信(network:request)

申告した宛先への通信

宛先の一覧を確認する

なお、サイトの設定ファイルに直接書いて組み込む追加機能には、この確認画面は出ません。組み込むかどうかは、サイトのコードを管理する人(多くは制作・保守を任せている会社)が決めます。誰が何を承認しているのかは、発注する側が把握しておきたい点です。

実際に試した:申告していない操作をさせると、箱の外に出る前に止まった

公式ドキュメントの説明どおりに動くかを、自分たちで確かめました。

  • 日時と版: 2026年10月15日、EmDash 1.2.0(ブログのテンプレートで新しく作ったサイト)
  • 隔離の仕組み: Node.js 用の公式の隔離ランナー(Cloudflare のオープンソースの実行環境 workerd を別のプロセスとして動かすもの)。開発用サーバーと、本番と同じ起動方法の両方で試した
  • 試した追加機能: 検証用に作ったもの。申告は「記事を読む」と「example.com だけに通信する」の 2 つ。そのうえで、申告していない操作を順に試させた

Cloudflare の上で動かす場合、この隔離には Cloudflare の有料プラン(Workers Paid)が必要です。今回は有料プランを使わず、同じ考え方で作られた Node.js 用の仕組みで確かめました。Cloudflare 上での挙動は確かめていません。

試したこと

結果

意味

記事を新しく作る・書き換える

機能そのものが渡されず失敗

承認なしに記事は増やせない

保存の直前にタイトルへ文字を足す

処理が登録されず、タイトルはそのまま

編集者の保存に紛れ込めない

申告していない宛先(example.org)へ通信

「許可されていない宛先」として拒否

外部への送信先を増やせない

窓口を通さず直接通信

箱の中で拒否され、外に出ない

抜け道の通信も止まる

サイトの環境変数を読む

何も見えない

秘密情報は渡らない

ページの末尾に隠しリンクを差し込む

処理が呼ばれず、ページに出ない

隠しリンクは足せない

比べるために、隔離を外す設定(sandbox: false、公式には不具合の切り分け用で本番では使わないよう書かれている)でも同じことを試しました。こちらでは直接の通信が外部のサイトに届き、サイトの環境変数も 76 個すべて読めました。同じ追加機能でも、箱に入っているかどうかで、届く範囲がこれだけ変わります。

検証結果の比較:申告・承認のない記事の作成と書き換え、保存前の書き換え処理、申告外の通信と直接の通信、ページへの HTML 差し込みと環境変数の読み出しは止まった。記事の書き込みを許可した版での書き換え、canonical や noindex の上書き、隔離を外した設定での直接の通信と環境変数の読み出しは止まらなかった
EmDash 1.2.0、Node.js 用の隔離環境(workerd)で 2026年10月15日に検証

手順と、追加機能のコード、結果の記録は記事の制作フォルダに残しています。

正直に書くと、隔離では防げないこともある

同じ検証で、止まらなかったことも確かめました。隔離は「追加機能からの被害」を小さくする仕組みで、改ざん全体を防ぐものではありません。

  • 承認した権限の中では、何でもできる。 検証用の追加機能に記事の書き込みを許可すると、新しく作った記事のタイトルに文字が足されました。公式ドキュメントも、記事の書き込みを許された追加機能は、自分が作った記事に限らずどの記事でも書き換えられると明記しています。承認の判断を誤れば、隔離があっても書き換えられます。
  • 検索向けの meta 情報は、申告なしで書き換えられる。 公開ページの見出し部分に meta 情報を足す処理は、権限の申告が要りません。検証では、何も承認していない追加機能が「この記事の正式な URL は別のサイトにある(canonical)」「検索に載せない(noindex)」という情報を出せました。検索の評価に直接関わるので、入れている追加機能がページに何を出しているかは、公開ページの HTML で確かめる必要があります。承認の画面にこの処理が表示されるかは、確かめていません。
  • 管理者のアカウントを乗っ取られれば、隔離は関係ない。 管理者は、追加機能を入れることも、記事を直接書き換えることもできます。EmDash のログインは、パスワードの代わりにパスキー(端末の生体認証などでログインする方式)が標準で、公式には、ログイン情報がサイトのドメインに結び付くため、偽サイトに誘導されても使えない方式と説明されています。ログインの入口には回数の制限もあります。検証では、本番と同じ起動方法のサーバーで、開発用のログイン省略が拒否され、ログインしていない状態での記事の取得や書き換えが拒否されることを確かめました。パスキーそのものへの攻撃は試していません。書き手ごとの権限の分け方は 複数の書き手で運用するときの権限とレビュー で扱います。
  • サイト本体のコードは箱の外にある。 ページの見た目を作るコード(WordPress のテーマにあたるもの)、隔離されない形式の追加機能、サイトが使う外部の部品は、サイト本体と同じ権限で動きます。ここに穴があれば、隔離の外で被害が起きます。コードの変更を誰が承認し、どう公開しているかは、別に管理が必要です。
  • 隔離には費用と条件がある。 Cloudflare の上では有料プランが前提です。Node.js 用の仕組みでは、処理時間の上限だけが守られ、CPU やメモリの上限はかかりません。

WordPress のままでよい場合と、今のサイトで確かめること

WordPress でも、改ざんの多くは運用で防げます。次の条件がそろっているなら、改ざん対策だけを理由に移る必要はありません。

  • 入れているプラグインが少なく、どれも更新が続いている
  • 更新を当てる担当が決まっていて、公表から数時間〜数日で当てられている
  • 不正なアクセスを手前で遮る仕組み(WAF など)や改ざんの監視を、契約で任せている

反対に、プラグインが増えて誰も全体を把握していない、更新が月に一度の作業になっている、という状態なら、追加機能を箱に入れる設計は大きな意味を持ちます。

どちらの CMS を使っているかに関係なく、今日すぐ確かめられることがあります。

  1. Search Console を開き、所有者の一覧に知らない人がいないか、「セキュリティの問題」に何か出ていないかを見る
  2. Google で site:自社のドメイン と検索し(Google の日本語キーワードハックの解説でも勧められている方法)、書いた覚えのないページや、日本語のおかしなタイトルが並んでいないかを見る
  3. 入れている追加機能の一覧を出し、それぞれ何の権限を持ち、誰が入れたかを書き出す

3 で「誰が承認したか分からない」ものが出てきたら、仕組みを見直す合図です。追加機能の承認まで含めて設計を相談したい場合は、EmDashでつくるWebサイト制作からご連絡ください。

参考(一次情報)

WRITTEN BY

EmDash制作チーム

Noweverの「EmDashでつくるWebサイト制作」の制作チームです。Cloudflareの基盤で動くCMS「EmDash」によるサイト設計、更新機能、セキュリティ、WordPressからの移行について、制作の現場で確認したことを記録しています。

EmDash制作チームについて →
← すべての記事を見る