Sabakura Blog

WordPressを利用してウェブサイトを作成する機会も増えてきましたが、それに伴って利用するプラグインの数もしだに増えてきます。そこで半ば備忘録も兼ねて、自分がよく使っているプラグインをまとめて紹介してみたいと思います。

SEO関連

All In One SEO Pack

タイトルタグの設定や、カテゴリやタグページのnoindex化など面倒な作業を一括で行える高機能SEOプラグインです。知名度・普及度も高く、SEO関連でどれか一つプラグインを入れるならこれで間違いなしと言えます。なお、導入記事も「WordPressのSEO対策プラグイン「All in One SEO Pack」の導入と詳細設定」で書いています。

Google XML Sitemaps

Googleのウェブマスターツール等に登録するためのサイトマップ（.xml）を作成するためのプラグイン。一度設定してしまえば、あとは記事やページの追加・更新のたびに自動で送信してくれます。

Breadcrumb NavXT

パンくずリストを簡単に作成できるプラグイン。このサイトでは導入していませんが、カテゴリ分けが多岐に渡るサイトなどで、ユーザーに現在位置を分かりやすく示すのに有用です。SEO的には直接効果があるかは分かりませんが、Googleのガイドラインでも使用が推奨されていますので、悩んだら導入しておくのが吉です。

サイト運営の効率化

Akismet

WordPressにも標準で同梱されているスパムコメント排除プラグイン。

Broken Link Checker

リンク切れを自動でチェックして教えてくれるプラグインです。WordPressのダッシュボードから確認できるほか、新たなリンク切れを発見したときにはメールで通知してくれる機能も持っています。

Contact Form 7

メールフォームが設置できます。非常に有名なプラグインでもあり、また導入も専用のタグを挿入するだけととても簡単です。

Front-end-Editor

記事の修正をダッシュボードに移動することなく、サイトを表示させたまま直接行えるようになります。いまいち認知度が低いように感じるのですが、こまかな修正を多数行うことが多い自分にとっては手放せないプラグインです。
参考：記事を頻繁に修正する人には、WordPressプラグイン「Front-end Editor」がおすすめ！

WP Hatena Notation

「*（アスタリスク）」を文頭に入れるだけでhタグに変換できるなど、HTMLを含む記事の執筆を手助けしてくれる「はてな記法」がWordPressでも使えるようになります。こちらもFrond-end-Editorと並んで、個人的には必須といえるほど使用率が高いプラグインです。
参考：WordPressではてな記法を使えるプラグイン「WP HatenaNotation」導入とカスタマイズ方法

URLの変更に関するもの

WP No Category Base

WordPressは標準ではカテゴリページのURLに「/category/」という階層が自動で追加されてしまいます。そのためたとえばニュースカテゴリであれば「/category/news」とURLが長くなります。これを「/news/」のみに短縮化してくれるプラグインです。

Custom Permalinks

一記事、一ページごとにURL構造をユーザーが手動で設定できるようになります。私の主な使い方としては、階層化された固定ページ（子ページ）のURLから親ページのディレクトリURLを削除する場合に使用しています。

メンテナンス関連

Maintenance Mode

名前のとおり、一発でWordPressサイトをメンテナンスモードにしてくれます。メンテ終了時間をユーザーに告知できるほか、一時的なメンテであることを検索エンジン等に通知するhttpステータスコード「503」を返すことができます（要設定）。

WordPress Importer

WordPressでエクスポートしたデータを読み込む（インポートする）ためのプラグイン。ローカルでこまかな修正を施したものを書き出し、サーバー側でそれを読み込む、という使い方が個人的には多いです。

その他

WP Multibyte Patch

WordPressの日本語版には標準で同梱されています。日本語文字の取り扱いに関する様々な処理を行ってくれます。ワードプレスインストール後にまず有効にしておくプラグインの一つです。

Search Regex

投稿記事や固定ページに含まれる文章の一括検索・置換が行えるプラグインです。複数の記事に含まれるリンクを一括で書き換えたいといったときに重宝します。

このブログを含めて、自分が管理しているサイトは原則としてGoogleのウェブマスターツール（WMT）に登録を行っています。あわせて、サイトマップの送信も行っています。

現在は管理しているサイトのほとんどがWordPressサイトになっているため、サイトマップの作成には有名なプラグイン「Google XML Sitemaps」を利用しています。

・Google XML Sitemaps – WordPress Plugins

ただ、このプラグインでは設定により「標準のXMLファイル（拡張子は.xml）」のものと「gz圧縮されたファイル（拡張子は.gz）」の両方を出力することができます。
※どちらかだけを作成することも可能です。

今まではあまり意識せずに両方を出力し、WMTにはgz形式のファイルを送信していましたのですが、ふと「どちらを送信するのが正しいのか？」「それとも両方送信するべきなのか？」「SEO上の効果に差はあるのか」などが気になったので調べてみました。

（もしかしてあまりに当たり前の情報だからなのかもしれませんが）意外とこのことに触れている記事が少なかったので、調べた結果を書いておきます。

gz圧縮について

まず「gz圧縮されたファイル」ですが、これについてはUnix/Linuxにおいて圧縮コマンド「gzip」を使った場合に生成されるファイルです。

このほかよく見られる圧縮形式として「.tar.gz」という形式がありますが、これは複数のファイルをgzipで圧縮したものです。サイトマップの場合は「sitemap.xml」のような単独のXMLファイルを圧縮するため、（.tarのつかない）「.gz」形式になります。

ためしにこのブログのサイトマップのサイズを確認してみたところ、以下のような結果になりました。たしかにgz形式のほうがサイズが明らかに小さくなっています。

• sitemap.xml：18,342 byte
• sitemap.xml.gz：2,440 byte

ウェブマスターツールへの登録について

では実際にWMTに送信するサイトマップの形式はどちらが望ましいかです。これについては、じつは「Google XML Sitemaps」の公式ヘルプに答えに近いことが書かれていました。

The “sitemap.xml.gz” is a compressed version of the “sitemap.xml” file. It has the same content, but is significantly smaller than the other one. This helps you and the search engines to save a lot of traffic. Since all search engines support compressed sitemaps, you actually don’t need the “sitemap.xml”, but maybe you or your visitors want to view them from time to time so keeping it doesn’t hurt.

要約すると「どちらの形式で作成しても中身には変わりないが圧縮されたgz形式だとサイズが小さいため、トラフィックの節約になる。すべてのの検索エンジンは圧縮したサイトマップを読み取れるので通常はgz形式で問題ない。ただユーザーが直接サイトマップファイルを閲覧するような場合には.xmlが役立つこともある」というわけです。

なおxml形式で送信したからといってインデックスが遅くなるなどのデメリットがあるというわけではないようです。なお、私は一時期「.xml」と「.gz」を両方ともWMTに送信していたことがありますが、とくに警告を受けたりSEO面で順位に変化も感じられませんでした。

ようするに、通常はサイズの小さいgz形式のファイルを送信していればOKということです。これで安心してサイトマップを送信することができるようになりました。

先日VPSで運用している別サイトでWordPrewwの再設定を行ったのですが、その際にちょっとハマった内容についてのメモです。

WordPressのURLをトップページに指定できない

そのサイトは、これまでは「wp」というディレクトリを作って、そこにWordPressをインストールしていました。つまり「http://hogehoge.com/wp」といったURLで運用していたわけです。

ただ今回WordPress入れ替えに伴って、「wp」の表示を省略して「http://hogehoge.com」というURLで運用しようと思いました。同様の作業は過去に何度も経験があったので、以下のページを参考にindex.phpと.htaccessをルートディレクトリにコピーするなどの作業を行いました

参考：WordPress を専用ディレクトリに配置する – WordPress Codex 日本語版

いつもなら上記ページの「既存のサブディレクトリをルートディレクトリとして表示する場合」の手順で問題なく動くはずなのですが、なぜかトップページは表示されるものの、個別の記事や投稿が404NotFoundになります。

どうもパーマリンク設定が反映されていないようで、デフォルトの「?P=1」などに戻すと表示されるのですが、それ以外だと表示できません。というわけで、どうやら.htaccessが動作していないようだ、というところまでは原因が絞り込めました。

で、今度は下記ページを参考にmod_rewriteやhttpd.confの設定を見直していたのですが、やっぱり直りません。

参考：mod_rewriteの設定(パーマリンク形式を変更した場合にエラー表示された場合) – WordPressの使い方

ここで完全に行き詰ってしまい、かなりの時間悩んでいました。が、色々やって解決してみたら原因は単純でした。やっぱりhttpd.confの設定でした……。

AllowOverrideの指定に注意

httpd.confを見直すと、.htaccessを有効にするために下記の設定を行っていました。

<Directory "/var/www/html/wp">
    AllowOverride All
</Directory>

しかし、よく考えたらindex.phpと.htaccessは一つ上のディレクトリ（/var/www/html）にコピーしたわけですから、「/var/www/html/wp」でAllowOverride Allしてもその下層にしか反映されていません。

よって以下のようにDirectoryの指定を書き直しました。

<Directory "/var/www/html">
    AllowOverride All
</Directory>

これで個別の投稿や記事が、カスタム構造のパーマリンクでも問題なく表示されるようになりました。

というわけで、既存のディレクトリからルートディレクトリにURLを変更する場合は、AllowOverrideの指定に注意しないといけないという話でした。覚え書きな記事ではありますが、もし同じような現象で困っている方がいればお役に立てば幸いです。