【THE THOR】また出たAMPエラーを解消！『属性「decoding」はタグ「amp-img」で使用できません』

2022年12月16日2026年4月6日

今回はWordPress6.1に更新した際に生じるAMPエラー『属性「decoding」はタグ「amp-img」で使用できません』の解決方法です。またしても、WordPressの更新で追加された機能がエラーの原因でした。実際にエラーをゼロに解消したかんたんな方法を書いています。

AMPの意味やTHE THORでの設定方法、前回WordPress5.9への更新時に生じたエラーについては、以下の記事で解説しています。

【THE THOR】AMP設定で起きたサーチコンソールのAMPエラーと原因今回は、THE THORのAMP機能設定で生じたGoogleサーチコンソールのAMPエラーについてです。実際に通知されたエラーの内容と原因を解説しています。その前に、AMPとは何か…

『属性「decoding」はタグ「amp-img」で使用できません』

WordPress6.1更新後にサーチコンソールでAMPエラーが検出されました。

1件の重大な問題で、64のURLが検出されています。

問題の種類は「許可されていない属性または属性値がHTMLタグにあります」です。

画像のようにエラーがなくなった対処方法をこの記事に書いています。

問題の検出

更新2日後に問題検出についてのメールが届いていました。「AMPの問題を修正する」をクリックすると、サーチコンソールの該当ページに遷移します。対象となっているURLの一つをクリックすると、問題の詳細が表示されます。

「属性「decoding」タグは「amp-img」で使用できません」となっており、検出された64のエラーすべてに共通でした。

AMPエラーの原因

WordPress6.1に更新すると、画像の遅延読み込みのために自動的にdecording=”async”という属性を付与するからです。

前回WordPress5.9のAMPエラーでは、サムネイル画像にだけloading=”lazy”が出力されていました。今回は記事内のすべての画像にdecoding=”async”が出力されるようになりました。そのため、AMPでは「許可されていない属性または属性値が HMTL タグにあります」ということでエラーが出ます。画像すべてが関係するためエラー数も多くなるというわけです。

エラーの解消方法

WordPressのダッシュボードから、外観＞テーマファイルエディター へ進み、functions.phpにコピペしたコードを追記するだけです。

WordPress5.9への更新で生じたAMPエラー時に追記したコード（以下の関連記事参照）は削除して、新しいコードをコピペしました。

【THE THOR】AMPエラーを解決！実際にエラーが0になった修正方法を解説 THE THORでAMP設定をした時、Googleサーチコンソールで通知されたAMPエラーについて、実際にエラーがゼロになった修正方法をご紹介します。今回通知されたエラーは、「…

編集前に以下の点を確認してください。

編集するテーマ：THE THOR CHILD
テーマファイル：テーマのための関数（functions.php）

※functions.phpを編集する前にバックアップを取るようにし、編集は自己責任で行ってください。

追記するコード

以下の2種類のコードをコピペします。AMPページだけ遅延読み込みを無効化する設定になります。

今回も以下の記事が参考になりました。ありがとうございました。

参考サイト

コード1

function gnr_tail_pattern_matched($target, $pattern) {
if (empty($target) && empty($pattern)) {
return true;
} else if (empty($target)) {
return false;
} else if (empty($pattern)) {
return false;
}
$s_end = strlen($target);
$s_len = strlen($pattern);
$offset = $s_end - $s_len;
if ($offset < 0) {
return false;
}
$pos = strpos($target, $pattern, $offset);
return $pos === $offset;
}
////AMPページか否か判定する
function gnr_is_amp() {
if (function_exists('is_amp') && is_amp()) {
return true;
} else if (function_exists('is_amp_endpoint') && is_amp_endpoint()) {
return true;
} else if (function_exists('ampforwp_is_amp_endpoint') && ampforwp_is_amp_endpoint()) {
return true;
} else if (@$_GET['amp'] === '1') {
return true;
} else if (@$_GET['type'] === 'AMP') {
return true;
}
$uri = gnr_get_uri_full();
return gnr_is_amp_pattern($uri);
}
function gnr_is_amp_pattern($uri) {
if (gnr_tail_pattern_matched($uri, '/amp')) return true;
if (gnr_tail_pattern_matched($uri, '/amp/')) return true;
if (gnr_tail_pattern_matched($uri, '?amp=1')) return true;
if (gnr_tail_pattern_matched($uri, 'type=AMP')) return true;
return false;
}
function gnr_get_uri_full() {
return (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off' ? 'https' : 'http')
. '://'
. $_SERVER['SERVER_NAME']
. $_SERVER['REQUEST_URI'];
}
function gnr_remove_amp_uri_part($uri, $pattern) {
$s_end = strlen($uri);
$s_len = strlen($pattern);
$offset = $s_end - $s_len;
if ($offset < 0) {
return $uri;
}
$pos = strpos($uri, $pattern, $offset);
if ($pos === $offset) {
return substr($uri, 0, $pos);
}
return $uri;
}
function gnr_remove_amp_pattern($uri) {
$uri = gnr_remove_amp_uri_part($uri, '/amp');
$uri = gnr_remove_amp_uri_part($uri, '/amp/');
$uri = gnr_remove_amp_uri_part($uri, '?amp=1');
$uri = gnr_remove_amp_uri_part($uri, 'type=AMP');
return $uri;
}
function gnr_get_amp_pattern($uri) {
$ret = '/amp'; if (gnr_tail_pattern_matched($uri, $ret)) return $ret;
$ret = '/amp/'; if (gnr_tail_pattern_matched($uri, $ret)) return $ret;
$ret = '/?amp=1'; if (gnr_tail_pattern_matched($uri, $ret)) return $ret;
$ret = 'type=AMP'; if (gnr_tail_pattern_matched($uri, $ret)) return $ret;
}

コード2

function gnr_stop_lazyloading_when_amp() {
return !gnr_is_amp();
}
add_filter('wp_lazy_loading_enabled', 'gnr_stop_lazyloading_when_amp');
function gnr_delete_amp_lazyload($html_src) {
if(!gnr_is_amp()) {
return $html_src;
}
$html_src = preg_replace('#loading="lazy"|decoding="async"#', '', $html_src);
return $html_src;
}
add_filter('post_thumbnail_html', 'gnr_delete_amp_lazyload', 9999);
add_filter('the_content', 'gnr_delete_amp_lazyload', 9999);

追記後、左下部にある「ファイルを更新」を忘れないようにしてください。

エラー修正の検証をする

サーチコンソールで「修正を検証」

サーチコンソールのAMPページで、「修正を検証」をクリックします。

「初期検証中」となります。

問題なければ「検証：開始」と表示され、「開始日」を確認できます。すぐに検証が開始されない時もあるようです。少し時間をおいてからリトライしてみてください。

検証の結果

2日後には、検証の詳細ページで「修正を確認しました」と表示されていました。画像の通り、「合格」は2ページだけで、他の60ページは「保留」になっています。

「保留」の部分をクリックすると、該当するページのURLが表示されます。

「URL検査」でリクエストしてみる

サーチコンソールのURL検査で、「保留」になっているURLを一つずつ検査し、ページ修正によるインデックス再登録をリクエストしてみました。早めに修正の検証をしてくれるかもしれないと思ったからです。実際、リクエストしたほうが検証が早いように感じました。この点は後述します。ただ、1日にリクエストできるURLに制限（割り当て量）があるようです。

私の場合、10ページ分のURLをリクエストしてからは上の画像のように表示され、それ以上リクエストできなくなりました。

Googleのサポートページを見てみても、この点について記載がありました。

インデックス（再）登録のリクエスト
検査済み URL のインデックス登録を Google にリクエストできます。インデックス登録には 1～2 週間程度かかります。処理状況はこのツールで確認できます。

インデックス登録をリクエストする際の注意事項
通常、インデックス登録は 1 日程度ですみますが、長くかかる場合もあります。リクエストを送信しても、ページが Google インデックスに表示されるとは限りません。送信できるインデックス登録リクエストの数には、1 日あたりの上限が設定されています。インデックス登録したいページが多数ある場合は、サイトマップを Google に送信してみてください。

明確な回数が書かれているわけではありませんが、「1日当たりの上限が設定されています」とあります。今回ように64ページもエラーがある場合は、Googleが勧める通り「サイトマップをGoogleに送信」するのも一案です。

いずれにしても、数日間にわたりURL検査でリクエストした結果、修正の検証が進んでいきました。