WordPressにおいて人生をやり直す方法

WordPressサーバ移転

Twitterで、「今のブログは一旦リセット!過去の気に入らん記事も全部消す!面倒さいけどやってやる!!これが正しいと信じてる!呪術廻戦って面白い!」というコメントを見かけた。

呪術廻戦が面白いことには賛成するけれども、どうも今一つWordPressを理解できていないような気もする。
そこでブログにおいてセカンドインパクトもニア・サードインパクトも経験したぼくが、WordPressにおいて人生をやり直すというのが、一体どういうことなのかを語らせて頂くことにする。

なお当記事は、あくまでWordPressに関する体験談である。人生をWordPressでやり直すという怪しげな話ではないことを、あらかじめお断りしておきたい。

また上記の通りで、アクセスは一気に激減する。どんなに頑張っても、リセット後に新記事を作成開始したのでは数記事が限界だ。大幅にアクセス激減して当然だ。
おまけにドメインパワーが蓄積されてから、URLを引き続き利用するのだけれども、どうも新記事にはドメインパワーが効かないような気もする。ここら辺は検索エンジンたちの評価次第なので、真実を知るのはエンジン開発者やその関係者だけだ。

都合の良い部分だけリセットするというのは、なかなかムズカシイ。やれやれ。

ファーストインパクト

ぼくは2005年9月22日に、ニフティのココログ(red-brick.cocolog-nifty)を開設した。実は長老クラスのブロガーだったりする。

しかしココログのブログを参照しても、本当に開設日が2005年9月22日であることしか分からない。昔の記事は全て削除してしまい、検索エンジンにキャッシュも残っていない。
おそらくココログ以外も同様だと思うけれども、こういったブログサービスの記事を一つ消すのは簡単だ。サクっと全記事を削除してしまえば、それで終わりである … なんてことは、全くない。

さすがに2005年頃の投稿記事は、今読むと恥ずかしい。そこである時にがんばって、数百記事を全て削除してみた。
で、新記事を投稿しようとして、ふと気がついた。「画像は全く削除されていない」ということを。
そこで少し心配になって、Google検索エンジン神にお伺いを立ててみた。そしたら恐ろしいことに、検索エンジンではゴミのような情報に山ほどヒットする。で、クリックしてみると、本当にゴミのようなデータが存在した。

つまり安全策なのかもしれないけれども、単純にココログの管理画面から記事を削除しただけでは、投稿記事は削除されないことになっているのだ。いざとなったらエヴァンゲリオンのシンジ君のように、サルベージすることが可能になっている。

で、結局はブログそのもの(nekoboko)を削除した。そうしたらnekobokoディレクトリが削除されて、検索エンジンにはキャッシュだけが残るようになった。
それから今度は新たに世界を作り直すというか、もう一度nekobokoディレクトリ名で別ブログを新設した。そうしたら新ブログのサイトマップ情報をGoogle Search Consoleが読み取ってくれて、Google検索エンジンのキャッシュデータもクリアされた。

こうやってエヴァンゲリオンのように、世界 … というか、ぼくのココログは再創造された訳である。現在も継続して残っているのは、画像データとred-brick開設日(2005年9月22日)だけだ。ちなみにその気になれば、これも削除(アカウント削除)してから再び設置することが出来る。
しかしながら流石に勿体ないので、そこまでやるつもりはない。

投稿記事はパソコンにバックアップとしてエクスポートしてあるので、その気になれば全く同じ世界… というか同一ブログを再構築可能だ。しかしred-brickを削除してしまうと、2005年9月22日の日付が抹消されてしまう。そして画像データは一枚一枚の手動バックアップが必要だ。

ちなみに過去記事を全削除した時、Google Search Consoleは何も言って来なかった。そんな訳でファーストインパクトは、セカンドやニア・サードよりは心穏やかなエンディングで済んだ。

そのために少し調子に乗ってタカをくくってしまい、セカンド・インパクトで大変な目に遭遇する結果となった訳である。

セカンドインパクト

さてココログは手間がかかるだけで済んだので、試みにWordPressで構築したbike-nekoドットコムをサーバ移転してみた。で、そこの人生(投稿記事)の大半を喪失する事態に遭遇した。

WordPressブログは、MySQLデータベース(DB)とフォルダ収納されたスクリプト&画像データで構成されている。そして記事データは、何とMy SQLに収納されている。

ぼくは元技術者なので、てっきりMySQLに保存されているのは「どんなデータがどこに存在するか」といった類に過ぎないと思い込んでいた。だって記事データまで収納したら、動作速度が低下する危険性がある。
ところが「事実は小説よりも奇なり」というか、上記で報告した通り、記事本体がMySQLに収納されている。道理で「記事の修正ログは過去2バージョン程度に限定しないと、記事数が多くなった時にWordPress動作が遅くなる可能性がある」というアドバイスが存在する訳である。

(アドバイスに従って、ぼくは2リビジョンにしている。設定が出来ているかどうかは、WordPress投稿記事の管理画面の公開情報欄で確認できる)

当時のぼくはこういった辺りを全く考慮せず、「いざとなったらフォルダにテキストデータとして保存されている記事データをサルベージすれば大丈夫だろう」と超楽観的だった。
だってファーストインパクトの時に見たココログは、そのようになっていたのだから。

で、さらにbike-nekoドットコムをサーバ移転させる時にバックアップがちゃんと取れていると信じて、MySQLで作成したデータベースまで削除してしまった。知らずして、ブログを消滅させてしまった訳だ。

そして事態は、単に今までの投稿記事を消滅させただけでは済まなかった。Google Search Consoleにアクセスすると、「URLにアクセス出来なくなりましたっ!」と警告メッセージが出力されるようになってしまった。
そうなのだ。一度Google検索エンジンにインデックス登録されたURLは、削除手続きなどを実施しないと、その後も延々と警告メッセージに悩まされることになる。

しかし逆にSearch Consoleの警告メッセージが、ぼくの場合には “救いの女神” となった。
なぜなら警告メッセージはURL単位(記事単位)で出力されるので、そのURLで検索エンジン神にお伺いを立てることが出来る。そうするとブログ消滅して間もないため、キャッシュデータを参照することが出来る。

つまりぼくの場合、新サーバ上でbike-nekoドットコムURLのWordPressブログをゼロから再作成し、そこで一つ一つ過去記事を復活(新規投稿)させた訳である。
今にして思えば、自分としては二番目にアクセスの多いブログだったとはいえ、よくまあ心が折れなかったと感心する。

それにしてもレンタルサーバのバックアップソフトウェアは手間暇かけて作成されているように見えるけれども、どうしてMySQLのバックアップを取得してくれないのだろうか。
こちらがWordPressの本体であり、フォルダのデータだけならばFTPツールによって、自分のパソコンにバックアップを取ることが出来る。

ともかく人類というか、ぼくだけに限定されるけれども、心に大きな傷を残しながらセカンドインパクトは幕を閉じた。

ニア・サードインパクト

さてセカンドインパクトで懲りていたのに、とうとう最もアクセスの多い主力ブログでニア・サードインパクトを体験することになった。

本当はサード・インパクトの引き金を引くような真似はしたくなかった。けれどもWordPressブログ初回構築時に、主力ブログに致命的欠陥を作り込んでいた。
性能の問題だったら放置するけれども、セキュリティ方面の致命的欠陥である。間違っても世間に迷惑はかける事態は起こしたくない。(サイトを乗っ取られる等)
しかし最もアクセスの多いブログなので、削除するのも勿体ない。そこで碇シンジ君のように、「逃げちゃダメだ」と主力ブログの新ドメイン移転に立ち向かうことにした。

それだけニア・サードインパクトの時には、本気になった。
WordPressの解説本を読み、テスト用のサイトで検証作業をやってノウハウを蓄積し、最終的には全ブログのMySQLデータとフォルダ情報の全てを自分のパソコンへ完全バックアップできるようになった。
さらにMySQLのテーブルを書き換えることも出来るようになり、もはやプロを教育できる領域にまで達してしまった。もともとプログラマーだったおかげでPHPも書き換え出来る。そのうち解説本を書いても良いかもしれない。

そんなエラそうなことを言っているけれども、実は昨日までトラップにハマっていた。
WordPressブログのバックアップ・リカバリをするのは、サーバ移転が目的であることが多い。ドメインだけでなくサーバ名も変わるので、プラグイン(WP Super Cacheが構成ファイルに絶対パスでURLを書き込む罠があった)問題なども克服できることが必要になる。

そこまではオッケーだった。

しかし … Google Search Consoleからの警告メッセージを封じるため、RewriteRuleをhtaccessファイルに700行も書いたけれども、その時に余計なものまで入れてしまった。(URL変更したのだけれども、元URLも継続利用したくてRedirectは使わなかった)

この人気ブログランキングに登録して気付いたけれどもRSSフィードまでRewriteRuleしていたのだ。つまりnekobokoドットコム/feedへのアクセスを、yotsubaseiドットコム/feedに転送していた訳である。(ランキングが上がらないので更新エリアをチェックして、ようやくそのことに気がついた。面目ない)

もちろん700行に及ぶRewriteRuleを手打ちしたら、本当に心が折れてしまう。そこでGoogle Search ConsoleのカバレッジデータをExcelにエクスポートして、それをconatenete関数などを使って入力データに変換した。このデータを真面目にチェックしなかったのが敗因だった。

とりあえず現時点はRSS問題も解消し、全く問題は存在しないように見える。

そんな訳でドタバタしたけれども、もう大丈夫だと思う。エヴァンゲリオン劇場版も無事に最終章が終わったし、ぼくのブログ環境も落ち着いたと思う。いや、お願いだから、もうこれ以上は何も起こって欲しくないと、ひたすら平和な日々が続くのを祈るのであった。

まとめ

ちょっと端折って書いたので分かりにくいけれども、以上が「WordPressにおいて人生をやり直す」、つまり旧WordPressブログを別URL(yotsubaseiドットコム)に移転し、元URL(nekobokoドットコム)に新WordPressブログを構築するということである。

  • 元ブログのMySQLとフォルダをパソコンにバックアップ(FTPやDBツールでエクスポート)
  • 元ブログのWordPress管理画面で移転後URLを記述
  • FTP等を通じてWordPressの設定データ(DB名やWP Super CacheのCache保存場所)を書き換え
  • マルチドメインの場合は、ディレクトリ情報を書き換え
  • 移転先URLでAdsense等を登録済でない場合は、それらを再申請
  • 移転元URL用にWordPressを新規インストール(MySQLデータベースも新規作成)
  • RewriteRuteで既存記事を移転先WordPressへ行くように設定
  • Search ConsoleやAnalyticsでも問題ないことを確認して作業終了

最終的には、呪術廻戦のアニメを見ながらサクサクと作業できるようになった。焼肉を食べながらだって大丈夫だ。

しかし最初は大変だと思う。そしてプログラマーとして経験に照らし合わせると、「面倒」ということは全くない。

あと「過去記事を消す」というのは少し変な話でもある。それはSearch ConsoleでURL削除申請をかけて、チマチマと記事を全面書き換えすれば良いだけのハズだ。そして削除申請は、いつでも取り消し可能である。

と、いうことで、Twitterでは141文字なので端折ったのかもしれないけれども、人生をやり直すのであれば「まず基本を勉強していますか?」と問いかけたい。一度しっかりと基本を身に付ければ、その後がずっと楽になる。

… と、セカンドインパクトを経験する前の自分にも、可能だった言っておきたい今日この頃だったりする。(本当にファーストインパクトの経験で、調子に乗り過ぎましたな)

それでは今回は、この辺で。ではまた。

————————————–
記事作成:小野谷静 (おのたにせい)