タグアーカイブ トラブル解決

  1. ホーム   /  タグ付きの投稿: "トラブル解決" ( 固定ページ2 )
WooCommerceのStripe決済が自動更新後に消えた時の原因と対処法
2026年8月16日 0

WooCommerceのStripe決済が自動更新後に消えた時の原因と対処法

WooCommerceのStripe決済プラグインを自動更新した直後に、設定画面の「決済」タブからStripeが丸ごと消えた場合は、更新時に発生した致命的エラーか、他の決済プラグインとの競合が主な原因だ。まず「ステータス」→「ログ」で fatal-errors の有無を確認し、競合を切り分けた後、キャッシュ削除と設定の再保存で復旧できる。セキュリティパッチ自体がStripe決済を意図的に隠すことはない。

Stripe決済が消える原因は何か

Stripe決済が消える原因は何か

Stripe決済プラグインのアップデート後に、WooCommerceの「設定」→「決済」画面からStripeの項目が消える現象には、いくつかの典型的な原因がある。セキュリティパッチの更新処理そのものがStripeを除外する仕様は存在しないため、まず「更新に伴って別の何かが壊れた」と考えるのが正しい。

最も多いのは、アップデート処理中に発生した致命的エラーだ。プラグイン更新時にPHPのメモリ不足やファイルの不整合が起きると、WooCommerceがプラグインを正常に読み込めなくなり、決済方法の一覧からStripeが消える。管理画面には「このサイトで重大なエラーが発生しました」と表示される場合もあれば、画面に何も表示されず設定一覧だけが欠けるケースもある。

次に多いのがプラグイン競合だ。複数の決済ゲートウェイ系プラグインを導入していると、アップデート後に読み込み順序が変わって競合し、Stripeが一覧から漏れることがある。WooCommerceの決済方法はフィルターを通して一覧に追加されるため、競合相手のプラグインがエラーを出すと後続の読み込みが止まり、Stripeが表示されない。

キャッシュが原因になるケースも見逃せない。アップデート直後にサーバーキャッシュやオブジェクトキャッシュへ古い状態が残っていると、管理画面の一覧にだけ反映されずStripeが消えて見える。ブラウザキャッシュでも同様の現象が起こる。

Before「Stripeが見つからない状態」
WooCommerceの「設定」→「決済」画面を開くと、有効な支払い方法の一覧にStripeが表示されない
↓
After「Stripeが復活した状態」
Stripeが一覧に再び表示され、チェックアウトでクレジットカード決済が利用できる
■ Stripeが消えた状態　■ 復旧後

このデモは、決済タブでStripeが消えた状態から復旧した状態への変化を示している。ここから先の手順を順に実行すれば、原因の特定と復旧まで進められる。

致命エラーログで原因を特定する手順

致命エラーログで原因を特定する手順

最初に確認すべきは、WooCommerceが記録している致命的エラーのログだ。管理画面の「WooCommerce」→「ステータス」→「ログ」タブを開くと、保存されているログの一覧が表示される。この中に fatal-errors で始まる名前のログがあれば、アップデート時になんらかの致命的エラーが発生している。

fatal-errors ログを開くと、エラーが発生した日時、原因となったプラグインやテーマ名、エラーが起きたファイルのパスが確認できる。Stripeプラグインのファイルパスが記録されていれば、そのエラーが原因で一覧から消えた可能性が高い。ログの内容は専門的なPHPの記述が多いが、どのプラグインでエラーが出たかを特定できれば十分だ。

ログに何も出ていない場合は、WP_DEBUG（デバッグモード）を有効にして再現させる方法もある。wp-config.php にデバッグ定数を追記してから決済設定画面をリロードすると、画面にエラー文言が直接表示される。ただし共用サーバーでは本番サイトでデバッグをオンにするとセキュリティ上望ましくないため、確認後は必ず元に戻す。

プラグインの競合を切り分ける

プラグインの競合を切り分ける

致命エラーログが出ていない、または出ていても原因が特定できない場合は、プラグイン競合の切り分けに進む。決済系プラグインを複数導入している環境では、どれか1つがStripeの読み込みを妨げている可能性がある。

切り分けの基本は「一度に全部を無効化しない」ことだ。Stripeを除く他の決済プラグインを1つずつ無効化し、そのつど「設定」→「決済」画面をリロードしてStripeが表示されるか確認する。たとえば「WooCommerce PayPal Payments」や「Amazon Pay」などを無効化するたびに確認を繰り返すと、競合相手を特定できる。

決済プラグインだけでなく、最近更新したプラグインやテーマも疑う。プラグインを全無効化してもStripeが表示されない場合は、テーマを標準テーマの「Twenty Twenty-Four」などに切り替えて同じ画面を確認する。テーマ側のフックが決済一覧を書き換えている例も過去にある。

STEP 1 致命エラーログを確認する
WooCommerceの「ステータス」→「ログ」で fatal-errors の有無を調べる
↓
STEP 2 プラグイン競合を切り分ける
他の決済プラグインを順に無効化して症状が直るか確認する
↓
STEP 3 サイトキャッシュを削除する
サーバーキャッシュとブラウザキャッシュを消して再読み込みする
↓
STEP 4 Stripe設定を再保存する
Stripe設定を開いて保存し直し、API接続が有効か確認する

このデモは、Stripe決済が消えたときに進めるトラブルシューティングの流れを示している。各ステップの詳細は本文の対応する見出しで確認できる。

キャッシュ削除と設定の再保存で復旧させる

キャッシュ削除と設定の再保存で復旧させる

競合の切り分けで原因が特定できた場合も、原因がまだ判明しない場合も、次に試すのはキャッシュの削除とStripe設定の再保存だ。この2つを実行するだけで、実害のない一時的な不整合が解消されてStripeが一覧に復活することが多い。

キャッシュ削除は、レンタルサーバーの管理画面で提供されているサーバーキャッシュ、WooCommerceのシステムが内部で使うオブジェクトキャッシュ、そして自分が閲覧しているブラウザのキャッシュの3つを対象にする。キャッシュ系プラグインを導入している場合は、そのプラグインの管理画面から全キャッシュを削除してから、決済設定画面をリロードする。

Stripe設定の再保存は、WooCommerceの「設定」→「決済」でStripeの項目が表示されていなくても実行できる場合がある。「決済」タブの一覧にStripeが出ていなくても、左メニューに「Stripe」の設定ページが残っていれば、そこを開いて「変更を保存」を押す。これにより設定値が再評価され、一覧に反映される。

設定を保存し直すと、StripeのAPI接続状態も再チェックされる。接続が切れていた場合は「接続」ボタンが表示されるため、そこからStripeアカウントに再接続できる。APIキーが無効になっている、あるいはテストモードと本番モードの切り替えが正しくない場合も、再接続で直るケースがある。

それでも直らない場合の追加チェック

ここまでの手順を実行してもStripeが一覧に表示されない場合は、環境そのものに問題がある可能性が高い。「WooCommerce」→「ステータス」→「システムステータス」を開き、WordPress本体、WooCommerce本体、PHPの各バージョンがStripeプラグインの推奨要件を満たしているか確認する。プラグイン更新後にPHPのバージョン要件が引き上げられ、サーバーのPHPが古いままだと読み込みに失敗することがある。

システムステータスレポートには、有効化している全プラグインの一覧と、WooCommerceが認識している各設定値がまとまっている。この中でStripeプラグインが「有効」になっているか、「非アクティブ」や「エラー」になっていないかを確認する。プラグイン一覧のページでStripeが有効化されていても、WooCommerce側で読み込めていない状態が可視化されることがある。

最終手段として、以前の安定したバージョンへロールバックする方法もある。プラグインの配布ページから過去バージョンのZIPファイルを取得して手動で上書きするか、「WP Rollback」のようなロールバック用プラグインを使って1つ前のバージョンへ戻す。ただしロールバックはセキュリティパッチを巻き戻すことになるため、あくまで復旧のための一時的な手段として扱い、原因を特定した上で最新版へ戻す計画を立てる。

よくある質問

Stripe決済が消えたのは自動更新の不具合か

自動更新自体がStripeを意図的に外すことはない。更新処理の中で発生した致命的エラーや、更新後に顕在化したプラグイン競合が原因であるケースがほとんどだ。ログを確認して切り分けることで特定できる。

セキュリティパッチによってStripeが意図的に隠されることはあるか

通常のセキュリティパッチがStripe決済を隠す仕様は存在しない。もしセキュリティ上の理由で決済方法が制限されるなら、公式リリースノートに明記される。リリースノートに記載がないのに消えた場合は、パッチの直接の影響ではなく別の要因を疑う。

Stripe Linkだけが表示されない場合は何を確認するか

Stripeゲートウェイ自体は表示されているが、Stripe Linkという特定の支払い方法だけが表示されない場合は、Stripe設定ページ内の「支払い方法」セクションでLinkが有効化されているか確認する。また、Stripeのアカウント側でLinkが利用可能な地域・通貨であるかも確認が必要だ。

システムステータスレポートのどこを見れば原因が分かるか

まず「環境」セクションでPHPとWooCommerceのバージョンが要件を満たしているか、次に「有効なプラグイン」でStripeが正常に読み込まれているか、そして「ログ」セクションでエラーが記録されていないかを順に確認する。レポートはサポートに共有する際にもそのまま使える。

プラグインを以前のバージョンに戻してもよいか

復旧を優先するなら一時的なロールバックは有効な手段だ。ただしセキュリティパッチを含む更新を巻き戻すため、原因を特定して修正した後は最新版へ戻すことが前提になる。ロールバック前に必ずサイト全体のバックアップを取る。

この記事のポイント

  • Stripeが決済一覧から消えた主因はupdate時の致命的エラーとプラグイン競合
  • セキュリティパッチ自体がStripeを隠すことはない
  • 最初にWooCommerceの「ステータス」→「ログ」で fatal-errors を確認する
  • 競合切り分け後はキャッシュ削除とStripe設定の再保存で復旧を試す
  • 復旧しない場合はシステムステータスでPHP・WooCommerceの要件を確認する
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WP Offload Mediaでサイトに重大なエラーが発生した時の原因と対処法
2026年8月14日 0

WP Offload Mediaでサイトに重大なエラーが発生した時の原因と対処法

WP Offload Media（S3/CloudFrontにメディアを転送するプラグイン）でサイトに「このサイトで重大なエラーが発生しました」と表示され、画面が表示されなくなる場合、PHP 8.xではプラグイン内部のsprintf()呼び出しに引数が1つ足りないのが原因だ。最新版へのアップデートで解消する。

なぜWP Offload MediaでArgumentCountErrorが起きるのか

なぜWP Offload MediaでArgumentCountErrorが起きるのか

このエラーの直接の原因は、WP Offload Mediaの remove-local-handler.php 内にある sprintf() 呼び出しだ。メディアをS3へ転送（オフロード）した後、ローカルファイルを削除しようとして失敗すると、エラーメッセージを整形する処理が走る。その際、翻訳文字列にファイルパス用の %s が含まれているのに、実際のファイルパスが渡されていない。

PHP 7.xまでは引数不足の sprintf() は警告で済んでいた。ところが PHP 8.0 以降では ArgumentCountError という致命的エラーになり、未処理の例外としてサイト全体が停止する。本来なら所有権やパーミッションの警告で済むはずの内部メッセージ生成が、フロントエンド全体を落とす事態になる。

発火のきっかけは特定の操作に限らない。Yoast SEO のスキーマ生成が wp_head 内で wp_get_attachment_image_url() を呼ぶケースもある。カスタム投稿やギャラリー、商品ページのサムネイル取得など、アップロード済みメディアの URL を取得する場所ならどこでも起こり得る。

Before（エラー状態）
sprintf() にフォーマット文字列だけを渡し、%s 用のファイルパスが無い。PHP 8が ArgumentCountError を投げ、サイト全体が停止する。
↓
After（修正後）
sprintf() の第2引数に $file を渡す。エラーは警告として記録されるだけで、サイトは稼働を続ける。
■ エラー状態　■ 修正後

修正版では sprintf() の第2引数として $file（実際のファイルパス）が追加される。未処理の例外がなくなるため、フロントエンドの停止を防げる。

エラーログから原因の関数名を確認する手順

エラーログから原因の関数名を確認する手順

画面上では「このサイトで重大なエラーが発生しました」とだけ表示され、詳細はわからない。管理者宛のメールやサーバーのPHPエラーログにスタックトレースが残っている場合もあるが、WordPress の debug.log を有効にするのが最も確実だ。

  • wp-config.php をテキストエディタかFTPで開く
  • WP_DEBUG と WP_DEBUG_LOG を true にして保存する
  • エラーが起きたページを再読み込みする
  • wp-content/debug.log を開き、ArgumentCountError と Remove_Local_Handler を探す

スタックトレースに「2 arguments are required, 1 given」という記述があれば、この症状と一致する。Yoast SEO が呼び出し元に含まれる場合もあるが、他のプラグインやテーマ由来でも発火するため、関数名の確認を優先する。

WP Offload Mediaをアップデートして修正する手順

WP Offload Mediaをアップデートして修正する手順

修正が取り込まれたバージョンがリリースされていれば、管理画面からプラグインを更新するのが最短の対応だ。WP Offload Media はサブスクリプション型のライセンスで更新が配布されるため、ライセンスが有効かどうかも確認しておく。

STEP 1 管理画面の「プラグイン」を開く
↓
STEP 2 WP Offload Media に更新があるか確認する
↓
STEP 3 プラグインを更新する
↓
STEP 4 キャッシュを削除し、ページの復旧を確認する

更新後はサーバーキャッシュとブラウザキャッシュを削除してから、エラーが出ていたページを開き直す。WP CLI を使える環境では wp plugin update コマンドでも更新できる。

すぐに更新できない場合の一時的な対処

すぐに更新できない場合の一時的な対処

サブスクリプションの期限切れなどで更新が受けられない場合は、remove-local-handler.php に直接修正を加える方法がある。管理画面の「プラグイン」メニューにある「プラグインファイルエディター」からWP Offload Media を選び、remove-local-handler.php を開く。

sprintf() に $file を追加して回避する

修正箇所は2つある。remove-local-handler.php の180行付近と185行付近だ。どちらも sprintf() の閉じ括弧の前に、カンマと $file を追加する。このファイルはプラグイン本体のため、次回のアップデートで上書きされるが、修正版が配布されるまでの時間稼ぎにはなる。

// 修正前（180行付近）
$file_to_remove['remove_result']['message'] = sprintf(
    __( "Error removing local file. Couldn't find the file at %s", 'amazon-s3-and-cloudfront' )
);

// 修正後
$file_to_remove['remove_result']['message'] = sprintf(
    __( "Error removing local file. Couldn't find the file at %s", 'amazon-s3-and-cloudfront' ),
    $file
);

// 185行付近も同様に $file を追加する

プラグインを一時的に無効化する

管理画面に入れる場合は、WP Offload Media を一時的に無効化すればサイトは復旧する。ただし、メディアがすでにS3にオフロードされていると、無効化中はローカルに存在しない画像が表示されないことがある。緊急時の対応と割り切って使う。

PHPバージョンを7.4に戻す

サーバーの設定で PHP を 7.4系に戻せばエラーは出なくなる。ただし、PHP 7.4はセキュリティサポートが終了しているため、恒久対策にはならない。あくまで更新までの一時的な回避策だ。

所有権とパーミッションを見直して再発を防ぐ

所有権とパーミッションを見直して再発を防ぐ

このエラーが起きたということは、オフロード後に削除するはずのローカルファイルに削除権限がなかった可能性が高い。プラグインの修正後は、アップロードディレクトリの所有権とパーミッションを確認し、Webサーバーユーザーが書き込める状態にしておく。

アップロードディレクトリ（wp-content/uploads）は、ディレクトリが755、ファイルが644であることが一般的だ。所有権がFTPユーザーになっていると、Webサーバープロセスが削除できず同じ状態になる。サーバー管理画面やシェルから、アップロードディレクトリの所有者をWebサーバーの実行ユーザーに合わせる。

# 所有者とグループをWebサーバー実行ユーザーに合わせる（www-data は環境により異なる）
sudo chown -R www-data:www-data wp-content/uploads

# ディレクトリとファイルの権限を整える
find wp-content/uploads -type d -exec chmod 755 {} \;
find wp-content/uploads -type f -exec chmod 644 {} \;

実行ユーザーの名前はサーバー環境によって www-data、apache、nginx など異なる。レンタルサーバーでは管理画面のファイルマネージャーから所有者を変更できないこともあるため、その場合はカスタマーサポートに依頼するか、PHP を実行ユーザーと同じ権限で動かす設定を検討する。

よくある質問

管理画面にも入れないほど真っ白になった場合はどうする？

FTPやサーバーのファイルマネージャーから wp-content/plugins/ に入り、WP Offload Media のフォルダ名を「WP Offload Media_backup」のように変更して無効化する。WordPress はプラグインが存在しないと認識し、サイトを復旧できる。その後、原因を修正してからフォルダ名を元に戻す。

プラグインを更新したのにまだエラーが出るのはなぜ？

キャッシュが残っている可能性が高い。サーバーキャッシュとブラウザキャッシュを削除してから再確認する。それでも出る場合は、別のプラグインが同様の sprintf() 引数不足を起こしている。デバッグログのスタックトレースを再確認する。

ArgumentCountError は WP Offload Media 以外でも起きる？

起きる。PHP 8.0以降では、翻訳文字列に %s を含む sprintf() で引数を渡し忘れると同様の致命的エラーになる。古いテーマやプラグインで潜伏していることが多い。PHP 8.x へ移行する際は事前にステージング環境でテストするのが基本だ。

所有権の問題を放置するとどうなる？

ローカルファイルの削除が失敗し続け、アップロードディレクトリに同じファイルが重複して残る。ディスク容量やバックアップサイズにも影響する。プラグイン自体は修正されても、警告ログが出続けるため、所有権は合わせて直しておくべきだ。

この記事のポイント

  • WP Offload Media の sprintf() 引数不足が PHP 8.x で致命的エラーになる
  • 「このサイトで重大なエラーが発生しました」の裏で ArgumentCountError が起きている
  • 修正版への更新が最短の解決策
  • 更新できない間は sprintf() の第2引数に $file を追加する
  • 所有権とパーミッションを整えて同じ失敗が起きないようにする
佐々木 太陽
, , , , ,
お悩み・トラブル解決
UpdraftPlusのバックアップが途中で失敗する原因と対処法
2026年8月14日 0

UpdraftPlusのバックアップが途中で失敗する原因と対処法

UpdraftPlusのバックアップが途中で止まって失敗する場合、まず確認すべきはセマフォロックの詰まりとサーバー側の実行時間制限だ。ログにエラーが表示されず、ファイル追加の途中で途切れているなら、バックアップ処理がサーバーから強制終了されている可能性が高い。

バックアップが途中で失敗する原因をログから特定する

バックアップが途中で失敗する原因をログから特定する

UpdraftPlusのログに「このサイトで重大なエラーが発生しました」のような明確なメッセージがなく、zipファイルへのファイル追加が途中で止まっている場合、原因のほとんどはバックアップ処理が外部から強制終了されたことにある。ログの末尾に「失敗」や「エラー」の表記がなく、単に記録が終わっている点が重要な手がかりだ。

具体的には、以下の3つのポイントをログから読み取る。1つ目は冒頭の「Semaphore（セマフォ）」に関する記述だ。「Semaphore was stuck」と表示されているなら、前回のバックアップがクラッシュしてロックが残ったままになっていたことを示している。2つ目は処理中に「cgi-fcgi」と記録されている点で、FastCGI経由でPHPが動いている証拠だ。3つ目はファイル追加の記録が数千件単位で正常に進んだ後、突然途切れている点だ。

異常パターン ログの末尾にエラー文言がなく、ファイル追加の途中で記録が止まる
↓
正常パターン 「The backup apparently succeeded」等の完了メッセージが末尾に記録される
■ 強制終了の特徴　■ 正常完了の特徴

上のデモは、強制終了されたバックアップと正常に完了したバックアップのログ末尾の違いを示したものだ。UpdraftPlusのログはバックアップが正常に終わった場合、末尾に完了を示すメッセージが必ず記録される。エラー文言も完了メッセージもないまま記録が途切れているなら、PHPのプロセスごと外部から停止されたと判断できる。

セマフォロックの詰まりが起きる仕組み

セマフォロックとは、同時に複数のバックアップが走らないようにするための「占有フラグ」だ。バックアップ開始時にWordPressのオプションテーブル（wp_options）にロック用の値を書き込み、終了時に削除する。しかし、サーバーが処理を強制終了した場合、ロックを削除する処理まで到達できないため、古いロックが残ってしまう。

残ったロックは次回のバックアップ開始時に「stuck（詰まっている）」と判定され、UpdraftPlusが自動的にリセットする。ログに「Semaphore was stuck, reset to 1」と出ていれば、これは前回のバックアップが異常終了した履歴を示している。ロックの詰まり自体は自動回復するが、その前の回でなぜ強制終了されたのかを解決しなければ、同じ失敗を繰り返す。

セマフォロックの詰まりを解消してから再実行する手順

セマフォロックの詰まりを解消してから再実行する手順

ロックの詰まりが記録されている場合、まずは古いロックを手動で削除してからバックアップを再実行する。UpdraftPlusはロックを自動リセットするが、データベースに古いレコードが残っていると、別の不整合を引き起こすことがある。手動で掃除してから再実行すれば、より確実に状態をリセットできる。

STEP 1 phpMyAdminまたは管理画面からwp_optionsテーブルを開く
↓
STEP 2 「updraftplus_locked_」で始まるレコードを検索して削除する
↓
STEP 3 「updraftplus_last_lock_time_」で始まるレコードもあわせて削除する
↓
STEP 4 UpdraftPlusの「今すぐバックアップ」を実行して動作を確認する

上記の手順でロックを掃除したら、必ずバックアップを即時実行して挙動を確認する。ロックを消しただけでは根本原因は解消されていないため、再び同じ場所で処理が止まるかどうかをログで追う必要がある。もし再び途中で止まるなら、次のセクションで説明するサーバー側の実行制限が原因だ。

wp_optionsテーブルを安全に操作するには

wp_optionsテーブルの操作はレンタルサーバーの管理画面からphpMyAdminを開いて行う。テーブル名はインストール時にプレフィックスを変更している場合があるため、「wp_options」が存在しない場合は「wp_」の部分を導入時に設定した文字列に読み替える。該当するレコードを検索するには、phpMyAdminのSQLタブで「option_name LIKE ‘updraftplus_locked_%’」のような条件を指定すると確実だ。

データベースを直接触るのが不安な場合は、必ず事前にデータベース全体のエクスポートを実行しておく。wp_optionsテーブルはサイト全体の設定を保持する重要なテーブルなので、削除対象を間違えるとサイトが表示されなくなる恐れがある。削除するのは「updraftplus_」で始まるロック関連のレコードだけに限定する。

サーバーの実行時間制限が原因なら設定を見直す

サーバーの実行時間制限が原因なら設定を見直す

ログに「cgi-fcgi」と記録されている環境では、サーバー側のFastCGI設定がバックアップ処理を途中で切断している可能性が高い。この場合、UpdraftPlusやWordPressの設定をいくら変更しても解決しない。サーバーの実行時間制限とプロセス管理の仕組みを理解し、制限内に収まるようにバックアップ規模を調整するか、サーバー側の設定を変更する必要がある。

バックアップ対象を絞って1回あたりの負荷を下げる

処理が途中で強制終了される最も簡単な回避策は、1回のバックアップで処理するデータ量を減らすことだ。UpdraftPlusの設定画面で「ファイルのバックアップ」の対象から、変更頻度の低い大容量ディレクトリを除外する。たとえば、開発用のnode_modulesやキャッシュディレクトリ、過去のバックアップファイルなどは除外候補になる。

データベースのバックアップも同様に、ログや一時テーブル、リビジョンなどを除外すると処理時間を短縮できる。とくに投稿リビジョンやスパムコメント、ゴミ箱内のデータは意外と容量が大きい。不要なデータを定期的に削除するだけでも、バックアップの所要時間が大きく変わる。

zip分割サイズとバッチ処理の調整

UpdraftPlusの詳細設定では、zipファイルを分割するサイズを変更できる。デフォルトでは400MBごとに分割されるが、ファイル数が多いサイトでは分割サイズを小さく設定すると、1回のバッチ処理にかかる時間を短縮できる。ログで「split every 400 MB」と表示されている箇所が、この設定の反映だ。

分割サイズを200MBや100MBに下げると、1回のzip処理が短くなり、サーバーの制限時間内に完了しやすくなる。ただし、分割数を増やすと全体の処理時間は逆に延びるため、サーバーの制限時間に対してどこで止まるかを見極めながら調整する。ログの経過時間と処理件数を確認し、どこまで進んだ時点で強制終了されるかを把握することが先決だ。

バックアップを安定させるための追加対策

バックアップを安定させるための追加対策

ロックの掃除とバックアップ対象の絞り込みに加えて、以下の設定を組み合わせると、UpdraftPlusのバックアップ成功率が大きく向上する。いずれも管理画面から変更できる項目なので、サーバーに詳しくなくても実行できる。

バックアップの実行方法を「手動」から「cron」に切り替える

管理画面から手動でバックアップを実行すると、ブラウザとサーバーの接続が切れたタイミングで処理が中断されることがある。一方、WordPressのcron（疑似cron）を使ったスケジュール実行は、サーバー側で処理が完結するため、ブラウザの接続状態に影響されない。UpdraftPlusの設定で「バックアップのスケジュール」を有効にし、実行タイミングを毎日や毎週などに設定する。

ただし、WordPressの疑似cronはサイトへのアクセスをきっかけに動くため、アクセスの少ないサイトでは実行が遅れることがある。その場合はサーバー側のcron（本物のcron）を設定し、wp-cron.phpを定期的に呼び出す方式に切り替えると確実だ。レンタルサーバーの管理画面からcronジョブを追加できる場合が多い。

バックアップの保存先を外部ストレージに変更する

バックアップをサーバー内のディレクトリに保存していると、バックアップ完了後にファイルを外部へ転送する処理が追加され、時間がかかるだけでなく、転送中のエラーで失敗と記録されることがある。UpdraftPlusはGoogle DriveやDropbox、Amazon S3などへの直接アップロードに対応しているため、外部ストレージを保存先に指定すると、サーバー内への書き込みと転送を1つの流れで行える。

外部ストレージへの保存は、サーバーのディスク容量不足による失敗を防ぐ効果もある。バックアップは数GB単位で容量を消費するため、共用サーバーでは容量制限に達して書き込みに失敗するケースが少なくない。ログの冒頭に「Free space on disk」の値が記録されているので、この数値が数十GB以上確保されているかも確認しておく。

PHPの実行時間とメモリ制限を確認する

ログの冒頭には「max_execution_time」と「memory_limit」が記録されている。max_execution_timeはPHPスクリプトが実行できる最大時間、memory_limitはPHPが使用できるメモリの上限だ。どちらもバックアップ処理に直結する設定で、これらの値が小さいと処理が途中で打ち切られる。

レンタルサーバーによっては、管理画面からPHPのバージョンや設定を変更できる。max_execution_timeを300秒以上、memory_limitを512MB以上に設定できるなら変更を検討する。ただし、共有サーバーでは変更できない場合も多い。その場合は先に説明したバックアップ対象の絞り込みで対応するほうが現実的だ。

よくある質問

ログにエラーが何も表示されません。どこを確認すればいいですか？

ログの末尾に「失敗」や「エラー」の文言がなく記録が途中で止まっている場合、PHPのプロセスがサーバーから強制終了された可能性が高い。ログの経過時間と処理済みファイル数を確認し、どこまで進んだ時点で止まったかを特定する。あわせて冒頭のセマフォロック関連の記述も確認する。

セマフォロックは自動的に解消されますか？

UpdraftPlusは次回のバックアップ開始時に古いロックを自動でリセットする。ただし、原因が解決されていなければ再び同じ場所で強制終了され、ロックの詰まりが繰り返される。手動でロックを掃除したうえで、根本原因であるサーバーの実行制限やバックアップ規模の見直しを行うことが重要だ。

バックアップ対象から除外すべきフォルダはありますか？

キャッシュディレクトリ、過去のバックアップファイル、開発用の依存関係が入ったディレクトリ、ログファイルなどは除外候補になる。とくに「node_modules」や「vendor」のようなディレクトリは数千から数万のファイルを含むことがあり、ファイル数の多さがバックアップを遅くする大きな要因になる。

UpdraftPlusのログはどこで確認できますか？

管理画面の「設定」から「UpdraftPlus バックアップ」を開き、「既存のバックアップ」タブを表示する。各バックアップの横にある「ログを表示」ボタンから詳細なログを確認できる。ログは最新のものから順に表示され、画面上でスクロールしながら全文を確認できる。

バックアップが途中で止まる場合、サーバー会社に問い合わせるべきですか？

レンタルサーバーの管理画面から設定を変更できない項目が原因の場合、サーバー会社への問い合わせが必要になる。問い合わせる際は、UpdraftPlusのログの該当部分を添付し、「バックアップが毎回特定のタイミングで強制終了される」と具体的に伝えると、調査がスムーズに進む。

この記事のポイント

  • ログに完了メッセージがなく途中で止まる場合は強制終了が原因
  • セマフォロックの詰まりは前回の異常終了の痕跡
  • wp_optionsのロック関連レコードを手動で削除して状態をリセット
  • バックアップ対象の絞り込みとzip分割サイズの調整で負荷を下げる
  • cron実行と外部ストレージ保存の組み合わせで成功率を上げる
佐々木 太陽
, , , , ,
お悩み・トラブル解決
SureCookieで同意ログが記録されない時の原因と対処法
2026年8月13日 0

SureCookieで同意ログが記録されない時の原因と対処法

SureCookie で同意ログが 0 件のまま増えない場合、まず疑うのは REST API の URL が 404 を返している状態だ。パーマリンク設定とキャッシュ・最適化プラグインの影響を順に確認すれば、原因を特定できる。

同意ログが記録されない原因は REST API の URL にある

同意ログが記録されない原因は REST API の URL にある

訪問者が Cookie 同意バナーで「すべて同意」を選ぶと、SureCookie は WordPress の REST API に POST リクエストを送り、同意内容をログへ書き込む。この API とは、サイト内部と外部のスクリプトがデータをやり取りするための仕組みだ。

ところが、サイト側の設定やキャッシュの影響で、送信先の URL が意図した形にならないことがある。正常なら /wp-json/ から始まる URL が使われるが、設定オブジェクトが読み込まれないと /?rest_route= という形式に切り替わる。どちらも本来は動作する形式だが、後者が 404 を返す場合はリクエストが WordPress 本体に届いていない。

ブラウザの開発者ツールでネットワークタブを開き、バナー操作時の POST リクエストを確認すると、404 ステータスが返っている様子を直接確認できる。これが確認できれば、ログが記録されない直接の原因だ。

正常時の URL
パーマリンクが「投稿名」で設定オブジェクトあり
POST 先 /wp-json/surecookie/v1/consent
→ 200 OK でログが保存される
↓
問題が起きる URL
設定オブジェクトが読み込まれていない
POST 先 example.com/?rest_route=/surecookie/v1/consent
→ 404 Not Found でログが残らない
■ 正常時　■ 問題発生時

上図は URL の生成パターンを示したイメージだ。パーマリンク設定が「投稿名」などの見やすい形式にもかかわらず /?rest_route= が出る場合は、SureCookie の設定オブジェクトがページに正しく出力されていない。

パーマリンク設定を確認して URL 形式を切り分ける

パーマリンク設定を確認して URL 形式を切り分ける
STEP 1 パーマリンク設定を確認する
↓
STEP 2 キャッシュと最適化を無効化する
↓
STEP 3 REST API の応答を確認する
↓
STEP 4 同意バナーを操作してログを確認する

この手順の全体像を踏まえて、各ステップを詳しく見ていく。

パーマリンク設定が「基本」の場合

WordPress 管理画面の「設定 → パーマリンク」を開き、現在の設定が「基本」になっている場合、/?rest_route= という URL が使われるのは正常な動作だ。この場合、URL の形式そのものは問題ではなく、404 になる原因は別にある。REST API 自体がブロックされているか、リクエストが WordPress に到達していない可能性を後述の手順で確認する。

パーマリンク設定が「投稿名」の場合

パーマリンク設定が「投稿名」などに設定されていれば、通常は /wp-json/ から始まる URL が使われる。それにもかかわらず /?rest_route= が現れるなら、SureCookie の設定オブジェクトがページ上に出力されていない。パーマリンク設定を一度保存し直し、データベース上のリライトルールを再生成するだけでも改善することがある。

キャッシュと JavaScript 最適化が設定を壊すケース

キャッシュと JavaScript 最適化が設定を壊すケース

サーバー付属の最適化プラグインやキャッシュプラグインが、JavaScript の結合・遅延読み込み・圧縮を実行していると、SureCookie がページに埋め込む設定オブジェクトが壊れるか、出力されないことがある。その結果、プラグインが正しい URL を生成できず、フォールバックとして /?rest_route= を送り、404 になる。

キャッシュの全削除と最適化の停止

最初にキャッシュプラグインの管理画面からキャッシュを全削除する。続いて JavaScript の結合、遅延読み込み、圧縮の各機能を一時的に無効化する。この状態でブラウザのシークレットウィンドウを開き、同意バナーを操作してログが記録されるか確認する。直った場合は、最適化機能のどれかが原因だ。

除外設定を追加して再有効化する

原因が特定できたら、SureCookie のスクリプトを最適化の除外リストに追加する。除外対象は SureCookie の本体スクリプトと、それに付随する設定オブジェクトのインラインスクリプトだ。除外設定後、最適化機能を一つずつ再有効化し、その都度ログが記録されるかを確認する。これで各機能の影響を切り分けられる。

REST API がブロックされていないか確認する

REST API がブロックされていないか確認する

セキュリティプラグインやサーバー側の設定で WordPress の REST API が無効化されていると、/wp-json/ も /?rest_route= も 404 や 403 を返す。同意ログの POST リクエストも同じようにブロックされるため、ログが一切記録されない。

REST API の動作確認

ブラウザのアドレスバーに、自サイトのドメインの直後に /wp-json/ を付けてアクセスする。正常なら JSON 形式のデータが表示される。404 や 403 になる場合は、REST API がサイト全体でブロックされている。セキュリティプラグインの設定画面を開き、REST API を許可するか、SureCookie のエンドポイントを除外する。

ログインユーザー限定設定を見直す

REST API へのアクセスをログインユーザーに限定する設定があると、未ログインの訪問者が送る同意 POST が拒否される。同意バナーを操作するのはログインしていない一般訪問者なので、この設定が有効だとログは永遠に記録されない。該当する設定を無効化するか、SureCookie のエンドポイントだけを許可する。

サイトスキャナーが Cookie を検出しない理由

サイトスキャナーが Cookie を検出しない理由

SureCookie に内蔵されたサイトスキャナーが「成功」と表示しても Cookie を 0 件と報告するのは、同意前のスクリプトブロックが働いているためだ。Google アナリティクス 4（GA4）や Microsoft Clarity のタグは、同意が得られるまで読み込まれない。スキャナーがこのブロック状態で実行されるなら、Cookie を検出しないのは想定内といえる。

一方、外部スキャナーが検出できるのは、実際の訪問者が同意した後にタグが発火し、Cookie が設定された状態を計測しているからだ。SureCookie のスキャナーが同意後の状態を反映するかは、製品のバージョンやスキャンの実行タイミングによって異なる。同意ログと実際の Cookie の乖離が続く場合は、プラグインの仕様や設定を確認する必要がある。

よくある質問

同意ログが記録されないと法的に問題になるか

Cookie 同意の記録は、GDPR や改正電気通信事業法などの監査対応で重要な証跡になる。ログが残っていないと、同意取得の事実を証明できないため、監査や紛争時に不利になる可能性がある。運用前に必ず記録される状態へ直しておく。

/?rest_route= という URL は正常なのか

パーマリンク設定が「基本」であれば、/?rest_route= は WordPress が公式にサポートする正常な形式だ。ただし「投稿名」などに設定しているのにこの形式が出る場合は、設定オブジェクトの読み込みに失敗している可能性が高い。

パーマリンク設定が基本のままでも SureCookie は動くか

動くように設計されている。REST API のリクエストが正しく WordPress に到達すれば、/?rest_route= でも同意ログは記録される。404 になるのは URL の形式だけが原因ではなく、リクエスト経路のどこかでブロックされているケースだ。

キャッシュプラグインの除外設定はどの範囲か

SureCookie の本体スクリプトと、設定オブジェクトを含むインラインスクリプトを対象にする。多くのキャッシュプラグインにはスクリプト単位の除外欄があるため、そこに SureCookie 関連のスクリプト名を追加し、結合や遅延読み込みから外す。

同意ログが記録されたか確認する方法は

SureCookie の管理画面にある同意ログ一覧で件数が増えるかを確認する。あわせてブラウザの開発者ツールで POST リクエストが 200 を返しているかを見ると、書き込みが成功しているかがより正確にわかる。

この記事のポイント

  • 同意ログが残らない直接の原因は REST API の 404 だ
  • パーマリンク設定で URL 形式の正常性を切り分ける
  • キャッシュと JavaScript 最適化を無効化して確認する
  • REST API 自体のブロックも忘れずに点検する
  • スキャナーの Cookie 0 件は同意前ブロックが原因になりやすい
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WordPressでデータベース接続確立エラーが出た時の直し方
2026年8月12日 0

WordPressでデータベース接続確立エラーが出た時の直し方

WordPressで「データベース接続確立エラー」が表示される原因は、wp-config.phpファイル内のデータベース接続情報の誤り、またはデータベースサーバー自体の停止に大別される。まずはこの二点を順に確認すれば、大半のケースは解決する。

エラーメッセージが示す根本的な原因は二つだけ

エラーメッセージが示す根本的な原因は二つだけ

WordPressのインストール時や運用中に「データベース接続確立エラー」というメッセージが表示された場合、WordPressは設定ファイルに書かれた情報でMySQL（またはMariaDB）データベースへ接続できていない。エラー画面にも表示される通り、原因は大きく分けて次の二つだ。

  • 認証情報の不一致（wp-config.phpのデータベース名、ユーザー名、パスワード、ホスト名のいずれかが間違っている）
  • データベースサーバーに接続できない（サーバーが停止している、ネットワーク障害がある、ホスト名が間違っている）

新規インストール直後のエラーでは設定ミスが大半を占め、運用中のサイトで突然発生した場合はサーバー側の一時的なトラブルや、何らかの設定変更が影響している可能性が高い。いずれにせよ、対処のステップは決まっている。

エラー 「データベース接続確立エラー」が画面に表示される
↓
認証情報 確認

wp-config.phpのDB_NAME・DB_USER・DB_PASSWORD・DB_HOSTを再チェック

サーバー 確認

データベースサーバーが稼働しているか、管理画面から確認

■ エラー状態　 ■ 認証情報の確認　 ■ サーバー稼働の確認

最初に確認すべきwp-config.phpの設定

最初に確認すべきwp-config.phpの設定

データベース接続情報を記述するwp-config.phpは、WordPressのルートディレクトリに設置されている。エラーが起きたら、まずこのファイルの中身をファイルマネージャーやFTPで開き、以下の4項目が正しいか確認する。

データベース名（DB_NAME）の確認

DB_NAMEには、使用するデータベースの正確な名前を指定する。多くのレンタルサーバーでは、契約時に自動生成されたデータベース名にアカウント名のプレフィックスが付与される（例: username_wp001）。phpMyAdminやサーバー管理画面のMySQLデータベース一覧に表示される名前と、一字一句たがわず一致させる必要がある。大文字小文字も区別されるため、コピー＆ペーストで転記するのが確実だ。

ユーザー名（DB_USER）とパスワード（DB_PASSWORD）の精査

データベースに接続するためのユーザー名とパスワードも同様に、サーバー側で作成したMySQLユーザーの情報と完全一致させる。パスワードは暗号化されずに平文で記述されるため、見間違いがないか注意する。また、パスワードに特殊文字（’ ” \ $ など）が含まれていると、PHPが正しく解釈できず接続エラーを引き起こすことがある。必要に応じてシングルクォーテーションで囲む、あるいはパスワード自体を英数字のみの強固なものに変更するのも有効な手段だ。

ホスト名（DB_HOST）の指定

DB_HOSTは、WordPressがデータベースサーバーを探しに行く宛先だ。多くの共用サーバーでは localhost で問題ない。しかし、一部のホスティング環境では、データベースサーバーがWebサーバーとは別のマシンで動作しており、専用のホスト名やIPアドレスが割り当てられている。サーバー会社のマニュアルに記載されているホスト名（例: mysql.example.com）を指定する。稀に 127.0.0.1 で接続できるが localhost だとエラーになるケースもあるため、どちらも試す価値がある。

Before（エラー発生時）
define( 'DB_NAME', 'wordpress' ); /* ← 実在しないDB名 */
define( 'DB_PASSWORD', 'mypassword' ); /* ← 誤ったパスワード */
↓
After（修正後）
define( 'DB_NAME', 'user_wp01' ); /* ← 正しいDB名 */
define( 'DB_PASSWORD', 'C0rrect!Pass#' ); /* ← 正しいパスワード */

データベースサーバーが稼働しているか確認する

データベースサーバーが稼働しているか確認する

wp-config.phpの設定が正しいのにエラーが続く場合、問題はデータベースサーバー側にある。まず、利用しているホスティングサービスの管理画面にログインし、MySQLやデータベースのセクションを確認する。

サーバー管理画面からの状況確認

多くのレンタルサーバーでは、cPanelや独自のコントロールパネルからMySQLサーバーの稼働状況や、データベースの一覧、ユーザー管理が行える。対象のデータベースとユーザーが存在し、かつユーザーに適切な権限が付与されているかを確認する。サーバー会社によっては、メンテナンスや障害発生時にステータスページで告知を行っているため、そちらも合わせてチェックする。

phpMyAdminで直接ログインを試みる

サーバーの管理画面からphpMyAdminを起動し、wp-config.phpで指定したのと同じユーザー名とパスワードでログインできるか試す。ログインできればデータベースサーバー自体は稼働しており、認証情報も正しいことになる。ログインに失敗する場合は、パスワードのリセットやユーザーの再作成を検討する。ローカル環境（LocalWPやXAMPPなど）で作業している場合は、MySQLサービスが起動しているか、タスクマネージャーやサービス一覧で確認する。

STEP 1 サーバー管理画面にログインし、MySQLの項目を開く
↓
STEP 2 データベースとユーザーが存在し、リンクされているか確認
↓
STEP 3 phpMyAdminで同じ認証情報を使ってログインできるかテスト
↓
STEP 4 接続できればデータベースは正常、できなければユーザーの再作成を検討

それでも解決しない場合の追加確認項目

それでも解決しない場合の追加確認項目

上記の確認で問題が見つからない場合、より深い部分に原因が潜んでいる。以下の点を順に見ていく。

データベースユーザーの権限を再確認する

MySQLユーザーがデータベースにアクセスするための権限が不足していると、WordPressはテーブルを作成・読み取りできず接続エラーを起こす。phpMyAdminやサーバー管理画面で、該当ユーザーに「ALL PRIVILEGES」が付与されているか確認する。特にデータベースを移行した直後や、手動でユーザーを作成した場合に起こりやすい。

データベースの破損をチェックする

サーバーの突然の停止やディスク障害により、MySQLのテーブルが破損することがある。phpMyAdminで該当データベースを選択し、すべてのテーブルをチェックして「テーブルの修復」を実行する。WordPressが管理画面にアクセスできる状態であれば、wp-config.phpに define('WP_ALLOW_REPAIR', true); を一時的に追記し、http://example.com/wp-admin/maint/repair.php にアクセスして修復する手段もある。修復後は必ずこの行を削除する。

wp-content/db.php ファイルの存在を疑う

一部のキャッシュプラグインやデータベース置き換えプラグインは、/wp-content/db.php というファイルを作成してWordPress標準のデータベース接続処理を上書きする。このファイルが破損していたり、古い設定を保持したままだと、突然データベース接続エラーを引き起こす。FTPでdb.phpを一時的に別名にリネームし、エラーが消えるか確認する。

マルチサイトのwp-config.php設定を見直す

WordPressのマルチサイト（サブディレクトリ型やサブドメイン型）を運用している場合、wp-config.phpにマルチサイト固有の定義定数が正しく記述されている必要がある。DOMAIN_CURRENT_SITE や SUBDOMAIN_INSTALL の値が、実際のURL構成やサーバー設定と矛盾していると、内部的なデータベースクエリが失敗して接続エラーに見えることがある。マルチサイト化した直後や、ドメインを変更した後にエラーが起きた場合は、この設定を疑う。

よくある質問

wp-config.phpの修正後にエラーが変わらないのはなぜか

修正内容を保存しても、サーバーのキャッシュやCDN（コンテンツデリバリネットワーク / 配信網）が古いエラー画面を表示し続けることがある。スーパーリロード（Ctrl+F5やCommand+Shift+R）を試し、それでも変わらなければキャッシュ系プラグインを一時停止するか、サーバー側のキャッシュを管理画面からクリアする。

パスワードやユーザー名は合っているのに接続できない

MySQLユーザーが特定のIPアドレスからの接続に制限されている可能性がある。レンタルサーバーでは「localhost」専用のユーザーが作成されるが、外部から接続するように変更してしまうとWebサーバーからのローカル接続が拒否される。phpMyAdminのユーザーアカウント管理で、ホスト名が「localhost」または「127.0.0.1」になっているか確認する。

レンタルサーバーのサポートに連絡するタイミングはいつか

自身でwp-config.phpの設定確認、phpMyAdminからのログインテスト、管理画面からのデータベース稼働状況確認を行っても解決しない場合は、サーバー側の障害や特殊な構成が原因である可能性が高い。サーバー会社のサポートに「WordPressのデータベース接続確立エラーが出ている」「MySQLに接続できない」と具体的に伝えて調査を依頼する。その際、エラーメッセージのスクリーンショットがあるとスムーズだ。

ローカル環境で同じエラーが出る場合の対処法は

LocalWPやXAMPP、MAMPなどのローカル開発環境では、MySQL（またはMariaDB）のサービスが停止していることが原因の大半を占める。各ツールの管理画面で「Start」ボタンを押してサービスを起動し直すか、OSのシステムトレイから再起動する。ポートの競合（特に3306番）が原因で起動に失敗しているケースもあるため、エラーログを確認する。

データベースの修復をしてもすぐにエラーが再発する

テーブルの修復が一時しのぎで終わる場合、ストレージのディスク容量不足や、ハードウェア的な障害が進行している可能性を疑う。サーバーのディスク使用率を確認し、不要なバックアップやログを整理する。根本的にはホスティングサービスのプラン見直しや、サーバー移転を検討する必要がある。

この記事のポイント

  • データベース接続エラーの原因は「認証情報の不一致」と「サーバー停止」に絞られる
  • wp-config.phpのDB_NAME・DB_USER・DB_PASSWORD・DB_HOSTを最初に確認する
  • phpMyAdminで同じ認証情報を用いて直接ログインし、サーバー稼働をテストする
  • 解決しない場合はユーザー権限・DB破損・db.phpの競合・マルチサイト設定を順に疑う
  • サーバー側の障害が疑われる場合は、ログやディスク容量を確認しサポートに連絡する
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WooCommerce商品ページでjQueryが未定義になるエラーはプラグインのasync読み込みが原因
2026年8月11日 0

WooCommerce商品ページでjQueryが未定義になるエラーはプラグインのasync読み込みが原因

jQueryに依存したフロントエンド向けスクリプトが async 属性付きで読み込まれると、実行順序が崩れて「Uncaught ReferenceError: jQuery is not defined」が発生する。商品ページの動作不良やバリエーション選択UIの不具合につながるこの問題は、プラグイン側で強制された async 指定と prefetch ヒントを外せば解決する。

なぜ商品ページで「jQuery is not defined」が起きるのか

なぜ商品ページで「jQuery is not defined」が起きるのか

WooCommerce サイトで「重大なエラーが発生しました」ではなく、ブラウザのコンソールに jQuery の参照エラーが出てページの一部が動かなくなるケースがある。このエラーの多くは、JavaScript の依存関係が守られていないことに起因する。

WordPress 本体や多くのプラグインは、JavaScript を安全に読み込むために wp_register_script や wp_enqueue_script で依存関係（例：array('jquery')）を宣言している。しかし、一部のプラグインが表示速度を意識してか、最終的に出力される <script> タグに async 属性を強制的に付与してしまうことがある。

async 属性が付いたスクリプトは、ダウンロードが完了次第すぐに実行される。もしその時点で jQuery 本体（jquery-core-js）の読み込みが終わっていなければ、jQuery is not defined の参照エラーとなる。この実行順序の逆転は、キャッシュや最適化プラグインが介在するとさらに発生しやすくなる。

加えて、問題のプラグインが <link rel="prefetch"> を head 内に自ら出力している場合、ブラウザはそのスクリプトを早期取得しようとし、実行タイミングの競合がさらに深刻化する。

async 読み込みを強制している箇所を特定する手順

async 読み込みを強制している箇所を特定する手順

まず、エラーがどのスクリプトで起きているのかを絞り込む。WooCommerce 商品ページで特定の動作（数量変更、バリエーション切替など）が効かなくなったら、ブラウザの開発者ツールを開く。

STEP 1 Chrome なら F12 キーで「コンソール」タブを開く
↓
STEP 2 赤いエラー行「Uncaught ReferenceError: jQuery is not defined」を確認し、該当のスクリプトファイル名を特定する
↓
STEP 3 「ネットワーク」タブを開き、該当 JS が jQuery よりも先に取得・実行されていないか読み込み順を調べる
↓
STEP 4 HTML ソース表示で該当スクリプトのタグに async 属性が付与されていないか、prefetch の link タグが head 内に存在しないかを確認する

調査の過程で、プラグインフォルダ（多くは /wp-content/plugins/プラグイン名/）内の enqueue.php やメインのプラグインファイルを開き、以下のような処理が入っていないか検索する。

  • str_replace( ' src', ' async src', $tag ) のように script タグに async を差し込むコード
  • wp_register_script で jQuery 依存を宣言しているにもかかわらず、上記で async を上書きしている箇所
  • echo '<link rel="prefetch" href="' ... .js'>' の形でプリフェッチヒントを出力している処理

これらのコードが確認できれば、プラグインが意図せず実行順序を壊している原因と断定できる。

プラグインのコードを修正して async を外す方法

問題を解消するには、async の強制付与と prefetch の出力を取りやめる必要がある。理想はプラグイン開発者が修正版をリリースすることだが、すぐに動かす必要がある場合は以下のようにコードを直接修正する。修正前に必ずバックアップを取り、子テーマや独自プラグインによる上書きが可能ならそちらを優先する。

修正前後の script タグ比較
Before（エラー状態）
<script async src=’…/custom.js’></script>
async 属性が付与されている
↓
After（修正後）
<script src=’…/custom.js’></script>
async が外れ、依存関係が守られる
■ エラー状態（async あり）　 ■ 修正後（async なし）

実際の修正は、プラグインファイルの該当行をコメントアウトまたは削除することで行う。

async 強制付与の無効化

includes/enqueue.php のようなスクリプト登録ファイルを開き、str_replace で async を割り込ませている箇所を探す。典型的には以下のようなコードだ。

if ( 'wcmmq-custom-script' === $handle ) {
    return str_replace( ' src', ' async src', $tag );
}

この部分全体をコメントアウトするか、条件分岐を削除して return $tag; だけを残す。これで async 属性の付与が止まり、WordPress が宣言した依存関係通りに jQuery の後で実行されるようになる。

prefetch リンクの除去

次にメインのプラグインファイル（例：plugin-name.php）を開き、wp_head 等にフックして <link rel="prefetch"> を出力している箇所を探す。

echo '<link rel="prefetch" href="' . esc_url(WC_MMQ_BASE_URL . 'assets/js/custom.js') . '">' . "\n";

この行をコメントアウトする。prefetch ヒントがなくなると、ブラウザが該当スクリプトを過度に早期取得しようとする圧力が減り、実行タイミングの競合リスクが下がる。

functions.php で上書きする方法

プラグイン本体を直接触りたくない場合は、テーマの functions.php で該当スクリプトをいったん解除し、async なしで再登録する方法もある。

function fix_custom_js_async() {
    wp_deregister_script('wcmmq-custom-script');
    wp_register_script('wcmmq-custom-script', WC_MMQ_BASE_URL . 'assets/js/custom.js', array('jquery'), $js_version, true);
    wp_enqueue_script('wcmmq-custom-script');
}
add_action('wp_enqueue_scripts', 'fix_custom_js_async', 99);

この方法でも async の強制を回避できるが、prefetch の出力は別途 remove_action で除去する必要がある。確実なのはプラグインの該当コードをコメントアウトする方針だ。

修正後も注意すべきキャッシュと最適化プラグインの影響

コード修正後にサイトを確認してもまだエラーが出る場合、キャッシュや最適化プラグインが古いスクリプトを配信し続けている可能性がある。

  • 使用しているキャッシュプラグイン（W3 Total Cache、WP Super Cache など）のキャッシュを全削除する
  • 最適化・高速化プラグイン（NitroPack、WP Rocket など）のキャッシュもクリアする
  • サーバー側で CDN を利用している場合は、CDN のキャッシュもパージする
  • ブラウザのキャッシュをクリアするか、シークレットウィンドウで動作確認する

最適化プラグインの中には、JavaScript の結合や遅延読み込み（defer）を独自に行うものもある。async を外したあとも問題が続くなら、最適化機能の「JavaScript の遅延読み込み」や「スクリプトの結合」を一時的に無効化し、問題のスクリプトが正しく読み込まれるか切り分けを進める。

よくある質問

async と defer の違いは何か

async はスクリプトのダウンロードが完了次第すぐに実行され、他のスクリプトとの実行順序が保証されない。defer は HTML の解析が完了したあとに、書かれた順序で実行される。jQuery 依存スクリプトに async を使うと実行順序が守られないため、今回のようなエラーを引き起こす。

プラグイン本体を修正するとアップデートで上書きされないか

プラグインを直接修正した場合、そのプラグインがアップデートされると修正内容は上書きされて失われる。長期的には、プラグイン開発者にバグ報告を行い、公式の修正版がリリースされるのを待つのが理想だ。それまでの間はアップデートを見送るか、修正を再適用する必要がある。

async を外しても「jQuery is not defined」が消えないのはなぜか

原因が複数存在するケースもある。ほかのプラグインやテーマが jQuery を正しく依存関係に含めずにスクリプトを読み込んでいる可能性や、jQuery そのものが何らかの理由で読み込まれていないケースが考えられる。コンソールで jQuery が本当に未定義かどうかを確認し、ネットワークタブで jQuery 本体の読み込み状況を再調査する。

子テーマで対策する利点は何か

テーマのアップデートに影響されず、修正内容を保持できる点が最大の利点だ。ただし、スクリプトの登録解除と再登録では prefetch の出力まで止められないため、完全な対策にはならないこともある。状況に応じて最適な方法を選ぶ。

この記事のポイント

  • jQuery 依存スクリプトに async 属性が付くと実行順序が崩れ「jQuery is not defined」が発生する
  • プラグインの enqueue.php やメインファイルで async 付与・prefetch 出力が強制されていないか確認する
  • 該当コードをコメントアウトし async を外せば、依存関係が守られエラーが解消する
  • 修正後はキャッシュプラグインや CDN のキャッシュをクリアして検証する
  • プラグイン本体の修正はアップデートで上書きされるため、公式修正を待つか都度再適用が必要
佐々木 太陽
, , , , ,
お悩み・トラブル解決
Rank Math有効時にElementorパネルがフリーズする原因と復旧手順
2026年8月11日 0

Rank Math有効時にElementorパネルがフリーズする原因と復旧手順

Elementorのウィジェットパネルが突然操作不能になり、半透明のまま固まってしまう。この症状はRank Math SEOが同時に有効になっている環境で特に発生しやすく、複数のプラグインが読み込むスクリプトの衝突が原因だ。キャッシュのクリアと一部モジュールの無効化、またはバージョン管理で大半は改善する。

なぜRank Mathを有効にするとElementorパネルが固まるのか

なぜRank Mathを有効にするとElementorパネルが固まるのか

この問題の根本には、WordPress管理画面で複数のプラグインがそれぞれJavaScriptやCSSを読み込む「競合」がある。Elementor Editorはページ上のあらゆる要素をドラッグアンドドロップで編集できる高度なインターフェースだが、そのぶん大量のAjax通信とDOM操作を行う。一方Rank Mathは、コンテンツAIやインスタントインデックス、スキーママークアップなど多機能なSEOツールを提供しており、画面内で動作する独自のスクリプトを多数読み込む。

両者が同時にロードされると、メモリ上で予期せぬエラーが発生したり、読み込み順序の不整合からElementorのウィジェットパネルがゾンビ化（グレーアウト状態）することがある。とくに最近のバージョンアップで機能が増えた直後や、サーバー側のPHPメモリ割り当てがギリギリの場合に表面化しやすい。

まずは本当に競合かどうかを確実に特定する

まずは本当に競合かどうかを確実に特定する

似たような症状は他のプラグインでも起こりうる。まずはRank Mathを含む全プラグインを停止し、Elementorだけの状態で正常に動作するかを確認する手順が切り分けの基本だ。

プラグイン停止モードを使った最小構成テスト

WordPressには「トラブルシューティングモード」を提供するプラグインがあるが、手動で行う方法も確実だ。管理画面の「プラグイン」→「インストール済みプラグイン」から、Rank Mathを除くすべてのプラグインを一時的に無効化する。その後、標準テーマ（Twenty Twenty-Fiveなど）に切り替えたうえで、Elementor Editorを開いてパネルが動くかテストする。

ここで問題が解消すれば、次にRank Mathだけを有効化し、再度パネルの挙動を確認する。Rank Mathを有効化した瞬間にフリーズが再現するなら、このプラグインがトリガーであると断定できる。

ブラウザコンソールでエラーの詳細を確認する

Chromeの場合、F12キーでデベロッパーツールを開き「Console」タブを見る。パネルが固まった直後には、赤字のJavaScriptエラーがいくつか記録されている。とくにUncaught TypeErrorやload-scripts.phpで始まるエントリがあれば、読み込み競合の有力な手がかりになる。エラー文言をメモしておくと、Rank Mathのサポートに問い合わせる際の情報になる。

Elementorパネルを復旧させる現実的な4ステップ

Elementorパネルを復旧させる現実的な4ステップ

原因が特定できたら、以下に示す順に作業することで元の状態に戻せる。いきなりプラグインの再インストールをする前に、まずはキャッシュとモジュールの調整で解決できる場合が多い。

STEP 1 Rank Mathをいったん無効化してパネルを復旧
↓
STEP 2 WordPress全体のキャッシュとブラウザキャッシュをクリア
↓
STEP 3 Rank Math内の不要なモジュールをオフにする
↓
STEP 4 Rank MathとElementorを最新版に揃えて再び有効化

上記は概念的なフローであり、実際の作業では各ステップ後に必ずEditor画面をリロードして状態をチェックする。

STEP 1 Rank Mathを無効化して即座に確認する

緊急時に最も手早い対処はRank Mathの一時停止だ。「プラグイン」一覧からRank Mathを「無効化」し、Elementor Editorを開き直す。パネルが正常に戻ったら、問題がRank Math由来であることが確定する。この状態で作業は継続できるため、更新が急ぎの場合はSTEP 1だけでその場をしのげる。

STEP 2 キャッシュをあらゆる層で削除する

無効化だけでは根本解決にならない。Rank Mathを再び有効化する前に、キャッシュを丁寧に消す。WordPress側ではキャッシュ系プラグイン（W3 Total CacheやWP Super Cacheなど）を使っているなら管理画面から「全キャッシュ削除」を実行する。サーバー側でNginx FastCGI CacheやVarnishが動いている場合はホスティングの管理パネルからも同様に行う。最後にブラウザのキャッシュとCookieも削除し、シークレットウィンドウでEditorにアクセスすると、より確実に変化を確認できる。

STEP 3 Rank Mathのモジュールを調整する

Rank Mathには多数の拡張モジュールが用意されており、その組み合わせによってはElementorのスクリプトと干渉することがある。Rank Mathの管理メニュー「Rank Math」→「ダッシュボード」→「モジュール」へ進み、以下の機能をひとまずオフにしてみる。

  • コンテンツAI
  • インスタントインデックス
  • SEO分析（管理画面で動作するウィジェット）

これらの機能は編集画面に独自のメタボックスや通知を追加するため、競合の原因になりやすい。変更を保存し、再度Elementor Editorでパネルの挙動をチェックする。症状が消えたら、ひとつずつモジュールをオンにして犯人を特定することもできる。

STEP 4 両プラグインを最新状態に保つ

WordPress本体、Elementor、Rank Mathのすべてが最新版であれば、開発者同士が互換性を確認した上でリリースしている可能性が高い。バージョンに偏りがあると、片方だけが想定する関数が欠落しているケースがある。アップデート後は必ずSTEP 2のキャッシュクリアを再度行う。

再発を防ぐために日頃からできること

再発を防ぐために日頃からできること

大規模な編集を始める前に、Rank Mathのモジュール状態を簡易チェックリストにしておくと、いざという時のダウンタイムを大幅に減らせる。また、PHPのメモリリミットが最低でも256MB以上確保されているかを確認するのも効果的だ。

万一どうしても競合が解消しない場合は、Rank MathをElementor編集時だけ一時的に無効化する運用でも実務上は問題になりにくい。ただし、無効化すると編集中のSEOスコアが変動する可能性があるため、プレビュー公開前に再度有効化してSEO設定を確認する習慣をつけておく。

よくある質問

他のSEOプラグインでも同じことが起きますか

Yoast SEOやAll in One SEO Packでも類似の競合は報告されているが、発生条件や修正パッチはプラグインごとに異なる。まずは同じ手順で特定し、問題が発生したプラグインに合わせた対処を行うとよい。

Rank Mathを無効化するとSEO順位に影響しますか

短時間（数分〜数十分）の無効化であれば、検索順位への直接的な影響はまずない。ただし、その間にクローラーがサイトを訪れると、メタタグが一時的に変化する可能性があるため、公開状態の確認は忘れずに行う。

キャッシュをすべて消さずに直す方法はありますか

管理画面の問題はサーバーレベルのページキャッシュと直接関係しないこともあるが、ブラウザ上に競合する古いスクリプトが残っていると再発しやすい。最低限ブラウザキャッシュだけは削除し、あわせて管理画面用のバックグラウンド処理キャッシュがないか確認する方が確実だ。

プレビュー画面だけ固まる場合はどうすればいいですか

プレビュー表示は管理画面とフロントエンドの両方のスクリプトが混在しやすい。まずはパーマリンク設定を再保存し、.htaccessをリフレッシュする。それでも治らない場合は、テーマのfunctions.phpで読み込みを遅延させるカスタムコードを追加する選択肢もある。

競合が直ったのにしばらくすると再発します

キャッシュ系プラグインやCDNが古いファイルを配信し続けている可能性が高い。Originサーバー上のキャッシュも含めて一掃し、変更後にCDNのパージが自動でかかる設定になっているか見直すことを推奨する。

この記事のポイント

  • Rank Mathの有効化直後にElementorパネルが固まるのはスクリプト競合が原因
  • 最小構成テストで競合相手を特定するのが最短の道
  • 即効復旧にはRank Mathの一時無効化と全キャッシュ削除が有効
  • 不要なSEOモジュールをオフにすることで競合を回避できる
  • バージョンの統一と定期的なキャッシュクリアで再発を防げる
佐々木 太陽
, , , ,
お悩み・トラブル解決
Mail Mintのワンクリック解除リンクでデータベースエラーが出る時の対処
2026年8月10日 0

Mail Mintのワンクリック解除リンクでデータベースエラーが出る時の対処

Mail Mint で配信したメールのワンクリック解除リンクをクリックすると、WordPress のデータベースエラー「Column ‘mint_email_id’ cannot be null」がログに出力される問題は、プラグインのバージョンが古いことが主な原因だ。最新版（バージョン 1.30.0 以降）にアップデートすることで、このエラーは発生しなくなる。

なぜワンクリック解除でデータベースエラーが発生するのか

なぜワンクリック解除でデータベースエラーが発生するのか

Mail Mint のワンクリック解除機能は、メール内のリンクに埋め込まれたハッシュ値から、どの配信（ブロードキャスト）からの解除なのかを特定する。しかし、古いバージョン（1.24.4 以下など）では、ハッシュ値が無効な場合や、該当する配信が存在しない場合に、ブロードキャスト ID を取得する関数が null を返していた。

その結果、購読解除ステータスの更新自体は正常に行われるものの、その後にブロードキャストごとのメタ情報（is_unsubscribe）を記録する際、データベースの mint_email_id カラムに null が INSERT されようとして、WordPress のデータベースエラーが発生していた。

このエラーは、購読解除の処理自体を妨げるものではなく、あくまでログに記録されるだけだが、大量に発生するとサーバーのエラーログが肥大化するなどの影響が出る。

Mail Mint を最新版にアップデートしてエラーを解消する

Mail Mint を最新版にアップデートしてエラーを解消する

開発元はこの問題を認識し、バージョン 1.30.0 で修正をリリースしている。そのため、まずは管理画面からプラグインを最新版に更新しよう。

STEP 1 管理画面の「プラグイン」→「インストール済みプラグイン」を開く
↓
STEP 2 Mail Mint の「更新」リンクが表示されていればクリック
↓
STEP 3 バージョン 1.30.0 以上に更新されていることを確認する

プラグインの自動更新が有効な場合はすでに適用されている可能性もあるが、念のためバージョン表示を確認しておこう。

更新後にエラーが止まったか確認する

更新が完了したら、メールマーケティングのワンクリック解除リンクを実際にテストするか、サーバーのエラーログに同じメッセージが出なくなったことを確認する。WordPress のデバッグモードを有効にしている場合は wp-content/debug.log もチェックする。

Before WordPressデータベースエラー Column ‘mint_email_id’ cannot be null がログに記録される
↓
After エラーは発生せず、静かに購読解除メタが保存される
■ エラー状態　■ 修正後

どうしてもアップデートできない場合の一時的な対処

どうしてもアップデートできない場合の一時的な対処

何らかの理由でプラグインをすぐに更新できない場合、以下のコード修正を適用することでエラーを回避できる。ただし、この修正はプラグインの本体ファイルを直接変更するため、次回のアップデートで上書きされる。あくまで緊急措置として理解しておこう。

修正するファイルは app/Internal/Optin/UnsubscribeConfirmation.php だ。process_one_click_confirmation メソッド内の、$broadcast_email_id を取得した直後の処理を対象にする。

修正前（エラーが発生するコード）

$broadcast_email_id = EmailModel::get_broadcast_email_by_hash( $hash );
// ... 中略 ...
EmailModel::insert_or_update_email_meta( 'is_unsubscribe', 1, $broadcast_email_id );

修正後

$broadcast_email_id = EmailModel::get_broadcast_email_by_hash( $hash );
// ... 中略 ...
if ( ! empty( $broadcast_email_id ) ) {
    EmailModel::insert_or_update_email_meta( 'is_unsubscribe', 1, $broadcast_email_id );
}

このガードを追加することで、ハッシュが無効でブロードキャスト ID が null のままでも、データベースエラーが発生しなくなる。購読解除ステータスの更新は問題なく行われるため、最低限の動作は保たれる。

データベースエラーが解消したか確認する方法

データベースエラーが解消したか確認する方法

エラーログを監視して、同じメッセージが出力されなくなったかを確認する。WordPress のデバッグモードが有効な場合は、wp-content/debug.log を直接確認するか、管理画面からデバッグログを表示するプラグインを使うと手軽だ。サーバーのエラーログ（エラーログファイルや php-fpm のログ）にも同様のエントリがないかチェックする。

また、テスト用のメールを送信し、そのワンクリック解除リンクを実際にクリックして、エラーログに新たな記録が発生しないことを確かめるのが確実だ。

よくある質問

アップデートしてもエラーが続く場合は？

キャッシュ系プラグインやサーバーキャッシュが古いバージョンのファイルを保持しているケースがある。全キャッシュをクリアし、ブラウザのキャッシュも削除してから再度確認する。また、他のプラグインとの競合も考えられるため、標準テーマに切り替え、Mail Mint 以外のプラグインを一時的に無効化して切り分けを試みる。

一度発生したエラーログは削除したほうがよい？

特に削除する必要はないが、ログが肥大化してディスク容量を圧迫している場合は、ファイルを空にしたり、ログローテーションを設定したりするのが現実的だ。WordPress の debug.log は管理画面から直接内容を確認できるツールを使うのも手だ。

購読解除のメタ情報が記録されないとどんな問題が起きる？

ブロードキャスト単位での解除率や効果測定の集計が正しく取れなくなる可能性がある。ただし、購読解除そのものは正常に処理されているため、配信停止自体は問題なく行われている。レポートの精度を気にする場合は、エラー解消後に過去分のメタ情報を補完することを検討してもよい。

この記事のポイント

  • Mail Mint のワンクリック解除リンクでデータベースエラーが発生するのはプラグインの古いバグが原因
  • バージョン 1.30.0 以上への更新で根本的に解決する
  • 更新できない場合は null チェックを追加する一時パッチで回避可能
  • エラーは購読解除の処理自体を止めるものではないが、ログの肥大化に注意
  • 修正後はテストメールで解除リンクをクリックし、エラーログを確認する
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
Speedixでプロファイリング用カスタムページを追加できない時の対処法
2026年8月9日 0

Speedixでプロファイリング用カスタムページを追加できない時の対処法

Speedixのプロファイリング設定で3つ目以降のページを追加するには、設定画面上部の検索フィールドに測定したいページのタイトルやスラッグを入力し、表示される候補から選択する。バージョン2.1.7以降ではこの操作が明確化され、追加ボタン代わりに機能する。

なぜ設定画面に「追加」ボタンがないのか

なぜ設定画面に「追加」ボタンがないのか

SpeedixはWordPressサイトのパフォーマンスプロファイリングに特化したプラグインで、任意のページ読み込み時間やクエリを詳細に計測できる。設定画面（「ツール」→「Speedix」）を開くと、デフォルトでホームページと1つの主要ページがプロファイリング対象として登録されている。そこへ新たなページを増やしたい場合、画面内に明示的な「追加」ボタンや「新規ページ」リンクは存在しない。このUI設計が混乱を招きやすい。

実際の追加手段は、画面上部にある検索フィールドだ。ここに任意の文字列を打ち込むと、既存の公開ページ・投稿・固定ページの中から、タイトルやURLスラッグに一致するものがオートコンプリートで候補表示される。目的のページをクリックするだけで、即座にプロファイリングリストへ追加される仕組みになっている。

バージョン2.1.6以前はこの検索フィールドの役割が説明されておらず、「どうやって追加するのか」という問い合わせが多発していた。最新バージョンへアップデートすると、入力欄のプレースホルダー文言や補助テキストが改善され、直感的に理解しやすくなっている。

STEP 1 「ツール」→「Speedix」を開き、画面上部の検索フィールドを確認する
↓
STEP 2 測定したいページのタイトルやスラッグの一部を入力する
↓
STEP 3 オートコンプリートの候補一覧から該当ページをクリックする
↓
STEP 4 下のプロファイリングリストに追加されたことを確認する

プロファイリング対象のページを実際に追加する手順

プロファイリング対象のページを実際に追加する手順

設定画面を開き現在の登録状況を確認する

WordPress管理画面の左メニューから「ツール」を選び、「Speedix」をクリックする。するとプロファイリングの設定ページが表示され、現在登録されているページ一覧が上部にリスト表示される。初期状態ではホームページ（フロントページ）と、直近でアクセスの多いページなどが2件ほど表示されているはずだ。

この画面で、リストのすぐ上に配置されているのが追加用の検索フィールドである。テキスト入力欄と虫眼鏡アイコンが表示されているので、ここが操作の起点となる。

検索フィールドにページ情報を入力する

フィールドに、追加したい固定ページや投稿のタイトルをそのまま入力してみる。たとえば「会社概要」や「キャンペーン特設ページ」といった日本語タイトルで問題ない。スラッグ（URLの最後の部分）がわかっているなら、「about」「campaign」のように英数字で絞り込んでもよい。

何文字か打ち込むと、その文字列を含む公開済みのページ群が検索され、フィールドの下にドロップダウン形式で候補が表示される。このオートコンプリート機能は、投稿タイプ（固定ページ・投稿）を問わず、公開ステータスが「公開」になっているものだけが対象だ。

候補をクリックして追加する

目的のページが候補に出てきたら、その行をクリックする。クリックした瞬間、画面下部のプロファイリングリストに新しい行が追加される。追加と同時にバックグラウンドで最初の計測が走るため、数秒後に読み込み時間やクエリ数などのデータが表示される。

検索候補に出てこない場合は、そのページが本当に公開状態かを確認する。非公開や下書きのページは計測対象にできない。また、カスタム投稿タイプで作成されたページ（例：WooCommerceの商品ページ）も、テーマやプラグインが適切に公開ステータスを返している限りは候補に表示される。

追加したプロファイリングページを管理・削除する

追加したプロファイリングページを管理・削除する

登録したページが不要になったり、計測を停止したい場合は、リスト右端に表示されるゴミ箱アイコンまたは「削除」リンクをクリックする。確認ダイアログは出ないものの、即座にリストから消え、それ以降の計測は行われなくなる。

削除しても過去の計測データはデータベースに蓄積されたままになる。完全に履歴を消去したい場合は、Speedixが提供する「データリセット」機能を使うか、プラグインを一度無効化して再有効化する方法もある。ただし再有効化するとすべてのカスタムページ設定が初期化されるため、必要なページは再度追加し直す必要がある。

よくある質問

検索しても目的のページが候補に出てこないのはなぜか

公開状態でない（下書き・非公開・パスワード保護）ページは候補に表示されない。また、何らかのキャッシュプラグインがREST APIの応答を妨げていると、検索機能自体が動作しない場合がある。その場合はキャッシュを一時的にクリアするか、プラグインの競合を切り分けるために他のプラグインを停止してから試すとよい。

一度に登録できるプロファイリングページ数の上限はあるか

Speedixに明示的な上限は設けられていない。ただし計測対象が増えるほどバックグラウンド処理の負荷が上がり、サイト全体のパフォーマンスに影響を与える可能性がある。数ページから十数ページ程度に絞って運用するのが現実的だ。

追加したページの計測頻度は変更できるか

デフォルトでは1時間に1回程度の間隔で自動計測される。この頻度は設定画面の「計測間隔」項目から変更可能で、最短15分から24時間まで選択できる。ただしあまり短い間隔にするとサーバーリソースを消費するため、必要なページだけ短く設定するといった使い分けが推奨される。

バージョン2.1.6以前の古いSpeedixを使っている場合はどうすればよいか

まずはプラグインを最新版（2.1.7以上）に更新する。検索フィールドの補足説明やプレースホルダーが改善され、操作方法が一目でわかるようになる。更新が何らかの理由でできない場合は、画面上部のテキスト入力欄が追加機能を兼ねていると理解して、前述の手順でページを追加すれば問題ない。

この記事のポイント

  • Speedixのプロファイリングページ追加は検索フィールドから行う
  • ページタイトルやスラッグの一部を入力すると候補が表示される
  • 候補をクリックするだけで即座に追加され計測が始まる
  • 公開状態のページのみが検索対象なので下書きなどは追加不可
  • 最新バージョンではUIが改善され操作が直感的になった
佐々木 太陽
, , , , ,
お悩み・トラブル解決
« 前ページへ 次ページへ »

メニュー

会社概要
事業紹介
社名の由来
JVパートナー募集

ウェブ開発 最新ニュース

B to B のご提案

事業譲渡（M&A）
卸売販売
アフィリエイト

その他

関連サイト
特定商取引法に基づく表示
プライバシーポリシー
お問い合わせ

Copyright 株式会社A&Gウェブ - ライバルには、ひみつ。 All rights reserved.