[アクセスアップ] 1 年でアクセス数を 10 倍にするには 1 ヶ月の伸び率 21% を 1 年キープ
google analytics では、アクセス数の 1 ヶ月の伸び率を表示してくれる。でも、その伸び率を続けたら 1 年でどのくらいアクセス数が増えることが期待されるかと言うことに関しては表示してくれない。
1 年でアクセス数を 10 倍にしたいと思ったときに 1 月当たりの伸び率がどのくらい必要なのかわからなくなる場合がある。そうでないにしても今の伸び率をキープできたら 1 年でどのくらいアクセス数が伸びるのかを知りたい場合がある。そこで下のようなテーブルを作ってみた。このテーブルを参照すれば、「1 年で 10 倍にしたければ 1 ヶ月当たり 21% の伸び率を 1 年キープすることが必要」とわかる。例えば現在の伸び率が 10% の場合、この伸び率をを 1 年間キープできれば 1 年後には大体 3 倍くらいになっていることが期待できる。
長期的目標を短期的目標にして、コンスタントにセルフチェックすることが重要。
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1.01 | 1.02 | 1.03 | 1.04 | 1.05 | 1.06 | 1.07 | 1.08 | 1.09 | 1.10 | 1.12 | 1.13 |
| 1.02 | 1.04 | 1.06 | 1.08 | 1.10 | 1.13 | 1.15 | 1.17 | 1.20 | 1.22 | 1.24 | 1.27 |
| 1.03 | 1.06 | 1.09 | 1.13 | 1.16 | 1.19 | 1.23 | 1.27 | 1.30 | 1.34 | 1.38 | 1.43 |
| 1.04 | 1.08 | 1.12 | 1.17 | 1.22 | 1.27 | 1.32 | 1.37 | 1.42 | 1.48 | 1.54 | 1.60 |
| 1.05 | 1.10 | 1.16 | 1.22 | 1.28 | 1.34 | 1.41 | 1.48 | 1.55 | 1.63 | 1.71 | 1.80 |
| 1.06 | 1.12 | 1.19 | 1.26 | 1.34 | 1.42 | 1.50 | 1.59 | 1.69 | 1.79 | 1.90 | 2.01 |
| 1.07 | 1.14 | 1.23 | 1.31 | 1.40 | 1.50 | 1.61 | 1.72 | 1.84 | 1.97 | 2.10 | 2.25 |
| 1.08 | 1.17 | 1.26 | 1.36 | 1.47 | 1.59 | 1.71 | 1.85 | 2.00 | 2.16 | 2.33 | 2.52 |
| 1.09 | 1.19 | 1.30 | 1.41 | 1.54 | 1.68 | 1.83 | 1.99 | 2.17 | 2.37 | 2.58 | 2.81 |
| 1.10 | 1.21 | 1.33 | 1.46 | 1.61 | 1.77 | 1.95 | 2.14 | 2.36 | 2.59 | 2.85 | 3.14 |
| 1.11 | 1.23 | 1.37 | 1.52 | 1.69 | 1.87 | 2.08 | 2.30 | 2.56 | 2.84 | 3.15 | 3.50 |
| 1.12 | 1.25 | 1.40 | 1.57 | 1.76 | 1.97 | 2.21 | 2.48 | 2.77 | 3.11 | 3.48 | 3.90 |
| 1.13 | 1.28 | 1.44 | 1.63 | 1.84 | 2.08 | 2.35 | 2.66 | 3.00 | 3.39 | 3.84 | 4.33 |
| 1.14 | 1.30 | 1.48 | 1.69 | 1.93 | 2.19 | 2.50 | 2.85 | 3.25 | 3.71 | 4.23 | 4.82 |
| 1.15 | 1.32 | 1.52 | 1.75 | 2.01 | 2.31 | 2.66 | 3.06 | 3.52 | 4.05 | 4.65 | 5.35 |
| 1.16 | 1.35 | 1.56 | 1.81 | 2.10 | 2.44 | 2.83 | 3.28 | 3.80 | 4.41 | 5.12 | 5.94 |
| 1.17 | 1.37 | 1.60 | 1.87 | 2.19 | 2.57 | 3.00 | 3.51 | 4.11 | 4.81 | 5.62 | 6.58 |
| 1.18 | 1.39 | 1.64 | 1.94 | 2.29 | 2.70 | 3.19 | 3.76 | 4.44 | 5.23 | 6.18 | 7.29 |
| 1.19 | 1.42 | 1.69 | 2.01 | 2.39 | 2.84 | 3.38 | 4.02 | 4.79 | 5.69 | 6.78 | 8.06 |
| 1.20 | 1.44 | 1.73 | 2.07 | 2.49 | 2.99 | 3.58 | 4.30 | 5.16 | 6.19 | 7.43 | 8.92 |
| 1.21 | 1.46 | 1.77 | 2.14 | 2.59 | 3.14 | 3.80 | 4.59 | 5.56 | 6.73 | 8.14 | 9.85 |
| 1.22 | 1.49 | 1.82 | 2.22 | 2.70 | 3.30 | 4.02 | 4.91 | 5.99 | 7.30 | 8.91 | 10.87 |
| 1.23 | 1.51 | 1.86 | 2.29 | 2.82 | 3.46 | 4.26 | 5.24 | 6.44 | 7.93 | 9.75 | 11.99 |
| 1.24 | 1.54 | 1.91 | 2.36 | 2.93 | 3.64 | 4.51 | 5.59 | 6.93 | 8.59 | 10.66 | 13.21 |
| 1.25 | 1.56 | 1.95 | 2.44 | 3.05 | 3.81 | 4.77 | 5.96 | 7.45 | 9.31 | 11.64 | 14.55 |
| 1.26 | 1.59 | 2.00 | 2.52 | 3.18 | 4.00 | 5.04 | 6.35 | 8.00 | 10.09 | 12.71 | 16.01 |
| 1.27 | 1.61 | 2.05 | 2.60 | 3.30 | 4.20 | 5.33 | 6.77 | 8.59 | 10.92 | 13.86 | 17.61 |
| 1.28 | 1.64 | 2.10 | 2.68 | 3.44 | 4.40 | 5.63 | 7.21 | 9.22 | 11.81 | 15.11 | 19.34 |
| 1.29 | 1.66 | 2.15 | 2.77 | 3.57 | 4.61 | 5.94 | 7.67 | 9.89 | 12.76 | 16.46 | 21.24 |
| 1.30 | 1.69 | 2.20 | 2.86 | 3.71 | 4.83 | 6.27 | 8.16 | 10.60 | 13.79 | 17.92 | 23.30 |
| 1.31 | 1.72 | 2.25 | 2.94 | 3.86 | 5.05 | 6.62 | 8.67 | 11.36 | 14.88 | 19.50 | 25.54 |
| 1.32 | 1.74 | 2.30 | 3.04 | 4.01 | 5.29 | 6.98 | 9.22 | 12.17 | 16.06 | 21.20 | 27.98 |
| 1.33 | 1.77 | 2.35 | 3.13 | 4.16 | 5.53 | 7.36 | 9.79 | 13.02 | 17.32 | 23.03 | 30.64 |
| 1.34 | 1.80 | 2.41 | 3.22 | 4.32 | 5.79 | 7.76 | 10.40 | 13.93 | 18.67 | 25.01 | 33.52 |
| 1.35 | 1.82 | 2.46 | 3.32 | 4.48 | 6.05 | 8.17 | 11.03 | 14.89 | 20.11 | 27.14 | 36.64 |
| 1.36 | 1.85 | 2.52 | 3.42 | 4.65 | 6.33 | 8.61 | 11.70 | 15.92 | 21.65 | 29.44 | 40.04 |
| 1.37 | 1.88 | 2.57 | 3.52 | 4.83 | 6.61 | 9.06 | 12.41 | 17.00 | 23.29 | 31.91 | 43.72 |
| 1.38 | 1.90 | 2.63 | 3.63 | 5.00 | 6.91 | 9.53 | 13.15 | 18.15 | 25.05 | 34.57 | 47.70 |
| 1.39 | 1.93 | 2.69 | 3.73 | 5.19 | 7.21 | 10.03 | 13.94 | 19.37 | 26.92 | 37.43 | 52.02 |
| 1.40 | 1.96 | 2.74 | 3.84 | 5.38 | 7.53 | 10.54 | 14.76 | 20.66 | 28.93 | 40.50 | 56.69 |
| 1.41 | 1.99 | 2.80 | 3.95 | 5.57 | 7.86 | 11.08 | 15.62 | 22.03 | 31.06 | 43.79 | 61.75 |
| 1.42 | 2.02 | 2.86 | 4.07 | 5.77 | 8.20 | 11.64 | 16.53 | 23.47 | 33.33 | 47.33 | 67.21 |
| 1.43 | 2.04 | 2.92 | 4.18 | 5.98 | 8.55 | 12.23 | 17.49 | 25.00 | 35.76 | 51.13 | 73.12 |
| 1.44 | 2.07 | 2.99 | 4.30 | 6.19 | 8.92 | 12.84 | 18.49 | 26.62 | 38.34 | 55.21 | 79.50 |
| 1.45 | 2.10 | 3.05 | 4.42 | 6.41 | 9.29 | 13.48 | 19.54 | 28.33 | 41.08 | 59.57 | 86.38 |
| 1.46 | 2.13 | 3.11 | 4.54 | 6.63 | 9.69 | 14.14 | 20.65 | 30.14 | 44.01 | 64.25 | 93.81 |
| 1.47 | 2.16 | 3.18 | 4.67 | 6.86 | 10.09 | 14.83 | 21.80 | 32.05 | 47.12 | 69.26 | 101.81 |
| 1.48 | 2.19 | 3.24 | 4.80 | 7.10 | 10.51 | 15.55 | 23.02 | 34.07 | 50.42 | 74.62 | 110.44 |
| 1.49 | 2.22 | 3.31 | 4.93 | 7.34 | 10.94 | 16.30 | 24.29 | 36.20 | 53.93 | 80.36 | 119.74 |
| 1.50 | 2.25 | 3.38 | 5.06 | 7.59 | 11.39 | 17.09 | 25.63 | 38.44 | 57.67 | 86.50 | 129.75 |
[css] 色指定用のcssファイル
色指定を個別にする場合にタグのstyle属性の属性値にbackground:#FF0000とか指定する。例えば下のような感じ。
<div style="background:#FF0000; color:#00FF00;">背景色が赤で文字色が緑</div>
でも、統一的な外観をキープするためにはclass指定したほうがいいと思う。そこで下のような内容のファイルを作ってhtmlファイルからは外部cssファイルとして参照する。
.bg00{ backgrond:#FF0000; }
.co00{ color:#00FF00; }
その上で、上で挙げた例を書き換える。class属性の属性値にスペース区切りでclassを複数指定すれば指定されたclassが組み合わされて適用される。異なるclassで同じcssの属性に対して指定が行われている(css属性値の衝突する)場合は、後に指定したclassの属性が優先される。
<div class="bg00 co00">背景色が赤で文字色が緑</div>
もし、よく出来たブラウザとwebサーバがあるのなら、すべての色コードについてこのようなclassを作っておいても良いかもしれない。そうすればファイルサイズを小さく出来たり、データ転送量も減らせるかもしれないから。でも、この方法のポイントは統一的な外観を作ること。なので、いくつかの良く使う色と属性についてこのようなセットを作っておくことこそ本来の意味があると思う。
Google co-opの検索用ソースをW3C Markup Validatorでクリアさせる方法
僕はこれで引っかかった。このページはXHTML+MATHML+SVGでDOCTYPE宣言しているので、scriptタグのsrc属性を書く場合は、空白を と&を&のように記述せねばだめなようだ。「ようだ」というのはDTDをしっかり読んでないから。ということで下のようなコードがあった場合
http://www.google.com/coop/cse/brand?form=cse-search-box&lang=ja
これを下のように書き換える。
http://www.google.com/coop/cse/brand?form=cse-search-box&lang=ja
この解決策は正攻法だが、対応していないブラウザがあるらしい。いつだめになるかわからないのでW3C Markup Validatorへのリンクをおいておこう。
一応僕のサイトにもGoogle co-op(Google カスタムサーチエンジン)を置いてみたのだが、どうやら本家とco-opでは参照しているデータベースが違うみたいで、co-opでは引っかからないキーワードも本家でsite:を使えば引っかかるということがわかった。co-opを導入してみたのはGoogle Analyticsでどう表示されるのかが気になったからだけど、co-opだと引っかからない場合があることを考えると、使い続けるにはどうなのかなぁと思ってしまう。うだうだ言っててもしょうがないので元に戻した。いまはco-opは使っていない。co-opで意味のあることをするには検索しにくいキーワードの絞込みとかかな。例えばR言語について日本語のページを検索したいときとかね。Rだけだと余分なものがいっぱい引っかかるのでRに関連したページを人力でco-op検索サイトとして登録して、出来上がったco-opページから検索するようにすればいいのかもしれない。
Google analyticsって結局JavaScriptが動かないとカウントされない。結構これは悲しいわけで。
- "http://www.google-analytics.com/__utm.gif" - Google 検索
- Google Analyticsでモバイルのログ解析（PHPとリンク集） | バレで昼寝
- 404 Blog Not Found:Google AnalyticsのAnalysis、そして滞在時間のウソ
- Troubleshooting the Tracking Code - Google Analytics - Google Code
- "http://www.google-analytics.com/urchin.js" - Google 検索
- google analytics img - Google 検索
検索サイトにGooとか追加。まぁ結局のところjsファイル読まないとだめですね。
[MathML] 数式や図を作る
Opera が 9.5 になって MathML もうまく描画できるようになったらしいのでやってみた。
1 つ目 (mathml)
2 つ目 (mathml)
3 つ目 (svg の直書き)
4 つ目 (object タグで svg の埋め込み)
svg の埋め込みだと拡張子が html でも読み込める。svg の直書きだと拡張子が html で表示されない。ここらへんはサーバ側の設定やクライアント側の設定とか色々ありそうで一言では言えないような気がする。まぁ、サーバは本当にデータを渡すためだけに機能し、受け取ったデータをクライアントが解析して、データが正しく表示されればいいのだけれど。
[CSS] レイアウトと見栄えの話
最近よくある 3 段ぶち抜きペインとか、サイドバーとかってどうよ。横幅の狭いディスプレイとかウィンドウの横幅を狭くしてみたとき、本当に見えなければいけないメインコンテンツ (その多くは真ん中にあるが) の幅がものすごく狭くなったりする。また横幅指定されているがために、横スクロールしないとメインコンテンツが見えなかったりする。これってどうよ。やっぱり一目で情報が見渡せる範囲は限られているわけで限られたスペースを有効に使わないといかんと思う。
[html] サイトデザイン
サイトデザインについて考えてみた。
このサイトの場合
結局横にメニューを入れるのはやめた。最終的にもっともよいと思われたのは最もシンプルなものだった。苦労してサイドメニューのレイアウトを考えたが、あまり役に立たなかったようだな。改めて書いてみると、LaTeX的レイアウトだと思う。下のような感じで上から下に向かってずらーっと並べる
+--------------------+ | Title | +--------------------+ | Abstract | +--------------------+ | Table of Contents | +--------------------+ | Contents | +--------------------+ | Tanks for everyone | +--------------------+ | Table of Contents on Upper Document | +--------------------+ | Credit | +--------------------+
サイトデザインの指標として
- http://builder.japan.zdnet.com/news/story/0,3800079086,20378931,00.htm
- http://www.okuramkt.com/dic/mkt/landing_page.html
- ASHのコンテンツについて
- ウェブアクセシビリティチェックサイトHAREL
- Firebugでラクラク診断～Yahoo!が明かすページ表示の高速化13のルール - Dragon.jp
- Unobtrusive Google Analytics Integration » The Notebook » Refract, the online landscape of Rommert Zijlstra
[css] 背景色と前景色の組み合わせ
色指定の基準が合ってもいいと思う。そうは言っても、絶対的な基準を作れるほど色のことについては良く知らない。だからこのページは一般的基準ではなくてマイルール。
16 色
色数の少ないところから始めよう。前景色背景色の組み合わせとして見やすいとされている W3C の基準を満足する組み合わせは 256 の組み合わせの内たった 14 個である。意外なことに、注意を喚起すると思われる赤は前景色背景色どちらで使用しても赤以外との組み合わせは見にくいと判断された。
| NG | NG | OK | OK | NG | OK | NG | OK | NG | NG | NG | NG | NG | NG | NG | NG |
| NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
| OK | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
| OK | NG | NG | NG | NG | NG | NG | NG | NG | NG | OK | NG | NG | NG | OK | NG |
| NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
| OK | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | OK | NG |
| NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
| OK | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
| NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
| NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
| NG | NG | NG | OK | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
| NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
| NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
| NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
| NG | NG | NG | OK | NG | OK | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
| NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG | NG |
[メモ] ブラウザの設定が変わっても変わってほしくないものはコンテンツの見易さ
自分のサイトのユーザがどのような機器を使って自分のサイトから情報を得ているかはほとんど不明である。例えば、このサイトのユーザがコンテンツをどのようなサイズ (文字のサイズ、window のサイズ、ディスプレイのサイズ) で見ているか僕には全くわからない。
コンテンツの魅力というものは、内容がユーザによく理解されてこそ得られるもので、内容が貧弱であったり見難いものであったりすると、ユーザの理解度はさがり、よく読めば非常に魅力的な内容であるにもかかわらず、コンテンツの魅力が下がってしまう。類似した内容を提供する Web ページが大量に存在する今だからこそ、自サイトのコンテンツの理解度を高める努力をしないことは、類似した内容を提供している他サイトに流れてしまうユーザを増やすことになり、自サイトのユーザ数を減らすことになる。どのようにして他サイトに流れる引き止めるかということはサイトのオーナーにとって重要な戦略だと思う。内容コンテンツを提供する側はこのような点を考慮して、コンテンツの理解度を左右する一つの要素である「コンテンツの見易さ」に配慮したサイトを作成するべきだと思う。ここからは、このサイトにおけるコンテンツの見易さを考えてみる。
まずは、ユーザがどのようにしてこのサイトから情報を得るか考えなければならないだろう。このサイトのメインコンテンツのほとんどはテキスト情報であり、ユーザはテキストを読んで「文字から情報を得る」だろう。そこで、ユーザの内容理解の手助けとなるのは文字に関連したパラメータだろうと仮定した。つまり文字サイズ、文字字間サイズ、行間サイズ、段落間上下外余白である。り、文字のサイズを基準にして余白設定するべきだと思う。
ディスプレイ上に映し出される文字の大きさは、「ピクセルサイズ (1 ピクセルの形)」に依存する。ここでいう「ピクセルサイズ」には 2 種類あり、「ディスプレイのピクセルサイズ」と「OS のピクセルサイズ」がある。
| ディスプレイ斜辺長[in] | 横ドット数[dot] | 縦ドット数[dot] | ディスプレイのピクセルサイズ[dpi] |
|---|---|---|---|
| 15 | 640 | 480 | 15[in] * x[dpi] = 640[dot] |
| 15 | 800 | 600 |
同じディスプレイサイズの場合、ピクセルサイズは解像度が細かいほうが短い。
前者について考えると例えば、異なる大きさのディスプレイの表示可能枠いっぱいに同じ解像度で表示した場合、ピクセルサイズはディスプレイサイズが大きいほうが長い。また、同じ大きさのディスプレイの表示可能枠いっぱいに異なる解像度で表示した場合、ピクセルサイズは解像度が細かいほうが短い。すなわち、ユーザのディスプレイサイズと解像度によってはピクセルサイズは変わりうる、ということだ。つまり、Web ページで論理的に同じ大きさを指定しても、ユーザの目に入る文字の大きさは Web ページを見ている機器によって異なるということだ。
では、文字に関連するパラメータのサイズをどのようにして指定するのがよいのか。サイズ指定には大きく分けて絶対指定と相対指定の 2 つがある。絶対指定は cm, pt のようなものである。絶対指定の場合は、1 ドット当たりのインチ (dpi) が機器ごとに設定されているので、これを元にディスプレイ上で何ドットか計算され表示される。残念なことに、12 cm と指定したらディスプレイ上でも常に 12 cm というわけではない。その理由は、OS の考える dpi と実際のディスプレイの dpi が異なるからである。例えば、12 インチと絶対指定し OS の dpi が 96 dpi だとすると、96 dpi * 12 in = 1152 dot ということになり、ディスプレイ上で 1152 ドットの長さに相当する。解像度 800x600 の 15 インチディスプレイ (ディスプレイの対角線の長さが 15 インチ) では sqrt(800 * 800 + 600 * 600) dot / 15 in ≈ 66.66 dpi なので、このディスプレイ上で 1152 dot は 1152 dot / 66.66 dpi = 17. 28 in に相当する。このように、絶対指定の 12 in はディスプレイ上の長さとイコールになるとは限らない。つまり、に表示にユーザの使用している機器に依らない。長さの単位に変換できるできる大きさは 3 つあり、window の大きさに対して相対的に変化する「パーセント指定」と文字の大きさに対して相対的に変化する「em 指定」と、ピクセルサイズに対して相対的に変化する「px 指定」がある。
ブラウザ window の幅とか高さを変えるとパーセント指定していた部分はそれに対応して変化する。ものすごく私的な意見だが、このような変化によってきれいに見えるようになる場合と汚く見えるようになる場合があると思う。僕が自分のサイトを読むとき、パーセント指定によって変化してほしくないものを下に挙げる。
このような部分をもしパーセント指定すると、window の高さを縮めると要素間が詰まって表示される。一つの p 要素はある一つの内容を含み、p 要素の区切りは内容の区切りである。著者が内容の区切りを意識して書いた部分には視覚的にも余白が必要である。内容の区切りを意味する余白の高さが window の高さの変化に対して変化するのは、読者の window サイズによっては内容の理解に差が出てきてしまうことになる。したがって、上に挙げた要素間の上下外余白は window サイズに対して動的に変化するように (パーセントで) 指定するべきではないと思う。
p、pre、ol、ul、dl 要素間の上下外余白
[seo] SEOのネタメモ
- http://woork.blogspot.com/2008/03/css-message-box-collection.html
- http://www.jankoatwarpspeed.com/post/2008/05/22/CSS-Message-Boxes-for-different-message-types.aspx
- 10 Ways to Increase Your Site Crawl Rate
- Kick Butt With Internal Site Search Analytics | Occam's Razor by Avinash Kaushik
- スタートアップが押さえておくべきSEOの極意、6カ条 - ＠IT
[html] *mlのタグの使い方メモ
html、xml、xhtmlとかのタグを使うときの使用方法についてのメモ。
baseタグを使う僕なりの理由
ネームスペースとかクラスとかの考え方がある。あるネームスペースが有効な範囲内では、ある名前は其のネームスペース内で有効な名前と考えられる。baseタグを使うと同じようなことが出来ると思う。もしbaseタグに自分のホームページスペースのルートディレクトリが書いてあれば、ルートディレクトリが変わらない限り其のページが同じホームページスペース内で移動したとしても、リンク先のアドレスの変更は必要ない。
ただし、もしミラーサイトを作った場合、ミラーサイトにあるページを見ているユーザがリンク先に飛ぶリクエストは常にマスターサイトへのリクエストになってしまう、という問題がある。
linkタグrel要素とかrev要素に対応したページ
Operaのナビゲーションバーを表示させると出てくるボタンはそれぞれ、下のような感じ。各ページのheadセクションにこのようなlinkタグを付け足して、それぞれのlinkタグに対応したページを独立させて作っておくというのはどうだろう。まぁ裏取れてないけれど。
- ホーム
- <link rel="home" href="home.html" />
- 索引
- <link rel="index" href="index.html" />
- 目次
- <link rel="contents" href="hoge.html#contents" />
- 検索
- <link rel="search" href="search.html" />
- 用語集
- <link rel="glossary" href="glossary.html" />
- ヘルプ
- <link rel="help" href="help.html" />
- 最初
- <link rel="start" href="hoge.html#start" />
- 前へ
- <link rel="prev" href="prev.html" />
- 次へ
- <link rel="next" href="next.html" />
- 最後
- <link rel="last" href="hoge.html#last" />
- 親階層
- <link rel="up" href="up.html" />
- 著作権
- <link rel="copyright" href="index.html#copyright" />
- 作成者
- <link rel="author" href="index.html#author" />
それぞれのリンクタイプについての解説は邦訳：Modularization of XHTML - Defining Abstract Modulesが詳しい。
strongタグ
強調のためと太字のためというのは違うわけだ。文脈上の意味合いとして強調したい場合はstrongたぐを使うわけだし、強調したい部分を視覚的にわかりやすくするために太字にしたり斜体にしたり色付けしたりする。太字というのは視覚的な変更であって文脈上の意味合いとはまた違ったものだと思う。
[google] 検索ユーザが求めるもの
よくまとまっているページなのではないだろうか。では、「よくまとまっているページ」とはどのようなものだろうか。どのようなユーザも満足することが出来るようなページを作るのはかなり難しいと思う。自分のページが対象としているユーザを、僕はどのようにして決定すればよいのだろうか。検索ユーザからのレスポンスは、検索キーワード以外にはわからないだろう。ということは、それぞれのページが対象としているキーワードを明確にして、そのキーワードについてのコンテンツを書き上げるというアプローチが適しているのだろう。
[SEO] 表現の正規化、統一
検索エンジンがどのようにしてランク付けをしているのか全くわからないけれど、自分のサイトの中では同じものを意味する物については同じように表現するように心がけてみよう。たとえば、operaとかOPeraとかのかわりにOperaで代替するとかね。c言語の変わりにC言語と書くとかね。それ以外にも、urlの正規化とか。つまり、同じ内容を参照する際に最も信頼の置けるソースをurlにするとかはどうなんだろう。たとえば、日本語版perldocは腐るほど同じ内容ページがあるが、その内容を参照する場合に全部perldoc.jpにしたら、perldoc.jpにはすごい負担がかかるわけで。これは負荷分散の感覚からしたらだめなんだろうけど。
[SEO] パーマリンクと検索エンジン
検索エンジンには大量の情報を渡し、その中から人間に渡される情報は可能な限り最小化するべきだということ。検索エンジンは結構賢いわけで、検索エンジンを自分のサイトへのフィルタとして機能させるのは重要だということ。結局のところ、今までの検索エンジンはページ単位である。情報に対する紐付けの役割をなしている検索エンジンの結び付けられた先はページである。だから、人間は結局検索キーワードから紐付けされたページから自分に必要な情報を探しださなければいけない。このことは人間にとっては激しく面倒な話で、おそらく検索エンジンによって精度の高い情報と判断されても、人間にとって有用と判断されない。
じゃぁどうするか。人間が面倒だと思うのは検索エンジンから提示された候補から必要な情報を読みとるさいのページ内検索である。検索エンジンによっては検索キーワードをハイライト表示してくれたり、ブラウザによっては検索キーワードをハイライト表示してくれたりする。そのため、このようにして元ページに対して、情報をプラスアルファされたページを読むのが人間にとって効率がよい場合がある。しかし、残念なことにそうでない検索エンジンもあるし、そのようなブラウザを使っていない場合もある。
だから、単一のページとそこに含まれる情報は意味として単一である必要がある。コンテンツを作る側は、検索エンジンがキーワードに対して導きだすページというものに対して、単一の意味を与えるべきだ。このようにすることで、ユーザはより提示されたページが不要か有用か判断が容易になる。つまり、これまでページ内項目として意味的に分割していた部分を、項目同士の繋がりが無ければ別ページとして可能な限り分割させるべきだと思うわけだ。ユーザには必要十分で可能な限り少ない情報を与える。そうすることでユーザの必要な情報をすばやく拾い出す手伝いが出来ると思うわけだ。
ユーザのお手伝いという意味においてサービスを展開することは古い考え方ではない。googleだってそうだ。googleの検索結果のページには極力ユーザを引き止めておかないようにしておくことはgoogleだった考えていることだからね。