重複コンテンツの正規化と言っても、あまりピンとこないかも知れない。
アクアリウムサイトではあまり該当のサイトは見かけないし。
でも例えばうちがそうです（汗）
重複コンテンツとは？
重複コンテンツというのは、主に CGI や PHP なんかが動的に生成するページなどで発生します。静的な HTML で発生してたら、それは意図的な何か陰謀を感じます（曝）
例えば、見た目はほぼ同じページなのに、URL が微妙に違うってことありますよね？
こんな感じで。
http://www.1023world.net/city/eiji
http://www.1023world.net/city/eiji?menu=guestbook&date=20090207
http://www.1023world.net/city/eiji?menu=guestbook&date=20090208
これはどういうものかと言いますと、「基本的には同じページなんだけど、データや表示方法を切り替える目的で、プログラムに引数を渡して処理させるような場合」などによく用いられる URL 形式です。
但し、上記のURL例の場合は表示内容がかなり変わるため厳密には重複コンテンツにはならないと思いますが、よくある通販ページ等で、単に商品の並び替えソートを行うようなページは、記載順が違うだけで内容は同じなので、そういうものは重複コンテンツと見なせます。
また、単に以下のようなケースもあります。
http://1023world.net/
http://www.1023world.net/
www に対するサブドメインの処理はサーバーの設定によっても違いますが、多くの場合、上記のケースは同じページを指しますよね。こういうものも重複コンテンツになります。
重複コンテンツを正規化する
では、それがどうしたの？と言われそうですが、実はこれらのうんちくは他の誰でもない検索エンジンらが騒いでいることです（笑）
なんて言うと叱られるのできちんと説明しますと、要するに同じ内容なのに URL がいくつもあると、検索エンジンはそれだけ多くのページを巡回しなければならないし、保存データも多くなるので資源の無駄だから、もっとこれらを最適化しなさいよ。と言うことです。
とは言え、それらを無くすことが出来るなら、初めからそのような構造を作りませんよね。
もし無くせるならそれに越したことはありませんが、大抵の場合これは「必要悪」です（汗）
ですから、「せめてページでこのように宣言しなさいよ」と、検索各社が正式に発表したそうです。
<head>
...
<link rel="canonical" href="本来の正式なページのURL" />
...
</head>
重複コンテンツに該当するページにこのように記述することで、「あぁ、このページはあのページのダブりね。OK！」と、検索エンジンがスマイルになるのです。
もちろん、ダブりに該当するページ全てに記述が必要ですね。
また正式ページにも記述して問題ないと思います。その方が判りやすいかも。
ちなみに多くの場合は CGI や PHP が対象だと思うので、その場合は HTML に記述するようにはいきません。該当のプログラムのテンプレートのヘッダに、動的な URL が割り当てられるように <link rel=”canonical” href=”正規な動的URL”> タグを適切に記述しなければなりません。詳しくは利用しているプログラムのヘルプを。
最終的にそれらの関係にあるページ群には、それぞれ以下のように記述させます。
Aページのヘッダ内
<link rel="canonical" href="AページのURL" />
Aページのダブりページ1のヘッダ内
<link rel="canonical" href="AページのURL" />
Aページのダブりページ2のヘッダ内
<link rel="canonical" href="AページのURL" />
これで検索エンジンにやさしいサイトに昇格です（笑）
1.023world の場合
今回、当サイトでも一部のページで重複コンテンツの正規化を行いました。
超ヤドカリ図鑑の以下のようなURLパターンのページがすべて対象です。
カシワジマヒメホンヤドカリ/Pagurixus fasciatus Komai & Myorin, 2005 の場合
- 和名 URL
- http://www.1023world.net/カシワジマヒメホンヤドカリ
- 学名 URL
- http://www.1023world.net/Pagurixus-fasciatus
そうです。これらは URL こそ異なりますが、同じページを指しています。
なので、現在これらのパターンで形成されている重複 URL は、全て和名 URL を正規 URL に設定しました。
既にお判りのように、まるっきり異なる URL 同士を関連づけることになるので、実験も兼ねてました。また、検索各社が内部処理に役立てるだけなのか、あるいは SERPs（検索結果）にも反映されるのか、それも実験の目的でした。
ところで、そもそも超ヤドカリ図鑑では何故こんな URL 形式が採用されたかと言いますと、
- 目的のヤドカリのページに容易に辿り着けること （ URL の簡略化）
- 学名でも和名でも辿り着けること （グローバル？）
- 子供でも簡単に辿り着けること （広いターゲット層）
このような意図があります。
「 1.023world のトップページ URL に、調べたいヤドカリの名前を付け足すだけでOK！」というコンセプトです。
wiki もこんな感じですよね。
でも、別に wiki を目指した訳ではなくて、単に検索でヒットして欲しいから（笑）
URL 自体にキーワードが入っていると、検索結果への効果が違いますからね。
最近はあまり影響が見られなくなったようだけど（汗）
いや、あくまでも真の目的は上記の意図1～3ですから、お間違えなく（汗）
で、実際に検索テストをおこなってみたら、3/15時点で Google では既にこれが完璧に適用されていました。この措置は2月の末くらいに施したので、およそ半月が経過していますが、さすが Google は仕事が速いです。
それに引き替え Yahoo と MSN は。。。未だ華麗にスルーですね（汗）
以下、3/15時点での検索各社の挙動です。
- Google
- 和名で検索しても学名で検索しても、正規化の指示通り和名 URL を返してくれます。これは単に内部アルゴリズムのためだけの正規化ではなく、SERPs への反映にも利用されているのが伺えます。
- Yahoo
- ヤドカリの種によっては和名 URL を返したり、学名 URL を返したり、特に何も考えて無さそう（苦笑）。多分、バックリンクの有無にも影響されているのでしょう。
- MSN
- 学名で検索しても和名で検索しても、意地でも学名 URL を示す（曝）
すべてのヤドカリを検索した訳ではないので、上記はあくまでも参考例としてお受け止めください。
こうして今日もまたひとつ、 Google のサービスの良さを実感したのでした♪
こちらのエントリーもどうぞ♪
えー。まず事前案内から。
実は今月の投稿の約9割は、WordPress の予約投稿機能によるものです（汗）
今これを書いてる日付も本当は3/14ですが、今日のこの投稿内容で時系列が少し可笑しくなる恐れがあるので、予めお断りしておきます（曝）
先日（僕にとっては本当に昨日だけど、この投稿が公開される時点では一週間前になる）、WordPress の高速化 と言う投稿をしました（と言ってもその投稿自体書いたのは今を遡ること2週間前になる）が、その後の効果を報告しておきます。
（あー。くどいので文中に時系列の解説はもう入れません）
QoSアラート再び
実はこの WordPress の高速化を実施する前までは、特に恐らく WordPress の最新版 2.7.1 をインストールしてからは、サーバーのメモリ使用率は一日あたり約10回前後のアラートが発生していました。
以前、このサーバーの下位プランを借りた時点ではアラートなんて出てませんでしたが、調子に乗ってあれやこれや回すようになったら、すぐにメモリが厳しくなってしまい、ものの3ヶ月ほどで現在の上位プランに移行せざるを得ませんでした（汗）
でもその後しばらくはまた平穏な日々が続いていたはずでしたが、今年の2月に入ってくらいかな、またアラートがポツ、ポツと出始めるようになってしまったのです。
ちなみに今僕が使ってるサーバーは VPS なので（厳密には性能保証プランの方）、管理画面が Virtuozzo （仮想化ソフト）やら Presk （コントロールパネル）やらが利用できるのですが、その Virtuozzo の方でリソースやら QoS アラートやらがモニタできるようになってます。
で、このアラートにも段階があり、普段出ていたのはソフトリミットの方で「イエローゾーン」と呼ばれています。これは、「契約しているプランの保証値に近づいてるぞ！」というものです。
と言っても、仮にコレを越えてもハードリミットまでの余裕があればそっちに回るので問題はありません。
が、ここ最近はまた契約初期のように「ブラックゾーン」と呼ばれるハードリミット越えが見られ始めていました。またかよ、と。
多分そのせいで WordPress が転けるようになり始めたんだと思います。
でも、こりゃどげんかせんといかん。
と言う経緯があっての、先日の WordPress の高速化 でした。
WordPress高速化の結果報告！
長くなりましたが、結果報告です。
なんと、これを実施した3/9以降、まだ一度もアラートは出てません！
ブラックどころかイエローすら見あたりません。
こりゃ凄い！！
いやぁ、ダメもとで試してみたMySQL のクエリキャッシュと、WordPress のコンテンツキャッシュの設定でしたが、なんとまあコレが覿面だったようです。
以下は、3/8まで出ていたアラートのログ。
また、平常時でもメモリ使用率はほぼ安定して40％台をキープしています。とてもこれがフローするとは今のところ思えません。
僕はサーバー関係は専門外でサッパリなのですが、これでしばらくは一安心です。
だったらルート権限付きのサーバーなんか借りるなって話ですが。。。汗
僕のようにリソースで困ってるサーバー初心者の方、もし WordPress を使ってるなら高速化をオススメしますです。
でも、早くも問題が・・・
ところで MySQL の状態を phpMyAdmin で見てみたら、なんか早くも Qcache_lowmem_prunes の値が現れていた。
- Qcache_lowmem_prunes
- 新しい照会をキャッシュするためにメモリを解放するべく、キャッシュから削除された照会の数。この情報は照会キャッシュのサイズを調整するときに便利です。照会キャッシュがキャッシュから削除する照会を決定する際には、最後に使われた時刻が最も古いものから削除する戦略をとります。
これ、今 query_cache_size の値を 24M にしてあるんだけど、もう少し挙げた方が良いのかなぁ。
ま、ブログの方は閲覧者が少ないし、そこまで神経質になることないのかな？
サーバー先生。。。
こちらのエントリーもどうぞ♪
やっぱり電磁弁がおかしい。
通電してるのにエアの通りが悪かったり、オフになってもチビってたり。。。（汗）
これはどげんかせんといかん。
で、電磁弁の取り外し。
エアチューブ接続用のタケノコはねじ込みなのですぐに外せる。しかしそれ以上の分解は無理っぽい。と言うか買い換えか？（汗）
ちなみにこれは、空気も水もOKな電磁弁で、AC100Vで使えるのがグッド。また、これはエアチューブ用のタケノコをセットしたモデルだが、ネジ径さえ合えば用途に応じて別の継ぎ手も利用できる。たぶん販売店側でも注文に応じていろいろと組み合わせて出荷しているのだろう。
ところでこの電磁弁は水草用品通販専門店 GREENSで購入した。該当ページはここ。「電磁弁」で商品検索すれば、他の継ぎ手仕様のものもいくらか見つかる。
しかし2,600円って安いなぁ。。。アクアショップで買えば福沢さんが出陣しそうだ（笑）
とは言え、まだ半年しか使ってないし、買い換えるのは勿体ない。
ちょっと原因を調べてみよう。
コレは一体どこのメーカー製品なんだろう。
で、電磁弁のラベルをチェック。
見やすいように画像を加工してます
SMC
VDW11-1G-2
-M5
0~0.4MPa AC100V
ORIFICE 1.6mm
MS JAPAN
これでググったら、すぐにメーカーが判った。ラベルの通り SMC と言う産業用部品の製造会社のようだ。で、該当製品の仕様書があったので、構造を見てみた。
なるほど。ソレノイドが穴を塞いでいるだけか。なんかゴミでも噛んだかな？
で、実際にタケノコを外して覗き込んでみたら、あらま、中に緑青が。。。
確かに経路は真鍮だし、湿気がありゃ緑青も噴くってか？
え？ これ、水用途もOKなんじゃないの？？？
海水だからダメなんだろうか？
いや、その前に「海水自体」は通してない。干満システムの仕様上、あくまでエアだけだ。でも、塩っ気のあるエアだから、それが返って緑青を誘発したのかしら？
うーん。。。あるいは塩の結晶でも噛んでたかな？
考えてても仕方がないので、出来る範囲でクリーニングしてみることにした。
まず、見える範囲の緑青を綿棒で綺麗に掃除して、勢いよく通水したり、頻繁に通電したり、とにかく中の緑青が上手く流れ出るように仕向けてみた。
ついでに潤滑と保護の意味で、オイルを通した状態でも同様の作業を繰り返した。
そうして黙々と電磁弁と戯れる私。。。
お。凄くスムーズになった。
エアの遮断と開放も完璧に復活した！
何でもやってみるもんだ。
でもこれ、半年後もやらなアカンかな。。。
こちらのエントリーもどうぞ♪
