そこで少しだけハマった点があったので備忘録も兼ねて書き起こしておきます。

実施した速度改善

速度改善のために以下のような施策を実施しました。

1. 画像のWebP化：
   ツールを使用して画像を手元でWebPに変換したうえでWordPressにアップ
2. キャッシュプラグインの導入：
   WP Fastest Cache を導入
3. CSS統合：
   サイト内外の複数読み込んでいたCSSを1つのファイルに統合
4. Googleフォントをサーバーで配信：
   フォントをダウンロードして /assets 配下に格納

画像のWebP化は以下のツールを使用してjpgやpngをWebPに変換しています。
複数の画像を圧縮したzipファイルをそのまま放り込んでも大丈夫なツールです。

ブログの画像処理を劇的に時短！ドラッグ＆ドロップで一括WebP変換＆リサイズを自動化する方法（Windows向け）

opticode.lab.com

速度改善の成果

なんとここまでやって58点。

サイト側で重い処理を実行しているならともかく、WordPress投稿ページ + キャッシュ でこのスコアはどういうことなのか。
1時間ほどコードとにらめっこしてました。

高速化一番のネックはGoogleのタグだった

いろいろ試した後にGoogleTagManagerのみ触れていなかったので、これを一時的に削除して速度を計測してみました。

ビンゴでした。GTMタグを削除するだけで96点まで跳ね上がりました。

GoogleTagManagerにはGoogleAnalyticsとGoogleAdSenceの2タグのみ登録していました。
まさかGoogle提供のPageSpeed Insightsで最も評価を下げていたのはGoogleのタグであり壮大なマッチポンプでした。
特にAdSenceくん、重すぎ。

Pagespeed Insightsに縛られすぎるべきではない

特にPagespeed Insights のスマートフォン パフォーマンスは非常に低いスコアが出る傾向にあります。
これは 低スペックスマホ + 弱回線 という日本では一般的ではない環境を想定した計測であるためです。

以下のGoogle公式ドキュメントにあるように、検索結果に与える影響はPagespeed Insightsよりも実際に優れたページエクスペリエンスを提供できているか。というのがカギのようです。

Google のコア ランキング システムは、優れたページ エクスペリエンスを提供するコンテンツを高く評価するように設計されています。サイト所有者が Google のシステムで高い評価を得るには、ページ エクスペリエンスの限られた要素のみにとらわれないようにすることが必要です。多くの要素について検討し、全般的に優れたページ エクスペリエンスを提供できているかどうかを確認してください。

引用：ページ エクスペリエンスが Google 検索の検索結果に与える影響について

具体的にはPagespeed Insights上部の「実際のユーザーの環境で評価する」やGoogle Search Consoleの「ウェブに関する主な指標」を重視するのがよさそうです。

まとめ

Pagespeed Insightsのスコアが低くなる要素が見当たらない場合はGoogleタグを一時的に削除して計測しなおしてみてください。

また、Pagespeed Insightsのスコアが低いこと自体はそこまで神経質になる必要はなく、あくまでもGoogle Search Consoleの「ウェブに関する主な指標」などで評価が低かった場合の改善ポイントを見つけるために使用するものと考えたほうがよさそうです。

Googleのタグを使用してGoogleに指摘されるという手の上で踊らされている状態ですが、僕たちがウェブで生きていくには頭を垂れるしかないという虚しさがありました。

この記事を読むと：

• Googleの検索結果で投稿がリッチリザルトで表示できる
• クリック率が上がる
• Googleに正確な情報が伝えられSEO評価向上につながる

リッチリザルトとは？

リッチリザルトとは、検索結果において、通常の「青いリンクと少しの説明文」だけでなく、画像、星の評価、よくある質問などが視覚的にリッチ（豪華）に表示される仕組みのことです。

百聞は一見に如かずということで、リッチリザルトのサンプル画像をご覧ください。
ニュース がカルーセルで表示されているかと思います。

このように、検索結果の画面で他よりも明らかに目立って表示されるのが最大の特徴です。
代表的なリッチリザルトの種類は以下のようなものがあります。（実際はもっとたくさんの種類があります。）

• レシピ（Recipe）
• レビュー（Review）
• よくある質問（FAQ）
• 記事（Article,BlogPosting）
• カルーセル（ItemList）

通常より目立つ表示なので、できるだけこのリッチリザルトで表示されるようサイト側で設定を行いたいです。
そのために必要なのが構造化データです。

構造化データとは？一言でいうと「Google専用の自己紹介カード」

私たちのサイトを巡回するGoogleのクローラーは、単なるテキストの羅列としてしか認識していません。
たとえばページに著者名を入れていた場合に、それが投稿の著者（ライター）なのか記事の中身の登場人物か、Googleのクローラーには完全には判別できないのです。

そこで役立つのが構造化データです。

構造化データがあればGoogleのクローラーに対して
「このテキストは記事のタイトル（Headline）ですよ」
「この画像はアイキャッチ画像（Image）ですよ」
「この記事を書いたのは山田太郎（Author）ですよ」
と、意味を明確にタグ付けして伝えるための「自己紹介カード」のような役割を果たします。

これによって、Googleクローラーがサイトの情報を正確に取得しリッチリザルトとして表示してくれるようになります。

構造化データはどのように設定する？

現在、Googleが最も推奨している構造化データの書き方が「JSON-LD（ジェイソン・エルディー）」という形式です。これは、HTMLのタグを直接いじるのではなく、headタグの中にスクリプトとして記述するため、サイトの見た目に影響を与えずに安全に実装できるというメリットがあります。

サポートしている構造化データの種類や形式が詳しく知りたい場合は公式ドキュメント：Google 検索がサポートする構造化データ マークアップ をご覧ください。

WordPressで構造化データを設定する方法

WordPressを使用する場合、SEOプラグインに出力させる方法と、head タグ内に JSON-LD を出力するコードを functions.php に追記する方法があります。
今回は後者の方法で解説します。

functions.php に以下を追記すれば投稿に記事（Article）の構造化データが追加されます。
Articleはニュースやブログ記事などに使える汎用的な指定です。

function insert_custom_json_ld() {
    // 記事ページ（is_single）のみ出力
    if ( is_single() ) {
        global $post;
        
        // 公開日時と更新日時の取得
        $pub_time_c  = get_the_time( 'c' ); // 出力用（ISO 8601形式）
        $mod_time_c  = get_the_modified_time( 'c' );
        
        // 比較用にUnixタイムスタンプも取得
        $pub_time_ts = get_the_time( 'U' );
        $mod_time_ts = get_the_modified_time( 'U' );

        // アイキャッチ画像（ない場合のデフォルト画像）
        $image_url = get_the_post_thumbnail_url( $post->ID, 'full' ) ?: home_url( '/wp-content/uploads/default-image.jpg' );

        $schema = array(
            '@context'         => 'https://schema.org',
            '@type'            => 'Article',
            'mainEntityOfPage' => array(
                '@type' => 'WebPage',
                '@id'   => get_permalink()
            ),
            // 投稿タイトル
            'headline'         => get_the_title(),
            // アイキャッチ画像
            'image'            => array( $image_url ),
            'datePublished'    => $pub_time_c,
            // 'dateModified' は下の条件分岐で追加します
            'author'           => array(
                '@type' => 'Person',
                // WPプロフィール設定の「ニックネーム」を明示的に指定
                'name'  => get_the_author_meta( 'nickname', $post->post_author ),
                // WPプロフィール設定の「サイト」を明示的に指定
                'url'   => get_the_author_meta( 'user_url', $post->post_author )
            ),
            'publisher'        => array(
                '@type' => 'Organization',
                // WP一般設定の「サイトのタイトル」を明示的に指定
                'name'  => get_bloginfo( 'name' ),
                'logo'  => array(
                    '@type' => 'ImageObject',
                    // サイトのロゴ画像を指定
                    'url'   => home_url( '/wp-content/uploads/logo.png' )
                )
            )
        );

        // 更新日時が公開日時以上のときのみ dateModified を配列に追加
        if ( $mod_time_ts >= $pub_time_ts ) {
            $schema['dateModified'] = $mod_time_c;
        }

        // JSON-LDの出力
        echo '<script type="application/ld+json">' . "\n";
        echo wp_json_encode( $schema, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT );
        echo "\n" . '</script>' . "\n";
    }
}
// head内で出力
add_action( 'wp_head', 'insert_custom_json_ld' );

各項目の指定内容はコメントの通りですので、変更したい場所は該当項目を修正してください。
注意点のみ以下に記載します。

注意① 著者 author をユーザー名にしない

author（著者）の情報は名前とURLを設定します。

上記コードでは名前をWordPressのプロフィール画面「ニックネーム」の内容を取得するようにしています。ここは必ずユーザー名以外を表示するようにしてください。
ユーザー名はWordPressのログインに使用するため、公開すると不正アクセスの危険があります。

また、URLは必須ではないものの強く推奨される項目です。
現在のGoogleは、記事の評価において「E-E-A-T（経験、専門性、権威性、信頼性）」を非常に重視しています。
url を指定して著者プロフィールと紐づけることは、Googleに対して次のようなアピールになります。

• このURLの先には、著者のこれまでの執筆実績や、SNSへのリンク、専門的な経歴が載っています
  個人ブログであれば aboutページなどを指定すればよいです。
• この記事は、どこの誰とも分からない匿名の人ではなく、身元がはっきりしたこのURLの人物が責任を持って書いています

結果として、記事単体だけでなく「サイト全体の信頼性」を底上げすることに繋がります。
個人ブログであれば about ページでもよいので、必ずサイトを指定しましょう。

注意② 更新日時 dateModified は公開日時 datePublished より新しい日時にする

WordPressの更新日時は、投稿画面を保存した時間となる仕様です。
そのため、予約投稿を行った際は 公開日時 > 更新日時 となってしまい、これをそのまま使用すると公開日時より前に更新日時がある というチグハグな状態となっています。

これを防ぐために以下のように公開日時と更新日時を比較し、更新日時の方が新しい場合のみ dateModified を指定するようにしています。

        // 更新日時が公開日時以上のときのみ dateModified を配列に追加
        if ( $mod_time_ts >= $pub_time_ts ) {
            $schema['dateModified'] = $mod_time_c;
        }

ポイントとしては、Unixタイムスタンプで比較することです。
ISO 8601形式の比較は文字列同士の比較となってしまうため、予期せぬバグが発生することがあります。
そのためUnixタイムスタンプ（整数）同士の比較をするほうがプログラム的には安全で確実です。

記事以外に構造化データを追加する方法

追記したfunctionの頭にあるif ( is_single() )を分岐させてテンプレートごとに適した構造化データを指定しましょう。
また、投稿の内容によって、レシピ・レビュー・FAQ など、別の構造化データを指定したい場合は、投稿のカテゴリやタグを利用して分岐させるのがおすすめです。

Google 検索がサポートする構造化データ マークアップ の中から選びましょう。

ただし、構造化データのタイプによって必須な項目も異なるため、継続的に運用できるかを考慮して判断しましょう。
（たとえば、商品 Product の価格 offers は常に変動するものなので指定が難しい など）

構造化データの検証方法

構造化データが適切に設定されているかは以下のツールで検証が可能ですが、スキーマ マークアップ検証ツールはGoogle固有の警告は表示してくれないようです。
Google公式が提供しているのがリッチリザルト テストなので、こちらのほうがおすすめです。

• リッチリザルト テスト
• スキーマ マークアップ検証ツール

ただし、構造化データが正しい形式で指定されていたとしても、リッチリザルトで表示されるとは限りません。
とは言えGoogleには正しく伝わっているはずなので、気長に待ちましょう。

まとめ

今回はプラグインを使用しないWordPressでの構造化データの指定方法を解説しました。

設定してもGoogleは中々リッチリザルトで表示してくれませんが、表示されたときは「やってよかったな」という満足感があります。

デメリットも無いので、とりあえずで設定しておくべきの必須級の機能ですね。