robots.txtでやらかした!

IMG_6444

robots.txtの設定をミスって、ウェブマスターツールに「重要なエラー」って言われてしまいました。てへ。

しかもしばらくどこが原因かわからなかったという(涙)

・ robots.txtってなんぞ?

まず、robots.txtが何か、これを何のために設定するかを知らないと分かりづらいのですが、おおざっぱに書くと、このファイルでサイト内のロボットにアクセスされたくないページを指定することができます。

検索サイトのロボットですね。クローラーともいいます。

robots.txtファイル内に Disallow:  のあとにサイト内のディレクトリやファイルを指定しておけば、ロボット避けになります。Allow:で拒否したディレクトリ内部を例外的に許可することもできます。

一部無視するクローラーもあったりとか、他にサイトマップの位置を書いたりもするのですが、細かい書式などはググってくださいってことで、今回割愛(不親切設計)。

 ・ robots.txtを何のために設定するか?

さて、ではrobots.txtを何のために設定するか?

基本的にロボットに見て欲しいページを指示するためなのですが……

まず、前提として今のGoogleさんは内容の薄いページや同じ内容のページがたくさんあるのを好まない傾向があるのです。しかもダメページがあると、サイト全体の評価が下がります。SEOな話ですね。

また、1回でクロールしてくれる数には限りがあるようで、クローラーがリンクをたどってダメページに行ってしまうと、見て欲しいページに行ってくれる可能性が減ってしまいます。

そんなわけでダメページをロボットサーチ拒否設定にしておくことでSEO的に有利になるというわけです。

まぁ、私の個人サイト程度ではおまじないにもならないくらいの効果だとは思いますが、ある程度アクセスの増えてきたサイトには多少の意味はあるようです。

(この理由以外にも身内用のサイトなどで、スパムコメントが来づらくするようにロボット拒否設定することもあります)

・ で、何やらかした?

そんなわけで、このサイトの話ではないのですが、ドメイン直下とその下/BLOG/ディレクトリの2箇所にWordPressをインストールしたサイトがありまして、そこのサイトのrobots.txt設定でやらかしました。

ドメイン直下のメインサイトではパーマネントリンク設定がデフォルトではないし、固定ページはそれぞれ名前を設定してあるのですが、/BLOG/の方は、パーマネント設定がデフォルトになったままです。

(変えろよって話なんですが、初期からそのままになってまして……いまさら変えるのもという)。

さて、robots.txtをWordPress用に

Disallow:  /wp-admin/
Disallow:  /wp-includes/
Disallow:  /wp-content/plugins
Disallow:  /wp-content/cache
Disallow:  /wp-content/themes
Allow: /wp-content/uploads

こんな感じのよくある設定をしました。

また、WordPressはカテゴリーやらタグやら、やたら同じようなページを大量作成してしまう傾向があるので、いっそメイン記事以外の部分をDisallow設定にしました。

ついでにドメイン直下のページ用に

Disallow:   /*?*

と書いておきました。パーマネント設定を変えてあるので、WordPressのデフォルトでたくさん出来る「?」の入るページは要らないと判断して。

しかし、しかしですよ、ええと、この書き方だと……

/BLOG/?*

にも適用されるじゃないですか!(よく考えたら当たり前なんですが、しばらく気づかず(涙))

WordPressのデフォルトのページ名はこんな感じですよね。

/BLOG/?p=3939

そんなわけで、パーマネント設定がデフォのままの/BLOG/のブログページがほとんどロボット拒否設定になってしまいましたとさ。

しかし、ウェブマスターツールさんはこんなミスにもツッコミ入れてくれるんですね。

ウェブマスターツールでrobots.txtの記述が正しいかを先にテストすることもできます。あくまで文法的な部分をなので、テストでは今回のようなミスはわからないですが(涙)

結論のようなもの

  • ワイルドカード怖い
  • robots.txt は、素人が下手にいじると危険!
  • まぁサイトが壊れるわけでもないし
  • 変なことすると、ウェブマスターツールが教えてはくれるけども

Sakuraサーバーで間違ってWordPressをアンイストールした場合の対処法。

Sakuraサーバーで要らないWordpressを消そうと思って、やってしまいました(涙)

アンインストールボタンを押してから時間がかかるようなのですが……そこであわてて連打。すると、もう1つの必要なWordpressまで消えてしまいました!

これを復旧する手順を記録しておきます。

ここではSakuraサーバー上での話ということで書きますが、phpMyAdminを使えるサーバーならば、他のサーバーでも似たような対処法で対応できると思います(レンタルサーバーならたいてい入ってるようです)。

バックアップファイルはプラグイン「BackWPup」で取ってあったものを使用しました。

もし、バックアップを取ってなかった場合は……たぶんどうしようもないですが、アンインストールしても実はデータベースそのものは残っているので、データベース部分だけならば、どうにかできるかもしれません。

復旧手順

  1. 同じデータベースにもう1度WordPressをクイックインストール
  2. phpMyAdminを使用して、SQLファイルをインポート
  3. データベース以外のファイルを復旧
  4. プラグインを手動でインストール

1.同じデータベースにもう1度WordPressをクイックインストール。

sakuraのサーバコントロールパネルにログインします。左メニューから

sakura2-2

運用に便利なツール>クイックインストール

まず単純にもう一度クイックインストールでWordPressを上書きして良いようです(あとからインポートで上書きしますので、データベースのバックアップがある場合に限ります!)。

このとき、元のインストールしていたバージョンを合わせた方が良いらしいのですが、低いバージョンをクイックインストールして、あとからアップデートでも大丈夫でした(必ず大丈夫なのかは保証しません!)。

今回は、WordPress ver.3.8.1で運用してたものに、ver.3.7.1でクイックインストールして即ver.3.8.1にアップデートしました。

2.phpMyAdminを使用して、SQLファイルをインポート

sakuraサーバコントロールパネル内

sakura

アプリケーションの設定>データベースの設定>管理ツール ログインから「phpMyAdmin」にログインします。

「BackWPup」バックアップしてあったものを解凍し、中から SQLファイル(“自サイトのデータベース名”.sql)を取り出し、ここにインポートします。

sakura3-2

「ファイルを選択」でSQLファイルを選択しアップデートしてインポート。これでデータベース部分は復旧します。

3.データベース以外のファイルを復旧

しかし、Wordpressをアンインストールしてしまうと、同時にサーバー上の他のファイルも消されてしまうので、FTPでこれも戻さないといけません。

バックアップファイルの中から、「wp-content」フォルダを全部FTPで送りこみます。

このとき、「wp-admin」や「wp-includes」、その他ルートにあるファイルを、まるごとアップしてはいけません。まずは「wp-content」フォルダのみで。ただし、「wp-includes」内部などに自分でさわった箇所がある場合は、そのファイルを個別に追加アップします。

また、フォルダ以外にもルート(正確にはwww直下)にあるwp-config.phpと.htaccessをアップします。

.htaccessをアップするのを忘れると、WordPressのパーマネントリンクの設定が反映されなくなりますので、ご注意。(私はこれであたふたしました。デフォルト設定のままだと実はなくても通るようですが)

4.プラグインを手動でインストール

プラグインに関しては一括インストールしてくれません。バックアップのプラグインリストもしくはメモなどを見ながらひとつひとつインストールしていきます。

これで復旧完了……のはず。

結論のようなもの

  • 誤操作怖い!(涙)
  • バックアップ超大事!!(涙)
  • でも必要なバックアップさえあればどうにかなります。
  • データベースのバックアップはもちろんですが、「wp-content」フォルダなどデータベース以外のバックアップも忘れずに。

ひるね部ブログ(仮)開設

ジャンル分けをどうするか悩みつつおおざっぱにブログ開設。ひとまずここではWordPressの覚え書きとブラウザ関係の話が多くなりそうです。

Google Analytics が 「not provided」だらけ

別ブログで書いてた内容の修正版です(このブログ開設前)。


Google Analytics の結果が 「not provided」だらけになっています。

GoogleがSSL化(暗号通信化)していってる影響か、昨年9月頃からGoogle Analyticsで、どんどん検索ワードが取得できなくなっていってます。今はもう多くが「not provided」になってしまいました。

「not provided」、つまり不明。

また、この1月にはアメリカのYahoo!もSSL化したそうです(向こうからの検索にはほとんどかからないので私は詳しくはわからないのですが)。

日本のYahoo!に関してはアメリカとは別資本なので、すぐにこちらもということはなさそうです。しかし、もしも日本の方もSSL化して検索ワードが取得できなくなると、自分のサイトにどこの言葉で検索して来たかがほとんどわからなくなってしまいます。

そうなると困ったことになりますね。

Googleからの情報が分からなくても、いまのところはYahoo!からのものはわかりますし、Google分もウェブマスターツールだとなぜか一部はわかるので、ある程度までは推測はできるのですが。

でもウェブマスターツールは90日分しかデータを残してくれないのが困りどころですね。私はそんなガチSEOしてるタイプではないのですけども……いやでもガチじゃないからこそ、てきとうSEOがやりづらくなるので面倒に思います。