長らくWordPressのパーマリンクを%post_id%で管理してきたが、いろいろ考えて%postname%（スラッグ名）に変更することにした。その理由と、CSVファイルを使った作業手順についてメモしておこうと思う。
今回はデータベースをいじらないExcelのみの作業。1,000記事近くのスラッグをコピペする単調作業になったが、マウスのボタンをカスタムすることで多少は効率化をはかれた。
記事IDが非連続で気持ち悪い
先日、post_idが自動で増えていく原因はテーマのカスタマイズと突き止めた。対策不可能なのであきらめたが、やはりテーマをいじるたびに数字が増えていくのは気になる。
せっかく数字で管理しているのに、記事IDが非連続なのは不気味だ。理想的にはこれまで書いた記事の数がIDから把握できるようにしたい。「postnameに数字を入れる」という技もあるが、途中で記事を消したり他ブログからインポート・挿入したりすると修正が面倒だ。
記事URLをIDで管理するメリット・デメリットは前の記事で書いた通り。ブログを始めた当初はちゃんと固有名でパーマリンクを付けていたが、次第に面倒になりデフォルト設定のままにした（はてなブログの場合は日付が入る）。
はてなからWordPressへ移行する際、さらにシンプルなpost_idに切り替えた。長かったパーマリンクが数ケタの数字に変わり、記事URLを劇的に短縮できた。
記事や画像の追加でIDが増えていくのは仕方ないと思っていたが、増分の理由はそれだけでない。複数ブログ間で記事移行する際、post_idが引き継がれてしまうという問題も出てきた。
記事移行時にIDが引き継がれる
別のブログから記事のエクスポート/インポートを繰り返すと、以下のような問題が生じる。
- 別ドメインのWordPressに記事をエクスポートすると、移行先のブログがインポートした記事IDからの増分になってしまう。そのため、始めたばかりのブログ記事URLがいきなり千桁の数字になってしまったりする（当記事のIDも5千台）。
- 別のブログから記事をインポートした際、IDの競合があると自動的に最新番号に置き換えられてしまう。その後301リダイレクトを設定する際、いちいち数字を確認するのが面倒。
そして前回発見した「記事以外の要因（テーマカスタム）」によるID増分問題。これらの要因を組み合わせると、記事を転送したりブログを移転するたび予期せぬエラー（リンク切れなど）が発生するおそれがある。心理的な気持ち悪さだけでなく、技術的・SEO的な面だけでも不都合が生じる。
一度postnameに設定したパーマリンクをpost_idに変更する場合はWordPress内の自動転送が働く。しかし逆は成り立たない。すると相対的にデメリットの少ないpostnameで運用しておいて、後から気が変わればまたpost_idに戻すのが合理的だ。
とにかく記事にスラッグさえつけておけば後々融通がきく。そう思って運用しているブログの記事パーマリンクを、すべて%postname%に変更することにした。
約1,000記事の設定変更
現在公開している記事を合計すると全部で973あった。そのうちスラッグ名が設定してあるのは初めの頃に書いた一部のみ。あとはpost-○○といったWordPressの初期値が設定されている。
これらに対して、以下のような作業を行いたい。
- 記事内容から妥当なスラッグ名を考えて入力
- パーマリンク設定をpost_idからpostnameに切り替え
- .htaccessファイルに各記事の301リダイレクト文を追加
作業手順は徐々に効率化できたが、すべての設定を終えるのに手動で6時間くらいかかった。仮にでもよいから、毎回記事を書くたびにスラッグを設定しておけばよかったと後悔した。
記事CSV書き出し用プラグイン
さすがに数が多いので、WordPressの管理画面ですべて済ませるのは骨が折れる。公開している記事のIDやタイトルをCSVファイルに書き出して、Excelで編集するのが効率的だ。そこからリダイレクト用のテキストもコピペできる。
記事CSVのエクスポートには、WP CSV Exporterというプラグインを利用させてもらった。他にも似たようなプラグインがいくつかあるが、いろいろ試して一番便利だったのがこれだ。
最初に試したExport any WordPress data to XML/CSVというプラグインもよかったが、書き出すフィールドをカスタムすると”An unknown error occurred”というエラーが出て先に進めない。
デフォルトのままでは長ったらしいContent全文が書き出されてしまう。数百記事もあるとCSVが重くなりすぎるのか、Excelではエラーが出てファイルを開けなかった。
他に評判がよさそうだったWP All Exportというプラグインは、現在Word Press内で検索しても出てこない。2019年8月現在、記事情報をCSVで書き出したいならWP CSV Exporterを選べば間違いないと思う。
WP CSV Exporterの使い方
プラグインをインストールしたら、管理画面のツールで詳細設定の画面を開ける。ここで不要なPost ContentとCustom Fieldsのチェックを外し、逆にPost Dateなど必要そうな項目をチェックして追加する。
注意点としては一番下に文字コードの設定があり、Windows環境のExcelではデフォルトのUTF-8だと文字化けしてしまう。オプションにあるShift_JISを選んでエクスポートすれば問題は出なかった。
Slug、Titleなどリスト化したい情報は、ほぼこのプラグインで網羅できる。便利なツールが無料公開されていて助かった。こういう補助ツールが充実しているのも、WordPressを使っていてありがたいと感じる点だ。
スラッグの命名規則について
書き出したCSVをExcelで開いたら、編集しやすいように列を入れ替える。自分の場合は左にpostname、右に記事タイトルを並べて、表題から思いつく文字列を設定するようにした。
単語の間に入れる記号は、Googleによるとアンダーバーよりハイフンが推奨。個人的には前者の方が好みだが、ここはGoogleルールに従うことにする。
TwitterやInstagramのユーザー名だと、逆にハイフンが使えずアンダーバーのみ。FacebookページのURLはピリオド区切り。このあたりの仕様はいつか誰かが統一してほしいものだ。
記事URLに単語を入れる場合、できるだけ詳しく具体的内容を示すようにした方がよいのだろう。そのあたりはプログラミングの変数名で、可読性を高めるため冗長に設定するのと同じ。もし記事URL内のキーワードが検索順位に影響するとしたら、変な略称・接尾辞・接頭辞などは避けた方がよさそうだ。
しかしこれをやり始めると、とてつもなくURLが長くなってしまう。ユーザーにとって、記事内容以外の視覚的ノイズは少ない方がいい。そしてスラッグ名は短い方が、すっきりして見栄えがいいし、管理の手間も省ける。
今回はpost_idの数字羅列と間をとって、1～2語で収まる程度の命名にとどめた。特に根拠はなく、好みの問題。
本記事のURLもできるだけ正確に表現すれば、wordpress-url-setting-postname-from-post-idとかの方が丁寧だろう。しかし今回は省略・短縮してwp-postnameくらいにとどめておいた。
記事を固有名で管理する利点
スラッグ名が短い単語だと、後でうっかり同じ名前を設定してしまうおそれがある。postnameがかぶるとWordPress側で自動的に-2、-3…と接尾辞を追加してくれるが、これは見栄えがよくない。スラッグが、公開していない下書きや保留状態の記事と干渉してしまうこともある。
その点、記事IDは固有値のため、ほかの記事と絶対にかぶらない。毎日5記事くらいアップするペースだと、ほかとかぶらないスラッグ名を考えるのが面倒になる。そのためシンプルにpost_idを採用した経緯がある。
最近は下調べや推敲に時間をかけるようになり、ブログの更新ペースが下がった。記事ごとにスラッグをつけるのも、たいして苦にならない。
そして自動的に振られるIDより固有名で管理した方が、記事に対する愛着も湧く。postnameをURLに反映した方が、ていねいに記事を書くモチベーションにつながると思う。
問題点としては、英単語のスペルが間違っていたりすると恥ずかしい思いをする点だ。後で違う名前に変えたくなるのも困る。そのため今回は単語の選定に相当時間をかけた。
SQLは使わないで手作業
満足のいくまでpostnameの編集が終わったら、ExcelからWordPressの記事情報へスラッグ文字列をコピペする。
管理画面には記事本文を開かず属性情報だけ見ることができる「クイック編集」という機能がある。これを使えば作業は楽だが、記事1個ずつ設定していくので、それなりの手間がかかる。
SQLを書いてデータベースを直接いじる方法もあるが、よからぬ障害を招くおそれがある。DBからエクスポートするのは楽だが、インポートをミスって変に上書きするのが怖い。
今回の作業はおそらく一度限り。調べた限り、目的にかなうソースのサンプルも見つからなかった。そこで試行錯誤して設定を自動化するより、手作業で片づける方が早いと判断した。
単調作業は嫌いでない。マウスをカチカチクリックして、数百記事分のスラッグ情報をコピペしながら、久々に仕事をしている気分を味わえた。自分のブログならましだが、会社の業務でやらされるとしたら、時給5,000円くらいもらわないと割に合わない苦痛な作業といえる。
マウスボタンを用いた単調作業効率化
以下の4ステップを効率化するため、マウスの補助ボタンを活用した。
- エクセルから該当セルを選んで文字列をコピー
- 該当記事のクイック編集ボタンをクリック
- スラッグの既存文字列を範囲選択してペースト
- 更新ボタンをクリックするか、Entarキーを押して編集確定
Logicoolのゲーミングマウスについてくる付属ソフトで、ホイール下のミニボタンにコピー（Ctrl+C）、親指側の戻る/進むボタンに貼り付け（Ctrl+V）とEnterキーを割り当てた。
右手の親指は、マウス左側面のEnter化したボタンに固定。もうひとつのサムボタンに指をずらすと握り替えが必要になり、余計な筋肉を使ってしまう。そこで貼り付けに割り当てたボタンの方は、左手で押すようにする。
こうするとマウスを両手でつかんだ状態で、一切キーボードに触れることなく一連の作業をこなせる。マウスの移動距離も最小化できて、かなり効率的に作業を進めることができた。
あとから考えると、サムボタンでなく右クリックボタンにコピペかEnterを割り当てた方が押しやすかった。右クリックを外してカスタムしようとすると、「右クリックは最低1ボタンに割り当てが必要」とエラーが出る。先に親指ボタンに右クリック機能を退避しておけば、右ボタンにも問題なく別の機能を割り当てできるとわかった（確認済み）。
単調作業も数百回・数時間におよぶと腱鞘炎など様々な健康リスクが生じる。ブログの執筆も30分に1回くらいは席を立って、肩や首のストレッチをするのがベターだ。歳をとるほど意識的に体のメンテナンスが必要になる。
301リダイレクト文の作成
全記事へのスラッグ割り当てが終わったら、いよいよ管理画面でパーマリンクをpostnameに変更。そしてExcel側で整形したリダイレクト文をテキストエディターにコピペして、区切り文字のTabを削除。ウェブサイトの.htaccessへ追記する。
転送機能は問題なくはたらき、内部/外部リンクとも新URLへリダイレクトされるようになった。その後一週間ほどして、Googleに出る検索結果も新しいURLへと入れ替わった。
URL変更後、PVに変化なし
パーマリンク変更によって懸念されたSEO面のデメリットについて、今のところ目立った変化は出ていない。一週間程度の観察だが、設定変更前とアクセス数は変わらず推移している。
URLに単語名を入れたことで、SEO効果がアップした分、デメリットが相殺されたのかもしれない。そのあたりのGoogle評価基準については何とも言えない。結局のところ、同じサイト内で記事URLを変える（転送する）ことは、たいして検索順位に影響を及ぼさない可能性もある。
もしまたしばらくしてから記事URLをIDに戻したくなったら、WordPressのパーマリンク設定を変更するだけで自動転送がきく。とにかく記事を書く際は、面倒くさがらずにスラッグもつけておいた方が、後々サイトを管理しやすく手間も減ると実感した。
