検索エンジン&SEO

[ガラケー版(QRコード)]
アクセス記録[推移 / PV内訳(過去1日 / 過去1週間) / 外部アクセス元 (昨日 / 過去1週間) / ログイン論客足跡]
プロフィール私書(メール)
   /   /送済
評価(一覧   /)
投票   /共:   /
ファン登録
作品/情報/
DB構築()
ブログ
[書く]
攻略記事リンク集
My Play List
 作成日時分類記事タイトル
12014/04/21検索エンジン&S..Yahoo::携帯(=ガラケー)サイト専用検索の機能..
22014/01/13検索エンジン&S..検索エンジンの作り方::BER圧縮差分データにgzi..
32013/10/02検索エンジン&S..Google::Google検索の完全https化と..
42012/12/19検索エンジン&S..書いた人本人専用メモ書き
52012/10/12検索エンジン&S..SERP::検索結果の位置とクリック率の関係..
=>古記事
 反応日時来客名来客者の最近のメッセージ
12017/04/20 非論客コメント
22017/02/25Merciこんばんは。サーバー移転後からだと思いますが、以前は見られた..
32017/02/17ねこじゃらしブログ投稿やコメントをしようとすると、たまにエラーになります..
42017/02/16Barnirunお世話になっております。https対応の影響か(またはhtm..
52016/11/10伏魔の剣こんばんわ。形式変更お疲れ様でした。 ところでこの改定につい..
その他最近のコメント
1.
2014/04/21 検索エンジン&SEO > Yahoo > 携帯(=ガラケー)サイト専用検索の機能の提供を停止」
[この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)]拍手:5個

Yahooが携帯サイト(=ガラケーサイト)専用検索エンジンの提供を停止するとの事。

http://mobile.yahoo-help.jp/cgi-bin/fp_yahoo_japan.cfg/php/wap/enduser/ans.php?p=10307&p_faqid=77154
平素はモバイル版Yahoo!検索をご利用いただき、誠にありがとうございます。
2014年4月15日(予定)をもちまして、モバイル版Yahoo!検索のサービスを、一部リニューアルさせていただくこととなりました。

これまで、モバイル版Yahoo!検索では、検索エンジン(クローラー)が収集した一般のモバイル向けサイトの情報が、検索結果に表示される「ケータイサイト検索」というサービスを提供してきましたが、これを終了させていただきます。

ヒント
これまで閲覧されていたサイトなどは、ご利用の携帯電話のブックマーク、お気に入りに登録されることをおすすめします。

なお、「PCサイト検索」や「カテゴリ検索」「Q&A検索」などのサービスは、引き続き提供してまいりますが、上記「ケータイサイト検索」の終了等にともない、検索結果ページ全体のデザインを変更させていただきます。

自分にもガラケー絡みは後回しという傾向が出てきていますが(汗)、ガラケーサービスには未来が無いという事で、世の中的にリソース配分として段々配分すらされなくなってきています。
Yahooからすらそういうのが利用出来なくなるというのは、一つの時代の流れの現れでしょうね。

コメントする5個


石鯉 さんのコメント (2014/04/22) [編集/削除(書込み者/所有者が可能)]
先ほど,タグが問題なく機能していることを確認しました。
ご対応感謝です!
管理人さん さんのコメント (2014/04/22) [編集/削除(書込み者/所有者が可能)]
石鯉さん

コメントどうもです。

メールサービスも止めちゃうんですね。
既にそういう傾向は他でも出ていましたが、Yahooは日本のネットの最大手なので、そこがガラケー向けのサービス開発提供止めてけば、他もそれに倣えで、どんどん止めていってしまうことになるだろうなぁ、と思います。

それはそれとしまして、前にコメントでご報告頂いていた、携帯版のnetaとkesuタグの作動問題、この記事書くついでに、だからって放置ではないよ、という事で、対応させて頂きました。
まあ、世の中的にほぼ完全ガラケーが売られなくなったら、流石にもう何もしないかもしれませんが。
石鯉 さんのコメント (2014/04/22) [編集/削除(書込み者/所有者が可能)]
急に検索画面のレイアウトが変わったな~…なんて思っていたのですが,なるほどそういうわけで。
来月にはメールサービスも停止になるみたいですし,時代の流れとはいえ旧式ユーザーを本気で殺しにかかってきてるなぁ…(まあ,そのときはそのときでネットの利用を控えればいいだけの話だけど)

2.
2014/01/13 検索エンジン&SEO > 検索エンジンの作り方 > BER圧縮差分データにgzipを組み合せて更に小さく出来るか検証」
[この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)]拍手:1個

1. 文章目的
2. 最初の段階
3. 「数値差分圧縮」をかける
4. 更に「BER圧縮」をかける
5. 更に「Gzip圧縮」をかける
6. 検証結論
7. $wordの最大の文章IDが含まれたtmp_bdbhのBER圧縮された値をindex_bdbhの先頭に挿入するBer圧縮の処理 by perl

    1. 文章目的

検索エンジンの索引サイズをgzipを使う事で小さく出来るか検証してみる。
検索エンジンの仕組みを知らなくても、頭の体操として理解出来るようにしてあります。
目的は、数値群をどれだけ小さいサイズで表現出来るようにするか、です。
    2. 最初の段階

例えば、「アニメ」という単語が、本の

1000,1125,1250,1375,1500

ページに登場したとする。
検索エンジンの基本的な仕組みは、「アニメ」と検索された時に、それが何ページ目に表示されるか、の索引機能です。

この時の上記バイト数は24bytes。
(オンライン文字列長調査ツールで計測)。
    3. 「数値差分圧縮」をかける

これを一番後ろを基準にその差で表現していくと
1500 = 1500
1375 = 1500 - 125
1250 = 1375 - 125
1125 = 1250 - 125
1000 = 1125 - 125
つまり、読込みの起点を1500において、それより後ろの数値は差分で表していくと、
1500,125,125,125,125
で表現出来る。
この時のバイト数は20bytes。
この時点の削減率は17%。
    4. 更に「BER圧縮」をかける

ここで1bytesは8bit(=[0 or1]の8回の組み合わせ)である事に注目すると1bytesは0-255のパターンが表現出来る事がバイナリー的観点では分かる。

1 bytes = 8 bits = [0 or 1][0 or 1][0 or 1][0 or 1][0 or 1][0 or 1][0 or 1][0 or 1]

ここで先頭の1bit目が0の時を数字の末尾を表す用途に使うと、

1500 = 128*11 + 92 = [1][0][0][0][1][0][1][1] [0][1][0][1][1][1][0][0] <= 4バイトが2バイトとして表現出来る
125 = [0][1][1][1][1][1][1][1] <= 3バイト文字が1バイトとして表現出来る

数字の切れ目が先頭の1ビットで分かり、数値の区切りも必要無くなるので、
なので、
1500,125,125,125,125

[2バイト][1バイト][1バイト][1バイト][1バイト]

6bytesで表現出来るようになる。
この時点の削減率は75%
この削減率は原理から考えれば数字が大きくなればなる程強力になるという事が分かるかとは思います。
    5. 更に「Gzip圧縮」をかける

Gzipの仕組みは自分も使うだけで原理を理解していないので、勉強をスキップして実際に唯動かして削減率を検証してみる。

#!/usr/local/bin/perl -w
use strict;
use Compress::Zlib;

# 最初の数値群
my @array=(1000,1125,1250,1375,1500);
print "Length of initial array: ".length(join(',', @array))."\n";

# 「差分圧縮」をする
my @reverse=();
my $pre_num = 0;
while(my $num = pop @array){
  if($#reverse >= 0){
    my $diff = $pre_num - $num;
    $pre_num = $num;
    push(@reverse, $diff);
  }
  else{
    push(@reverse, $num);
    $pre_num = $num;
  }
}
print "Length of diff array: ".length(join(',', @reverse))."\n";

# 更に「BER圧縮」をする
my $ber_commpressed_num = '';
foreach my $num (@reverse){
  $ber_commpressed_num .= pack("w*", $num);
}
print "Length of ber compressed diff array: ".length($ber_commpressed_num)."\n";

# 更に「Gzip圧縮」をする
my $final_str = Compress::Zlib::memGzip($ber_commpressed_num);
print "Length of gzipped ber compressed diff array: ".length($final_str)."\n";

Length of initial array: 24
Length of diff array: 20
Length of ber compressed diff array: 6
Length of gzipped ber compressed diff array: 24

あれ、最後のgzipはこのケースだと逆に大きくなっちゃうか。
Gzipを単に適用して必ずしも小さくなるというわけではないですね。
    6. 検証結論

BER圧縮差分データを格納したBerkeleydbファイルをgzipかけるとサイズは小さくなったので、この検証を思いついたのですが、それはデータ部分ではないのか、はたまたもっと長いとか別パターンの所でないと十分に効かない為なのか、いずれにせよ残念ながらBER圧縮したデータに更にGzipを適用してみるのは一旦保留ですね。

検索エンジンは読み込む量・貯め込む量が膨大なので、こうしたデータの圧縮方法を追求していく事になります。
頭の体操としても中々興味深い、理論と検証の世界である事が伺えるかと思います。
    7. $wordの最大の文章IDが含まれたtmp_bdbhのBER圧縮された値をindex_bdbhの先頭に挿入するBer圧縮の処理 by perl

こんな感じになる。
      my $word='';
      my $tmp_str='';

      if(my $cursor=$tmp_bdbh->db_cursor()){
        while($cursor->c_get($word, $tmp_str, DB_NEXT)==0){
          my $str;
          if($index_dbh->db_get($word,$str)==0){
            my $v;
            while($str=~ s!^([\x00-\xFF])!!o){
              $v.=$1;
              unless(0x80 & ord $1){
                my $pre_doc_id;
                if($pre_doc_id_bdbh->db_get($word, $pre_doc_id)==0){
                  my $diff=$pre_doc_id-unpack("w*",$v);
                  if($index_dbh->db_put($word, $tmp_str.pack("w*",$diff).$str)){
                  }
                }
                last;
              }
            }
          }
        }
        $cursor->c_close();
      }
      $index_dbh->db_close();


コメントする1個

3.
2013/10/02 検索エンジン&SEO > Google > Google検索の完全https化と「外部アクセス情報」の減少の関係について説明」
[この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)]拍手:3個

1. Google検索のhttps化
2. httpsで外部アクセス情報が分らなくなる原理
3. Googleのhttps化の進行状況

    1. Google検索のhttps化

Googleはhttps化を進めていましたが、先月からログインユーザーだけでなく、ログインしていないユーザーもhttpsでのアクセスを強制されるようになったので、基本的にGoogleは「外部アクセス元」をサイト側には渡さない状態になっています。

外部サイト情報例: 米Google、検索のSSL暗号化を拡大 - Googleにサインイン/アウト問わず暗号化へ
    2. httpsで外部アクセス情報が分らなくなる原理

https = http secure = 安全なhttp です。
サーバーへのリクエストと、サーバーから返される結果が暗号化されるので、その通信の間で情報を覗かれるという事が原理的になくなります。
また、暗号化にあたって、そのサーバーが本当にそのサーバーなのか、という事の確認処理も外部サーバーを使って行われます。

更に、暗号化を優先する通信である事に合わせて、ブラウザーの仕様としてhttpサイトからhttpサイトに来た時には、元々どこのページを見ていたのかの情報は渡されない挙動をします。
前見ていたページがサイト側に分ったら、それはその部分が「暗号化」されていないという事になってしまいますからね。

HTTPS通信図解

[引用元]

結果として、Googleの場合、こちらのサイトにアクセスしてくる時、
http://www.google.co.jp/
からの検索だと、検索元情報=refererが渡されますが、
https://www.google.co.jp/
経由だと、検索元情報が渡されません(ブラウザーがそういう挙動をする)。
そして今は全面的にhttpsの方に統一されたので
「Google経由のアクセスである」
「Googleで何の検索がされて人が来たのか」
の情報が分らなくなった = 外部アクセス元情報が相当分減少した、というカラクリです。

httpsのメリットは、サーバー間の通信が暗号化される事で、それを「覗き見」される可能性がなくなる=セキュリティが増す = 全部そうすれば良いじゃない?と思うかもしれませんが、証明書の購買&維持やサーバー負荷等、コスト増が色々な側面で起こる為、通常はショッピングとか限られた部分で使われるものになっています。
但し、Googleは検索エンジン全体に対して、httpsの使用を広げてきました。

※ ちなみに、作品DBも皆様にとってのセキュリティ向上の為、最近SSL証明書を買って https対応 ( https://sakuhindb.com/ ) したけれども、リンクとか色々作り直しが必要なので、公式にはアナウンスはしておらず。もっと色々作業したら、最終的にはPCのログインユーザーの方はhttpsを使って貰う事になるかも
    3. Googleのhttps化の進行状況

Googleは、ログインユーザーについて、httpsの強制をするように2011年位になりましたが、つい最近からログインしていないユーザーもhttpsの方のページの使用を強制するようになりました = 全ユーザーの検索行動が暗号化されました。

なので、Googleから来た&Googleでの質問は、サイト側から見ると分らなくなります。
なお、それでもgoogleのhttp経由のが外部アクセス元に少々まだあったりますが、それがどこから発生しているかは自分も分りません。
自分のPCではどうやってもhttpsの方に移動してしまいますが、何かしら環境によってはhttpがまだ使える環境もあるのかな?(ガラケーとか)

でも基本的に撲滅される筈なので、Googleからのアクセス元情報は今後は得られなくなるものと考えて下さい。
因みにYahoo Japan!は今の所https対応していないので、そっち経由の情報は得られます。

コメントする3個


管理人さん さんのコメント (2013/10/02) [編集/削除(書込み者/所有者が可能)]
ut さん、コメントどうもです。
そういえば皆さんにも関係する事だから書いた方が良いかなぁと思っていたので、良いきっかけになりました、ありがとうございます(^^

サーバーは不安定な処理になる部分について、これはもうWebサーバー用途では駄目だなという部分(DB = BerkeleyDB)があるので、そこについて別のDB(= riakというもの)を使って安定するように、現在差し替え作業中となっています。
やるべきことは諸々ありますが、現在自分的にはそれが最優先作業になっています。

宜しくお願い致します。
ut さんのコメント (2013/10/02) [編集/削除(書込み者/所有者が可能)]
こんばんは

なんかちょっと説明催促したみたいで申し訳ないですー
1ヶ月前から急に検索数減ったなー
そういえばアクセスできない期間も増えたなーなんて思っていたからひょっとして因果関係があるかと思ってました

どういうルートで来ているのか結構楽しみにしていて記事を書くモチベーションにもなっていたのでちょっとさみしいですねー

4.
2012/12/19
書いた本人専用メモ書き
5.
2012/10/12 検索エンジン&SEO > SERP > 検索結果の位置とクリック率の関係」
[この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)]拍手:4個

1. 文章目的
2. 検索結果に検索連動広告が表示されている割合
3. オーガニックな検索結果(検索連動広告でない部分)のクリック率
4. 検索連動広告(SEM)の表示場所とクリック率の関係
5. 検索連動広告(SEM)の順位とクリック比率の関係詳細
6. まとめ

1. 文章目的

検索結果の位置とクリック率の差異について面白い資料が提供されていたので、その日本語訳まとめ的な形で情報を提供させて頂きます。
米国にて何千万というサンプリングから導きだされた結果との事です。
2. 検索結果に検索連動広告が表示されている割合



検索結果に検索連動広告が表示されている割合は55%と、過半数を超えています。
キーワードのロングテールな多様性等々を考えると、相当数の広告主と出稿量があるという事が分ります。
3. オーガニックな検索結果(検索連動広告でない部分)のクリック率



検索連動広告でない検索結果の部分を、オーガニックと呼びますが、表示される数としてはオーガニックが85%、検索連動広告が15%あるそうです。

また、オーガニックの検索結果の内、クリックの割合は
1位53%
2位15%
3位9%
4位6%
5位4%
と、1位が圧倒的なクリック率を誇っている事が見て取れます。

ということで、検索結果において1位であるか否かは、大きな差になります。
2ページ以降になる11位以下については、その少なさは推してしるべしといったところでしょうか。
4. 検索連動広告(SEM)の表示場所とクリック率の関係



検索連動広告は、上部、右部、下部の3カ所に表示されますが、その表示割合は
上部24%
右部61%
下部15%
となっています。

しかし、そのクリック数の分布は
上部85%
右部13%
下部2%
となっており、圧倒的に上部がクリック率を集めている事が分ります。

日本では、Yahoo!が上部に4件、Googleが上部に3件表示するようになっているので、そこら辺を基準と考えた出稿が必要になる事が分ります。
5. 検索連動広告(SEM)の順位とクリック比率の関係詳細



検索連動広告の上部、右部、下部のそれぞれの中の順位と、全体でのクリック比率の割合の関係は以下の通りになっているという事ですね。
これから見て取れる通り、1位は圧倒的なクリック比率を誇り、それ以下も順位が高ければ高い程、クリックが来るという事は見て取れます。
とはいえ、
検索連動広告で上部に行く=単価が上がる
という事ではあるので、それだけの差が出る事を理解した上での、調整が結局は必要になるという事にはなります。

上部
1位59%
2位15%
3位9%

右部
1位4%
2位3%
3位2%
4位1%

下部
1位1%
2位1%

6. まとめ

同じ画面に表示されていても、それがどれだけ上部に表示されているのか、それがたった一つの差でも大きな差になる事が見て取れると思います。
それを認識した上で、SEOなりSEMの活動はやっていきましょう。

具体的には、SEOについては

1. トップ1位率
2. トップ10位以内率

で指定した100語についてトレースしていくといくというのが、成功度合いの把握指標として良いでしょうね。
Top10に入っていないのはSEO的には「失敗」でしかありません。
あと少しでTop10に入れる語がどれ位あるのかというのを把握する事は意味ありますが。

SEMについては、費用をかければ上に上がるというものなので、結局は費用対効果の臨界点を追っていくしかないでしょうが、そうした場所によるクリック率のドラスティックな違いについては把握した上で、値付けする事が必要でしょうね。

コメントする4個

=>古記事
RSS購読
RSS
ブログ表示スタイル
リスト/携帯(QRコード)
画像/動画/音声/リンク
表示開始年月
分類
全て
1.このサイトについて
2.作品DB開発/運用
3.ホームページ制作技術
4.Perl
5.C言語 / C++
6検索エンジン&SEO
7.サッカー
8.自分のこと
9.Linux
10.旅行
11.思ったこと
12.パソコン
13.Berkeley DB
14.その他技術系
15.企画
16.スマートフォン
17.鑑賞
18.皆声.jpニュース
19.インターネット業界
20.運用マニュアル(自分用)
21.技術系以外実用書
22.料理
23.ALEXA
24.アニメ
25.会計
26.漫画
27.設計書
28.色々サイト作成
29.サーバー
30.自分専用
31.生活
32.OP/ED/PV
33.ゲーム
34.DB整備
35.新規開始作品紹介
36.英語圏の話題
37.大道芸
38.映画
39.PHP
40.ダイエット
41.Mac
42.JavaScript
43.MySQL
44.介護
45.作品DB作品追加作業
46.BI
47.Web API
48.パフォーマンス
49.インターネットの活用方法
50.Riak
51.Androidアプリ開発
52.Cassandra
53.スパム
54.写真
55.iOSアプリ開発
56.AWS
57.マーケティング
58.Web漫画
59.法律
60.mongodb
61.開発環境整備
62.Google Apps Script
63.meteor
64.Pentaho
65.Ansible
66.VPS
67.技術書メモ
68.Vagrant
69.Docker
70.dokuwiki
71.Apple Watch
72.Webサービス
73.セキュリティ
74.Elastic Search
75.Wordpress
76.クラウド
77.英語
78.MVNO
79.シンガポール
80.マレーシア
81.管理人さん
82.管理人さん
日記の主な内容
サイト運営/開発
検索エンジン情報
・技術ネタ(Berkeley DB,
Linux, Perl, サイト作成)等

サイト管理
全まとめ
サーバー管理
定期処理状況
開発予定
削除提案
作品追加依頼
OP/ED追加依頼
OP/ED not found
作品提案承認欄

格言 fromスクライド
この世の理は即ち速さ
20年かければ馬鹿でも
傑作小説を書ける

助けられたら助け返す
それが俺のルール

強くなるには
一番弱い考えをする事だ
そしてその考えに反逆する




右側に何か入れてみるテスト


仕事でのサイト
介護DB
Helpyou
Doctor career
Nurse career
上へ ↑上へ 最速検索作品DB皆声