WordPress標準のXMLサイトマップ出力機能をカンタン設定 XML Sitemaps Manager

道に迷う
©いらすとや.

WordPressはバージョン5.5からXMLサイトマップの出力機能が含まれるようになった。(コアXMLサイトマップ)
このXMLサイトマップ出力機能は初期値で有効なので他のXMLサイトマッププラグインなどを使わなくても良い。と、いいたいところだだけど機能がお粗末なので標準状態ではちょっと使いたくないという意見が多数。ただ、コードを足してやれば実はソコソコなサイトマップを出せるようになるので、素性が判らなくてお粗末なプラグインを使うくらいならこのコアXMLサイトマップの方がマシかもしれない。

とはいえ、「コードを足してやれば」の難易度がそれなりに高いのでWordPressが難しいと思ってる人やPHPのコードがただの謎の呪文にしか見えないような人にとってはまるで歯が立たない。コードを書き込むfunctions.phpファイルを壊してしまって途方に暮れる人も出そうだし。
と、思ってたら、そのコアXMLサイトマップをWordPressの管理パネルでカンタンに設定できるプラグインが出ていた。

XML Sitemaps ManagerでWordPressコアサイトマップを制御 1
WordPressの管理パネルのメニューから「プラグイン」をクリックする。
プラグインリストの上部にある「新規追加」をクリックする。

XML Sitemaps ManagerでWordPressコアサイトマップを制御 2
右上のプラグイン検索で「RabanH Sitemap」を入力する。
RavanHというのは今回インストールするプラグインの作者のアカウント名。理由がさっぱりわからないけど何故か日本では人気?なXML Sitemap & Google Newsプラグインと同じ作者でもある。
「XML Sitemaps Manager」が今回の目的のプラグイン。その、「今すぐインストール」をクリックする。

XML Sitemaps ManagerでWordPressコアサイトマップを制御 3
数秒でインストールが完了して「有効化」のボタンになるのでそれをクリックする。

XML Sitemaps ManagerでWordPressコアサイトマップを制御 4
プラグインリストに戻るので「XML Sitemaps Manager」行の下にある「設定」または、左列のメニューから「設定」→「表示設定」をクリックする。

XML Sitemaps ManagerでWordPressコアサイトマップを制御 5
「XML Sitemaps Manager」プラグインは専用の設定画面を持たず、WordPressの「表示設定」画面の下部にXMLサイトマップの設定が追加される。サイトマップに含める記事等の種類または含めない種類を適切に決める。これは、本来はテーマのfunctions.phpにコードを書いて設定するものだがチェックボックスに印を付ける(外す)だけの簡単設定になっている。
「ユーザー」の子サイトマップは要らないという判断することが多そう。要らないならチェックを外す。
「最終更新日」というのはlastmodという項目でサイトマップに記載される記事の公開日時/更新日時。WordPressのXMLサイトマップの初期値では表示されなくてテーマのfunctions.phpにコードを書いて表示できるようにするのだが、「XML Sitemaps Manager」ではチェックするだけ。もちろんチェックするのがオススメ。
「Maximum number of URLs」は1つの子サイトマップに最大で幾つまでの記事URLを含めるかの指定。WordPressのコアXMLサイトマップ機能の初期値は2000になっている。静的出力なら2000やもっと多くて良いかと思うが非力なウェブサーバでWordPressを動かしてて動的出力で2000は多すぎると思う。個人的には数百、多くて500程度が良いように思うが「XML Sitemaps Manager」では空白(初期値2000)または1000以上の数字を入力しないとダメらしい。この1000は根拠がある数字ではなくこのプラグインの作者が勝手に決めた下限値。ちょっとセンスを疑う。テーマのfunctions.phpにコードを書けば幾つでも好きな数値を設定できる。なお、「XML Sitemaps Manager」の設定値よりもテーマのfunctions.phpのコードが優先される(優先にできる)。
設定完了なら「設定を保存」を忘れずにクリックする。

XML Sitemaps ManagerでWordPressコアサイトマップを制御 6
WordPressのコアサイトマップのURLは https://example.com/wp-sitemap.xml (example.comは自身のサイトのドメインに読み替えてください)
wp-sitemap.xmlはサイトマップインデックス(親サイトマップ)で、このページにあるリンクがそれぞれ(子)サイトマップ。子サイトマップに何のURLを含めるかは任意で、他のXMLサイトマッププラグインだと年別/月別で子サイトマップを出力するのが多いようだが、WordPressのコアサイトマップは投稿/固定記事等のID順で指定したURL数で分割しているよう。上の画像ではwp-sitemap-posts-post-N.xmlというのが「投稿」の子サイトマップ。wp-sitemap-posts-page-N.xmlというのが「固定記事」の子サイトマップ。wp-sitemap-taxonomies-category-N.xmlが「カテゴリ」の子サイトマップ、wp-sitemap-taxonomies-post-tag-N.xmlが「タグ」の子サイトマップ。
子サイトマップは単純にURLとlastmod(公開日時/更新日時)が並ぶ。(画像無し)
サイトマップインデックス(親サイトマップ)では「投稿」や「固定記事」など最大数指定を超えたものは分割されて複数の子サイトマップ(記事群)になるが、「XML Sitemaps Manager」を使用すると一番上の1つだけに最新の公開/更新日時がつくようになっている。ところが、子サイトマップの並び順は古い記事群の子サイトマップが上で新しい記事軍が下なので一番上に最新の公開/更新日時が付いてしまうと常識的にはおかしなことになる。本来は各記事群(子サイトマップ)の中で最も新しい公開日/更新日を表示するものだと思う。他のXMLサイトマッププラグインではそのように処理している。記事の更新がほぼ無いようなサイトであれば1つ最新の公開/更新日時を表示しておけば処理が簡単で良かろうという合理的判断かもしれないが、それなら全ての子サイトマップに(同じ)最新の更新日時を付ければ良くない?コードを見るとわざわざ日時表示を外しているのでこれはバカらしいように思える。個人ブログで1000記事を超えるのは滅多にないだろうということかもしれない。それが含めるURLの下限を1000にしている本当の理由なのかしら?

せっかく管理パネルのUIで設定できるのに、除外対象に記事IDやカテゴリ/タグIDを指定できないのは何でかしら。この除外設定は比較的容易に実装できる筈なんだけど。小規模な個人ブログだと除外なんかしないだろうというお考えなのかな。

殆どはWordPressのコアXMLサイトマップの機能を呼び出してるだけ。同じ作者のXML Sitemap & Google Newsプラグインにも変な仕様や考慮漏れ(と多くのバグ)があるが、この「XML Sitemaps Manager」もやっぱり「何でこうなの?」「コレじゃない」という部分がある。設定を手書きでやらなくて良いので圧倒的にカンタンにはなってるけど惜しいかなというのが率直に思ったところ。

「がとらぼ」の中の人はプラグインをあまり使わない。この「XML Sitemaps Manager」プラグインも正直要らない。コードを見たところ個人的に有益に思った部分があったのでそこだけ頂いて自分でテーマのfunctions.phpに書くことにした。ついでにこのプラグインで触ってない部分も追加してより実用的に?
それは次の記事で。

関連記事:

certbotを使いLet's EncryptでECDSAな証明書を作る 2022年

鍵
©いらすとや.

5年前に Let's EncryptでECDSAな証明書 を書いたときはまだECDSAな証明書を作るのは少し面倒だった。現在は簡単にECDSA鍵なTLS証明書を発行できるようになっている。
今回「がとらぼ」を https://gato.intaa.net から https://intaa.net にドメイン内移転させるにあたり、メールサービスに使っていた https://intaa.net を別ホストから「がとらぼ」の動いているホストに移すことになった。そこで、別ホストのintaa.net証明書を破棄 (certbot delete)し、「がとらぼ」のホストで再発行することにした。そのついでにECDSAな鍵の証明書を再発行した。

certbotでECDSAな証明書を発行(新規)

# certbot certonly --key-type ecdsa -d example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Spin up a temporary webserver (standalone)
2: Place files in webroot directory (webroot)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Requesting a certificate for example.com
Input the webroot for example.com: (Enter 'c' to cancel): /var/www/example.com

Successfully received certificate.
Certificate is saved at: /usr/local/etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /usr/local/etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2023-01-16.
These files will be updated when the certificate renews.

NEXT STEPS:
- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

このように --key-type ecdsa をコマンドに追加するだけでECDSAな証明書が発行される。なお、鍵のタイプだけを指定した場合は P-256 (prime256v1=secp256r1) になるみたい。高めの暗号強度を得たくて P-384 (secp384r1) にしたいのであれば追加で --elliptic-curve secp384r1 を指定する。まぁ普通はsecp256r1で良さそう。
強度的にはECDH256が鍵長3076bitのRSAに少し及ばない程度。ECDH384だと鍵長7680bitのRSAに少し及ばない程度でこれはブログなどの普通のウェブサイトで使うにはオーバーキルだと思う。

設定と更新への影響

以降全ての証明書の発行でECDSAにするとかP-384にしたいということであれば設定ファイル /usr/local/etc/letsencrypt/cli.ini (FreeBSDのPKG/Portsでインストールした場合のPath)に書く。cli.iniはPKG/Portsでインストールした場合は存在しないので過去に設定ファイルを作っていないなら新規作成となる。

key-type = ecdsa
elliptic-curve = secp384r1

設定を書いてしまうとそれがデフォルトになるので以降に例えばRSAな鍵を作りたいなら コマンドで --key-type rsa を指定することになる。RSAの鍵長さを初期値の2048bitではなく4096bitにしたいとなれば --rsa-key-size 4096 を追加指定する。
設定を書くと既存の証明書(発行時にオプション指定なしの証明書)の次回以降の更新に影響が及ぶため十分に注意。証明書発行時に付けたオプションは設定ファイルより優先して更新時にも適用されます。つまり --key-type ecdsa--key-type rsa を付けて発行(更新)した証明書は次回以降の更新でも設定ファイルの指定を無視して発行時と同じ --key-type ecdsa や --key-type rsa を付けたのと同様に更新されます。

ECDSAな証明書に変更して更新

既存のRSAな証明書をただちにECDSAな証明書に「更新」したいということがある筈。

# certbot renew --cert-name example.com --key-type ecdsa --force-renewal
こんな感じでいける。

ハイブリッド証明書

5,6年前はECDSAな証明書を普通のウェブサイトで使用するなら閲覧者のブラウザとの互換性のためにRSAな証明書とのハイブリッドを勧めたが、2022年の今はもうハイブリッドにする必要はないように思う。よほど古いスマホ Android 2.xとか古いゲーム機のブラウザが非対応なくらい。
ECDSAなSSL証明書を作ってみる

RSAな証明書を作成済みとして、ECDSAな証明書を追加発行する。

# certbot certonly --key-type ecdsa --cert-name example.com-ecdsa

5年前と比べると、需要を満たすコマンドが多く追加されたようでとても簡単になってて良い感じ。

関連記事:
Up