PukiWiki用URL短縮ライブラリ対応XMLサイトマッププラグインを導入する!

PukiWiki用URL短縮ライブラリ対応XMLサイトマッププラグインを導入する!

昨年のクリスマスに、WordPressAll in One SEOプラグイン大幅な仕様変更により、Google SearchConsole(以下、「SearchConsole」と略)を確認して愕然とした。
余りのショックで、思わずnoteに記事を書いたぐらいだ。

PukiWiki用URL短縮ライブラリは私が開発して公開しており、同ライブラリに対応したXMLサイトマッププラグインを開発しないことには、自分が運営しているPukiWikiサイトのSEOも改善されないのは自明である。
何よりも同ライブラリは結構ダウンロードされており、利用サイトもタマに見かけるため、それら利用者への責任もある。
プログラム自体は3日夜には完成したが、仕様の細部をどうするか、またXMLサイトマップをGoogleに送信しても実際にクローラーが情報を収集するには中4日~5日ほどかかるため、仕様を詰めてコードを整理し、8日昼には先にプラグインを公開してSNSでアナウンスをしたのである。

現状の問題点

問題点もクソも、PukiWiki用URL短縮ライブラリに対応しているXMLサイトマッププラグインを開発してないし、XMLサイトマップをGoogleに送信しても、それは元の日本語を含むクソ長いURLの情報である。

ゆえに、図のようにSearchConsoleのカバレッジを見ると「インデックス登録されましたが、サイトマップに送信していません」と出力され、その件数(該当ページ)はサイトが持つページ数と同数か、それ以上になる。
この「インデックス登録されましたが云々」とは、「XMLサイトマップ送信以外の方法でGoogleが該当URLを検知し、インデックス登録した」状態であり、Googleはインデックス登録しているから(ググる時は、Googleのインデックス情報からサイトが検索されるので)致命的な問題ではない
致命的な問題ではないし、URL短縮ライブラリで短縮したURLをXMLサイトマップとして送信していないからと言って、Googleの検索順位に変動はないようだ。
しかしながら、「致命的な問題じゃないから放置しても良い」とはならない。今の今までウッカリすっかりサッパリ思いっきり忘れていた私がイケナイのだが、ちゃんとURL短縮ライブラリに対応し、正しいURLをXMLサイトマップとして出力するプラグインを開発しないワケには行かないのだ。

プラグインの設置

例によってURL短縮ライブラリ対応XMLサイトマッププラグインは本サイトのダウンロードページにアップロードしているので、ダウンロードしてローカルの作業フォルダに解凍する。

解凍すると図のように「plugin」フォルダがあるので、通常はその中にある「sitemap.inc.php」ファイルをサーバの「plugin」フォルダにFTPし、パーミッションを「644」に設定すれば良い(同名のプラグインを既に導入している場合は、サーバにある導入済みのプラグインのファイル名を変更するなりして退避すると吉)。
そうは言っても本稿は導入記事なので、プラグインの設定について説明する。

plugin\sitemap.inc.php

// XMLサイトマップ出力ファイル名
define('PLUGIN_SITEMAP_FILE', 'sitemap.xml');
// XMLサイトマップ対象ページ名(正規表現)指定
// ※対象ページ名を指定する場合は指定ページ名のみが出力対象になるので注意
define('PLUGIN_SITEMAP_PAGE_ALLOW', '');
// XMLサイトマップ除外ページ名(正規表現)指定
define('PLUGIN_SITEMAP_PAGE_DISALLOW', '^(PukiWiki\/.*)$');
// XMLサイトマッププライオリティ初期値:ルート
define('PLUGIN_SITEMAP_PLUGIN_PRIORITY_ROOT', '1.0');
// XMLサイトマッププライオリティ初期値:コンテンツページ
define('PLUGIN_SITEMAP_PLUGIN_PRIORITY_CONTENT', '0.8');
// XMLサイトマッププライオリティ初期値:タグページ
define('PLUGIN_SITEMAP_PLUGIN_PRIORITY_TAG', '0.5');

特に説明するほどの内容は無いのだが、プラグインの仕様として

  • Googleで考慮されないとされる更新頻度(changefreq)出力には対応しない
  • URLの優先度(priority)指定は必須ではないため、個別にページ内容を調べて優先度を設定せず、次の通りザックリとしか出力しない
    • ルート(トップページ)URLは優先度「1.0
    • コンテンツページURLは一律優先度「0.8
    • PukiWiki用SEO対応プラグインで出力するタグページURLは一律優先度「0.5
      (当該プラグインを導入してタグ出力を設定している場合に設定され、未導入・未設定の場合はコンテンツページURLと同一優先度とする)

としている。
よって、設定するなら優先度(プライオリティ初期値)を変更するか、対象または除外ページの正規表現指定ぐらいしかない。除外ページ指定に関しては、「PukiWiki/」で始まるページ(PukiWiki標準のプラグインマニュアルページ)を除外するようにしてある。
個別にページ内容を調べて優先度を設定しない仕様にしたのは、ひとつには優先度をページごとにキメ細かく設定しても余り意味がないといった面もあるが、私設松本零士博物館サイトのように、既に数百ページ以上のボリュームがあるサイトでいちいちページファイルを開いてチェックしていたのでは、プラグインの動作が重いモノになってしまうからだ。
だだし本来的に、nofollowプラグインを使ってページに

#nofollow

と記述しているページのURLを、XMLサイトマップとして出力しない方が良い。
要望次第ではnofollowプラグインに対応させることも考えるが、実運用サイトでnofollowプラグインを指定しているページは少ないだろうと判断した。

実際の使い方とその効果について

まずは、SearchConsoleの場合。

図は私設松本零士博物館サイトのサイトマップ送信画面だが、図の通り入力して送信すれば良い。

/?cmd=sitemap
赤枠送信」ボタンをクリックする。

マイクロソフトのBing Webmaster Toolsを利用している人がどの程度いるのか不明だが、同様に簡単に送信出来る。

送信したいサイトマップをチェックする(図ではhttps://museum.dajya-ranger.com/?cmd=sitemap
赤枠再送信」をクリックする。

余りいないとは思うが、コレを機にBing Webmaster ToolsでもXMLサイトマップを送信したい人は、上述のようにチェックして「再送信」とは行かないが、それでも簡単だ。

赤枠サイトマップを送信」ボタンをクリックする
サイトマップ送信URLを入力(図の場合はhttps://museum.dajya-ranger.com/?cmd=sitemap
赤枠送信」ボタンをクリックする

これで次回からはサイトマップを一覧からチェックして「再送信」をクリックすれば送信することが可能になる。
なお、プラグインの動作としてページ更新キャッシュファイルをチェックしてXMLサイトマップを生成するか判断しているが、

/?cmd=sitemap&page=TRUE

と指定することで、強制的にXMLサイトマップを出力するようにしている。
そしてXMLサイトマッププラグインの効果だが、これも私設松本零士博物館サイトのSearchConsoleのカバレッジで確認してみよう。

図の通り、本稿執筆時点で「送信して登録されました」とされているページが617となっている。
インデックス登録されましたが云々」は年明け2日の段階で854ページあったのが362ページに半減している。

インデックス登録されましたが云々」となっているページの詳細を見てみると、図のようにURLに「index.php」が付いたURLだったり、短縮される元の日本語ページ名のURLだったりする。
昔のPukiWikiとPHPのバージョンでは、URLが「サイトドメイン/index.php?ページ名」形式で、今では「index.php」が省略可能になっているのだ。
また、PukiWiki用URL短縮ライブラリを導入している場合は、短縮されたURL以外にも、元の長い日本語ページ名を指定された場合でもちゃんと当該ページを表示するようになっているため、このような短縮していないURLをGoogleが収集してしまうのである。
Googleが勝手にURLを収集してインデックス登録している分には、それこそ「致命的な問題じゃないから放置しても良い」だろう。
ただ、「index.php」が付いたURLとかGoogleに登録されないように排除出来ないのか?と言えば出来ないことはない。「robots.txt」を書いて設定してやれば良いし、本プラグインではPukiWiki汎用の「robots.txt」も同梱しておいてある。

robots.txtを設定する

本プラグインに同梱している「robots.txt」をPukiWikiサイトのルートフォルダ(「pukiwiki.ini.php」が置いてあるフォルダ)にFTPし、パーミッションを「644」に設定すれば良い。
同梱した「robots.txt」の内容は、次の通りとなっている。

\robots.txt

User-agent: *
Disallow: /wiki/?FrontPage
Disallow: /wiki/index.php*
Disallow: /wiki/*cmd=sitemap*
Disallow: /wiki/*cmd=backup*
Disallow: /wiki/*cmd=diff*
Disallow: /wiki/*cmd=edit*
Disallow: /wiki/*cmd=unfreeze*
Disallow: /wiki/*cmd=freeze*
Disallow: /wiki/*pcmd=upload*
Disallow: /wiki/*plugin=newpage*
Disallow: /wiki/*plugin=rename*
Disallow: /wiki/*plugin=template*

1行目で全てのロボットクローラーのエージェントを指定し、2行目以降から「wiki」フォルダに対してブロックするように指定している。
具体的に2行目の「?FrontPage」は、PukiWiki標準のトップページ名が「FrontPage」であり、かつ省略可能だからだが、トップページ名を変更して設定している場合は、この部分を修正すれば良い。
3行目は省略可能な「index.php」を含む全部のURLをブロックする指定となり、4行目以降は、PukiWikiでの操作で各種コマンド(ライブラリ)やプラグインを呼び出すURLをブロックする設定となっている。
ちなみに「robots.txt」を配置した場合、PukiWiki標準の「.htaccess」の設定のままだと、Googleを含むサーチエンジンのクローラーがアクセス出来ないため、「.htaccess」ファイルの20行目付近を次のように編集する必要がある。

\.htaccess

# Prohibit direct access
#<FilesMatch "\.(ini\.php|lng\.php|txt|gz|tgz|zip)$">
<FilesMatch "\.(ini\.php|lng\.php|gz|tgz|zip)$">
  Require all denied
</FilesMatch>

上記2行目がPukiWiki標準の設定で、「.txt」ファイルのアクセスも拒否されてしまうため、コメントアウトして3行目のように「txt」部分を削除して追記・保存し、サーバへFTPすれば良い。
なお、「robots.txt」を編集した場合は、Googleのrobots.txtテスターでテストしてから、サーバにFTPすることをオススメしておく。

robots.txt」が文法的にちゃんと作成されているかのチェックに有効だが、下手に「robots.txt」を設定してしまうと、サーチエンジンにクロールしてインデックス化して欲しいURLをブロックしてしまいかねないので、その点は注意が必要だ。

おわりに

robots.txt」の内容はアレで良かったんかな?と思いつつ、ともかくPukiWiki用URL短縮ライブラリ対応XMLサイトマッププラグインをリリースし、想定通りの機能の確認が出来てホッとしている。
思えば去年はPukiWikiサイトでのコンテンツ作成に主眼を置いて労力をかけていたせいか、まったく自分でもマヌケだったが、採用していたXMLサイトマッププラグインに問題があったことを知らずに放置していた。
有り難いことにPukiWiki用URL短縮ライブラリは人気のようだし、その他のプラグインも順調にダウンロード数を重ねており、開発者冥利に尽きると言える。
ただ、「PukiWikiに革命を起こす」意気込みで開発したドラッグ&ドロップアップロード対応attachプラグインのダウンロード数がイマイチなのは、個人的に納得は行かないものの、ネットの常で自分が良いと思うモノってのは(自分で書いた記事も含め)イコール万人にウケて支持されるモノじゃないんだなと、改めて思い知らされている。
そもそも私個人は元来が雑な怠け者で大酒呑みのグータラであるから、不勉強なのは当然だし、勘違いして知った気になっているから誰にも相手にされず、ゆえに世捨て人を気取りながら「なんだ、ワシを理解しないとは低能め」と一方的に決めつけ、如何にも偉そうなことを放言していい気になっているのが普通だ。そして下手にいい歳ブッこいているものだから、訳知り顔で若い人に説教臭いことを吹聴し、以て増々得意になっている次第であるから、誠に手の付けられない老害として、これを封じなければならぬ
それには、「オッサン、なに勘違いしてやがるんだ」と、エビデンス(プログラムならソースプログラム)を提示し、面罵してもらわなくては困る。例えば、それがPukiWikiの場合ならばより良いシステムとしてこれからも発展する原動力となるに違いない。
私個人の文学的な理解や政治的な思想も含むが、殊にプログラムってのは正に「論より証拠」で、実際に動かしてみれば白黒がハッキリするだけに、そこに言い訳をするようではプロである以前に、プログラマとして失格だ。若者が「老害」と罵る、我々老人をコテンパンにヤッツケることを大いに期待する

 

 

この記事が気に入ったら
いいね ! をお願いします


ITで何かお手伝いできることはありませんか?

CTA-IMAGE

本サイトでは、外部サービスと連携して「ITの困った」を解決します!

PukiWikiカテゴリの最新記事