https://developers.google.com/search/docs/advanced/sitemaps/build-sitemap?hl=ja
上記のGoogle様のサイトマップ作成のガイドラインを参考にどのような仕組みがいいのか考えてみる。
ちょっといま時間がなく実装が一筋縄ではいかないので、今回は記事を書きながら草案を考えてみる。
まずWordPressで記事として公開されているすべての投稿タイプを取得とそのカスタムタクソノミーを取得し、そのアーカイブリンクと記事のリンクを用意する(CF7などの投稿タイプは記事なっていないとみなす仕組みだったり、トップページが固定ページかアーカイブページになっているかなどを注意)。
また対象の投稿タイプの記事すべてにnoindexを有効にするかどうかというカスタムフィールド を準備する。
その後、 下記のテンプレートに沿って sitemap.xml をインストール直下に出力するようにリライトルールを変更する。
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.google.com/schemas/sitemap/0.9">
<!-- アーカイブページ -->
<url>
<loc>https://example.com/</loc>
</url>
<!-- 記事ページ -->
<url>
<loc>https://example.com/blog/00001</loc>
<lastmod>2021-04-28T18:31:05+09:00</lastmod>
</url>
<!-- 他言語の場合 -->
<url>
<loc>https://example.com/about/</loc>
<lastmod>2021-04-28T18:31:05+09:00</lastmod>
<xhtml:link rel=”alternate” hreflang=”jp” href=”https://example.com/about/”/>
<xhtml:link rel=”alternate” hreflang=”en” href=”https://example.com/en/about/”/>
</url>
<!-- 他言語の場合(英語も同じように書かなければいけない) -->
<url>
<loc>https://example.com/en/about/</loc>
<lastmod>2021-04-28T18:31:05+09:00</lastmod>
<xhtml:link rel=”alternate” hreflang=”jp” href=”https://example.com/about/”/>
<xhtml:link rel=”alternate” hreflang=”en” href=”https://example.com/en/about/”/>
</url>
<!--
それぞれのHTMLには下記のように記述する
<link rel=”alternate” hreflang=”ja” href=”https://example.com/about/”>
<link rel=”alternate” hreflang=”en” href=” https://example.com/en/about/”>
-->
</urlset>
Google は priority と changefraq の値を無視するため、記述する必要はない。
またURLは完全修飾URLで記述し適切にURLエスケープを行う。
canonical タグを使っているものはその参照先のURLのみにし、もし50000を超えるURLになったりsitemap.xmlが50MB以上になる場合は、インデックスファイルを作成し、サイトマップを分割する必要がある。
その後、publish_post などのアクションフックで、下記のようにGoogle に ping 送信を行う。
$ch = curl_init( 'http://www.google.com/ping?sitemap=' . home_url('/') . 'sitemap.xml');
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_exec($ch);
if(curl_error($ch)) {
// エラー処理
}
curl_close($ch);
またrobots.txtにサイトマップのパスを記述する。
Sitemap: https://example.com/sitemap.xml
以上。
こうやって考えてみて思い出したんだが、トップページを固定ページにするか、自動生成にするかとか、カテゴリーやタグのタクソノミーが他のタクソノミーと違って、WordPressの組み込み度が深く、カスタムタクソノミーと同様に扱えないなどを考えるとエンジニア向けの作りとは言い難く(元々ブログシステムだし)、そういった一貫性がない部分を消すプラグイン(や別にフォークしたシステム)などがあれば便利だなーと思った。
WordPressは十分フレームワーク的な扱いで使えるようになっているが、LaravelみたいにコメントフォームなどのPOST処理する部分のHTMLも簡単に変えられるようになったらいいのに。