このブログを立ち上げて4ヶ月が経ちます。
やっとWordPressの使い方にも慣れてきた感じがします。

実はWordPress自体は、2007年のバージョン2.Xの頃から使っていました。
当時、ブログと言えば、ほぼ100％「Movable Type」という時代。

WordPressは、現在とは正反対で超マイナーなCMSでした。
今で言えばDrupalやJoomlaみたいな存在でした。

ですから、参考になるサイトや書籍もほとんどなく、WordPressはなんとか独学で覚えてきたという経緯があります。

手抜き運用したていたツケ

しかも、WordPressはサブサイト＝おまけのブログとして使っていました。Drupalのような汎用CMSが普及する以前は、ブログ以外のホームページ運用は本当に本当に、本当にいや本当に手間のかかるしんどいものでした。

運悪く私が初めてサイトを構築した年、2007年は、サイト運用者にとって「受難の年」だっと思います。WEBの関する様々な変革がいくつも同時に起きた時代。

冗談抜きで猫の手を何百個も借りたい状態でした。でも猫大好きなので、本当に猫ちゃんの手が出てきたら遊んでしまっていたでしょう。そんな状態ですから、ほとんど勉強する時間もないままWordPressを使用していのです。

このサイトはブログということで、あまり深く考えずWordPressを採用しました。初めてメインサイトをWordPressで運用するにあたり、約10年越しでWordPressについて改めて本気で勉強し直したという経緯があります。

そこで痛感したことがあります。

それは、WordPressの運営には、ちゃんとした手順・順番があるということです。
その順番を間違えると、二度手間、三度手間どころの問題じゃなくなることを身をもって知らされましたのです。

他の方には、そんな面倒な思いをして欲しくありません。ですから使用歴は長いけど初心者の私が分かる範囲で、その順番について書いてみたいと思います。ちょっと長いので2部構成にします。今回は前編です。「子テーマ」と「パーマリンク設定」についてです。

本当に書きたいのは次回の「セキュリティー対策」の方です。今回の記事は、他サイトでも紹介されていることです。すでに知っているという方は、次回をお待ちください。

ほんの少し前のサイト運営者はプログラマーだった

本論に入る前に少しだけ余談をさせて下さい。たかだか10年弱前の昔話をします。興味の無い方、お急ぎの方は「最初は子テーマとパーマリンク設定」へどうぞ。

私は、2007年～2012年までHTML・PHP混在の手打ちサイト。
その後リニューアルでは、DrupalというCMSを2013年～2016年2月まで使っていました。

Drupalは超難解なCMSですが、それでも手打ちの頃に比べれば、随分楽だと痛感しました。

Drupalに関しては「Drupal Hell（Drupal地獄）」という単語があります。そのくらい難解な「汎用CMS」が何故楽に感じたかというと、最初にサイトを立ち上げた2007年頃には、「汎用CMS」そのものが無かったからです。ただしブログ専用ということであれば、Movable Typeはありました。

Drupal Hell（Drupal地獄）なんてへっちゃら

汎用CMSが無いだけでなく2007年頃は色々な変革が波状攻撃でやってきました。それらに対応するのでもう四苦八苦。本当につらかった。具体的には以下の様なことが起こっていました。

今でも、メイリオ非対応のホームページは、レイアウトが崩れてますよね。

これらの中でもCSSハックと、メイリオ対応ページにレイアウト変更することは、本当に大変な作業でした。ですから、なおのこと、WordPressについて勉強する余裕がなかったのです。

ちなみに、サブサイト＝おまけのブログを当時マイナーだったWordPressで運営した理由はただひとつ。手打ちサイトの方でPHPを実装し、PHPの便利さだけでなく、もう静的ページはもう終了、Apache+PHP+MySQLの動的ページが時代が来ると実感したからです。

最低4つのコードが必要だった

汎用CMSが無かった時代。一般サイトの運営者は、上に挙げた改革の波状攻撃に対応する以外にも少なくとも4つのコードを絶対に習得する必要がありました（Flashは任意）。

1つはもちろんHTMLタグです。正確に言えば当時はXHTMLタグでした。しかし、XHTMLタグだけで作ったページは何の面白みもないただのページ。ですから、以下のようなコードも習得する必要があったのです。

JavaScriptも自分で書いていた

CSSについても積もる話がありますが割愛。でもこれだけ書かせて下さい。現在標準のCSSによるボックスレイアウトの歴史は結構浅いということです。

ちょうどIE7が「とりあえず」のCSS「標準準拠」をしだしたのは確か2006年末頃。それ以前は、CSSでレイアウトではなく、<table>タグを使ったテーブルレイアウト、もう廃止になった<frame>タグを使ったレイアウトの方が結構一般的でした。

ですから2007年時点でも、CSSによるボックスレイアウトというのものは比較的新しい概念。新たにCSSのボックスレイアウトの目的と方法について、勉強する必要もあったのです。

また当時は、「jQuery」などの「JavaScriptライブラリ」も浸透はしていませんでした。多分「jQuery」自体はリリースはされていたと記憶しています。しかし、はっきり言って浸透はしてませんでした。

ですから難解なJavaScriptも必死で勉強して、自分でスクリプトを設計し自サイトに埋め込んでいました。2000年代前半のサイト運営者は、今よりかなりプログラマーに近い存在でした。

ちなみに、自分でJavaScriptを書かないと、「ドロップダウンメニュー」さえ実装できなかったのです。素人が色々とJavaScriptを書いていくと、大体バグが発生します。ですからそのデバグにも大変な時間を費やしたものです。

CGIも自分で書いていた

CGIなんてもう死語に近いですね。でもPHPが浸透するまでは、サイト運営者は、CGIというサーバーサイドで働くプログラムを書かないといけませんでした。

そうしないと、「お問い合わせフォーム」さえ実装できなかったのです。今考えると「お問い合わせフォーム」がないサイトなんてありえないですよね。でもその実装作業は本当に大変だったのです。

あとは「サイト内検索」なんかも昔はCGIで実装。さすがに「サイト内検索」については、最初からプログラミングするのはきついので、私は「namazu」を使っていました。これももう知っている人は少ないでしょう。

CGIを作成する際にに使われていた言語がPerlでした。ここでPerlを習得したことは、PHPへの移行を少し楽にしてくれました（両者はほぼ構文が共通）。

つまり、最低この4つのコードについて勉強しないと、手打ちサイトは運用できなかったのです。これだけではなく2007年頃には、前に触れた大変革が襲ってきたのですから、もう絶対にWordPressについて勉強する余裕なんて1秒も無かったのです。冗談じゃなく猫の手が何百個も欲しかったのです。

その他、人によってはFlashを使う人もいました。私もそのうちの一人です。本当にちょっとしたアニメーションだったのですけど、FlashをWebで使うには、AS（アクションスクリプト）を覚える必要もありました。

これも余談ですが、Flash使いにとって、Flashが廃止になることは非常に残念です。

最初は子テーマとパーマリンク設定

さて本題に戻ります。

WordPress「独学者」が初めにすべき点は実は、WordPress 独学者にありがちな９つの致命的な失敗にほとんど書かれていますので、余裕がある方はそちらもご参照ください。

今回と次回の記事では、SEO、セキュリティー面において、WordPress運営者が【最初に】するべき4つのことをまとめています。

ただし、内容はどちらかと言えば、次回に記載するセキュリティー面の方に重きを置いてあります。繰り返しになりますが、子テーマとパーマリンクの推奨設定についてご存知の方は、次回をお待ち下さい。

子テーマを作る

「子テーマを作る」というのは、必ず一番目にすべき事、あるいはそれほど重大なことではないと思っています。特にローカルにバックアップ環境を構築している人は別に必ず最初にやる必要は無いかもしれません。本当に一番最初にすべきは、パーマリンクを「投稿名」に設定することです。

しかし、多くの方が、最初にテーマを選んで、それから投稿を始めると思います。今回はそうした実態に沿って、あえて最初に子テーマについて取り上げてみます。

子テーマの作成手順

子テーマのメリット等はあえて後で説明します。先に作成手順を説明します。

まず使いたいテーマを決めたら、同階層（wp-content/themes/）に子テーマ用のフォルダを作成します。
私の場合は、親となるテーマが「twentytirteen」なので、同階層に「twentythirteen-child」というフォルダを作りました。

つまり「使いたいテーマの名前」の後に単に「-child」を付けたフォルダを作成すればいいのです。

子テーマフォルダの中身

以上の手順で作成せいた「○○-child」というフォルダには、最低以下の2つのファイルを作成します。

繰り返しになりますが、子テーマの作成方法については、多くのサイトで紹介がされています。

しかし、未だに「style.css」の中に「@import url('../親テーマ名/style.css');」を記述するよう説明しているサイトがたくさんあります。しかし、この方法はサイトのパフォーマンスを低下させるので、現在「非推奨」となっています。そのようなサイトは古いので参考にしないでください。

@importは非推奨・不要

まずstyle.cssの中身ですが、これも多くのサイトで取り上げられています。しかし、単純に以下のように記載すれば大丈夫です。twentythirtennが親テーマだとした場合は、以下の記載だけで大丈夫です。

最初の/*と、最後の*/は必須です。

Theme Name:ここに子テーマの名前を記述します。単純に「親テーマ名-child」で大丈夫です。

次のTemplate:には「親テーマ名」をそのまま記述します。
以上です。

続いて「@import url('../親テーマ名/style.css');」の記述するよう解説しているサイトの方がまだ多いですけど、その記述は不要ですし、非推奨です。

もちろん、ここで作成したstyle.cssに、自分で作ったcssコードを追記してもいいのですが、それよりは「Simple Custom CSS」をプラグインを使った方が便利です。「Simple Custom CSS」を使っている人は、以上2つの記述さえあれば大丈夫です。

functions.phpの中身

functions.phpの中身は以下のように記述してください。

もちろんPHPコードなので、最初は<?phpで、最後は?>で必ずくくります。

これより短い以下のコードでも大丈夫なようですが、上のコードの方が確実です。

ちなみに、今後独自に関数を加えたい場合は、最後の?>の前に追記していって下さい。以上で子テーマの最低限の設定は完了です。

その後、管理画面にログインします。

そして、外観＞テーマの中に今作った「親テーマ名-child」という子テーマが出来上がっていますので、それを有効にすれば完了です。

テンプレートファイルを修正する場合

もし、親テーマのテンプレートファイルに修正を加えたい場合は、そのテンプレートファイルだけを、子テーマフォルダの中にコピーします。

その後は、そのコピーしたテンプレートファイルの方を修正します。そうすると、修正した子テーマのテンプレートファイルの方が優先して読み込まれるようになります。

もうこれで、子テーマを作る目的・メリットはお分かりいただけたと思います。

つまり、修正を加えたfunctions.phpとテンプレートファイルを避けておくことで、親テーマが更新されても、カスタマイズした内容が消えずに残るのです。親テーマが更新されても、せっかくカスタマイズした内容が上書きされ、消されなくても済むということです。

この仕組はDrupalでは無かったので、とても新鮮でためになりました。

Drupalにも「サブテーマ」というものがありました。私が知らなかっただけです。訂正します。

とは言え、私はローカルに本番と同じ環境を構築しています。ですから最悪、本番環境でカスタマイズした内容が上書きされても、ローカルに元ファイルがあるので、復旧はできます。

そういう意味では、子テーマの作成は後回でもそんなにダメージはありません。
一番ダメージがあるのは、後になってパーマリンクを変更することです。

パーマリンクは「投稿名」で

WordPressでサイト運用する際に、「最初の最初に」設定しなければならいのは、パーマリンクの設定です。

最初にSEOを考慮せず後になってから、パーマリンクを変更するのは本当に大変です。かくいう私も、14記事ぐらい公開した後、一個一個URLの修正したという経験があります。公開済みURLの修正は地道で大変な作業です。

そんなことにならないよう、まずは、一番最初にパーリンクの設定を「投稿名」（またはカスタム構造の「カテゴリ名/投稿名」）で設定しましょう。

基本と数字ベースは絶対選んではいけない

WordPressのデフォルトで6つのパーマリンク設定が用意されています。

この中で絶対に選んではいけないのは、以下の2つです。

実は私も最初の頃は、数字ベースのパーマリンクを使用していました。

なぜ、数字ベースを選んでいたかというと、「日付と投稿名」、「月と投稿名」、「投稿名」だと、URLに日本語（＝投稿名のタイトル）が入ってしまうと思っていたからです。

日本語URLの問題

日本語URLはどうしても長くなりがちです。長いURLはSEO的にはあまり良くはありません。

日本語URLが誕生してから10年ぐらいになるのでしょうか。もう今は検索エンジン側としては、日本語URLでも問題はないようです。しかし依然、日本語URLには以下の問題があります。

以上の問題があるので、日本語URLを避けるためだけの目的で、私はずっと数字ベースのURLを使っていました。

数字ベースのデメリット

しかし数字ベースのURLにも以下のデメリットがあります。

中でもURLにキーワードが入れられないのが致命的だと思います。

Google社の上級管理者によると「URLにキーワードが入っていると、非常に小さなものではあるが、上位表示へのSEO効果はある」そうです（参考：URLにキーワードを入れると「SEO効果あり」？／Google明かす）。

ですから、数字ベースと基本（?p=投稿ID）の数字系パーマリンクは、SEO上有利ではないと言えるのです。

また記事が増えるごとに、数字がどんどん増えていくのは、管理者にとっても面倒です。どのURLがどの記事に対応しているかが、非常に分かりにくくなっていきます。そんな状態でサーバーの移転などする場合、非常に苦労するのは目に見えています。

「投稿名」または「カテゴリ名/投稿名」で

この2点を考慮すると、推奨のパーマリンク設定は「投稿名」で決定だと思います。

カスタム構造で「カテゴリ名/投稿名」＝「/%category%/%postname%/」とするやり方も良いかもしれません。カテゴリ名と投稿名でそれぞれキーワードが入れられるのですから、SEO上も有利でしょう。

でも、「カテゴリ名/投稿名」は個人的には絶対おすすめしません。

なぜなら、後でカテゴリを変更した場合、その記事のURLが変わってしまうからです。

カテゴリにちゃんとスラッグ（slug）を入れていた場合は、カテゴリの名前の変更をしただけでは、URLは変わりません。ですから必ずカテゴリにはスラッグを付けましょう。

しかし記事のカテゴリそのものを変更したら、確実にURLが変わります。サイトの方針がガッチリしていない間は、カテゴリの変更はもちろん、カテゴリの追加・削除はよくあることです。ですから、「カテゴリ名/投稿名」のパーマリンクはやめたほうが賢明だと思います。

それと、「投稿名」に比べ少しですがURLが長くなるのも多少のデメリットです。

「投稿名」にする際のデメリット

とはいえ、パーマリンク設定を「投稿名」にした場合、デフォルトでは記事のタイトルそのものがURLになってしまいます。つまり、日本語URLになるのです。

日本語URLで問題ないという人は、ここで設定は終わりです。

しかし、前述のとおり、日本語URLにはいくつかのデメリットがあります。私はやらないので、前では触れませんでしたが、特にSNS系サービスで日本語URLがシェアされると、日本語がUTF-8でエンコードされ謎の文字列と化すことが多いようです。

それ以外にもまだまだ改善点があるので、やっぱりまだまだ日本語URLは個人的には推奨しません。

ではどうすればいいのでしょうか？

各記事ごとにURLを設定する

やり方は1つしかありません。各記事ごとに、「いちいち」日本語URLをアルファベットURLに書き換えるのです。WordPressではそれしか方法がありません。他にやり方はあるのでしょうけど、そんなトリックが必要と知っていたら、最初からDrupalを使ってました。

話を戻します。やり方は簡単です。
記事のタイトルの下に「パーマリンク」という項目があります。
WordPressでは、ここに勝手に記事の日本語タイトルが張り付きます（この辺がDrupalより劣る点です）。

その右横の「編集」ボタンを押下して、URLを書き換えるのです。WordPressではそれ以外方法がありません。

多分アルファベットURL用のカスタムフィールドを作って、それを呼び出す方法もあると思うのですが、それをするぐらいなら、最初からDrupalでブログをやった方が簡単です。

アルファベットURLにする際のコツ

以上のような手順で日本語URL→アルファベットURLに変更することはできます。
その際注意すべき点は以下の4つです。

キーワード同士は「_」アンダーバーではなく必ず「-」ハイフンでつなぎましょう。重大な影響はないと思いますが、Google様がそう仰ってるのそうしましょう。

必ずリダイレクトしましょう

推奨のパーマリンク設定についての説明は以上です。

すでに他のパーマリンク設定でWordPressを運用していた人は、公開記事が20本程度であれば今からでも遅くありません。「投稿名」にパーマリンクを変更しましょう。

既存の記事のURLの変更方法は、上記の方法と同じです。つまり、記事タイトル下の「パーマリンク」項目の「編集」をクリックして、1個づつURLを変更するのです。しんどいかもしれませんが、これが運営手順・順番をも守れなかった（正確には知らなかった、教えてもらわなかった）ツケです。仕方ありません。これは誰でも手軽に、順番あべこべでも運用できるCMSの落とし穴です。

全ての記事のURLを変更したら、必ずリダイレクトしましょう。

.htaccessについて熟知している人は、.htaccessでリダイレクトする方法もありです。

Redirectionプラグインの方を使いましょう

とはいえ今から.htaccessについて勉強するのは非効率でしょう。しかし、幸いWordPressには、リダイレクト用のプラグインが2つあります。

このうち私が推奨するのは「Redirection」の方です。こっちの方が面倒ですが、確実で正確なリダイレクトができます。

Permalink Redirectの方がはるかに楽

正直に言えば、「Permalink Redirect」の方がはるかに楽です。

・参考サイト：[WordPress]パーマリンクの変更時に便利！新しいURLへリダイレクトしてくれるプラグイン「Permalink Redirect」 | DelightMode（ディライトモード）

Permalink Redirectの不具合

一方、「Redirection」の方は、各記事ごとに転送（リディレクション）ルールを書かないといけません。20記事あれば、20個の転送ルールを書かないといけません。その点は.htaccessによるリダイレクトと同じです。それなら「Permalink Redirect」の方が楽でいいじゃないかと思うでしょう。

しかし、私の場合以下の不具合に遭遇したので、経験上推奨はしません。

例えば、「数字ベース」のURL：http://example.com/archives/40 （数字は投稿ID）を「投稿名」ベースで以下のパーマリンクに変更したとします。

http://example.com/archives/40 → http://example.com/test

この記事を「Permalink Redirect」の方でリダイレクトさせると、なんと正しいURLと誤ったURLの2つが出来てしまったのです。

これはプラグインの不具合なのか、私の設定ミスなのか結局分かりませんでした。しかし、こういった不具合は「Redirection」ではまず起こりません。確実に正確にリダイレクトしてくれます。面倒でも「Redirection」を使いましょう。

・参考サイト：WordPressリダイレクト用プラグイン「Redirection」のススメ

一気にやらなくても良い

こうした方法で、パーマリンク設定を推奨の「投稿名」に後から変更することは可能です。Googleの場合、URL変更は大体2～3週間程度で反映しました。

「でもうちは既に数十個も記事を公開している。今更の変更は面倒」と思う人もいるかもしれません。私はそういう場合は、アクセスの多い記事から順々にURL変更＋リダイレクトをすれば良いと思います。一気に全部やる必要はありません。負担が大きすぎます。

また、アクセスの少ない記事、サイトへの影響の少ない記事は、もうこの際リダイレクトはしなくても良いんじゃないでしょうか？

あまり影響の無い記事はリダイレクトの手間を省いて、検索サイトにじっくり再インデックスされるのを待てばいいと思います。

SEO上のことばかりで説明してきましたが、数字ベースのURLはやっぱり管理がしにくいです。サーバーの引越しなども考慮すると、機械的な数字ベースのURLよりは、人が管理しやすい「投稿名」ベースのURLにこの際、変更するほうが大きな手間でも長期的には利益になると思います。

「はじめに」が無いのが致命的欠点

では何でWordPressユーザーはこうしたトラブルに巻き込まれるのでしょうか？

「商品」、例えば家電やソフトウェアを購入した場合、必ず分厚い「取扱説明書本体」の他に「はじめに」、「スタートガイド」といった短い冊子が別で付属します。我々は必ず「はじめに」の方を先に読みます。そのことで、トラブルなく「商品」を使うことができます。

WordPressに関して言えば、この「はじめに」、「スタートガイド」に当たる物が存在しないのだと思います。誰でも簡単に、順序あべこべでも運用できる「利便性」というのも、その原因の1つでしょう。

「WordPress神推しブログのネタワン」さんとかはそんな部類のサイトです（リンクは張りません）。なおかつ、内容が薄いです。何が神推し何でしょうか？私は「Personal Block List」でブロックしています。

プラグインの紹介やテーマのカスタマイズ方法は、「はじめに」ではなく「取扱説明書本体」の方です。

子テーマとパーマリンクのトラブルは、現代日本人の「人生」とは違って、後でやり直しが効きます。しかし、セキュリティ面でのトラブルはやり直せません。WordPressはDrupalに比べ、セキュリティーが甘すぎです。

WordPressはセキュリティー甘すぎ

たとえば一般人の私でさえ、あなたのログインIDを盗み取ることは瞬殺で可能。後はパスワード解析ができれば、WordPressサイトは簡単に乗っ取れます。

そんな目にあって泣きを見ることが無いように、次回はセキュリティー面における「はじめに」、「スタートガイド」に当たる物を書いてみたいと思います。

• Tweet