BLUEFOX

WordPressテーマを自作する part3

BLUEFOX — Sun, 11 Apr 2010 06:33:03 +0000

少しずつですが、WordPressテーマの製作作業は進んでおります。
index.php、header.php、footer.php、sidebar.phpが終わり、現在single.phpとcomments.phpの作業中。

最近はシンプルなデザインが好みなので…本当にシンプルです。

さて配布用ということでいくつか機能を工夫しました。
右には2つのサイドバーがあるので、ウィジットも2つ分設定し自由に配置換えできるようにしました。幅が250pxと125pxでアドセンス広告がピッタリはまります。

上部のナビゲーションは、当初固定ページのリンクをそのまま並べようかと思いました。その後カスタムフィールド名を「navigation」とすることで上部ナビゲーションに追加、そして値で並び順を設定できるようにしようかと思いましたが、もう少し簡単且つ自由に設定できるほうが望ましい。
ということで上部ナビゲーションはリンクカテゴリ名「Navigation」のリンクを表示するように設定。並び順は評価設定の値を使用することにしました。管理画面で管理できるので良いかなと。

このテーマ用の管理ページを作成しても良いのですが、データベースへのアクセス増やしてパフォーマンス下げたくない。
もしカスタム用スイッチを付けるならfunction.phpを編集してもらう形にしたいと思います。

WordPressテーマを自作する part3 by BLUEFOX

WordPressテーマを自作する part2

BLUEFOX — Sat, 03 Apr 2010 11:36:18 +0000

WordPressのテーマには style.css と index.php が最低限必要です。でも大抵通常は単体記事(single.php)、カテゴリ別(category.php)、タグ別(tag.php)、日付別(archive.php,date.php)、検索ページ(search.php)、404エラーページ(404.php)など、それぞれの表示スタイル用にテンプレートを追加している方が殆どです。

まずはindex.phpを作成していきます。index.phpはそれぞれの追加テンプレートが見つからない場合に使用されます。
そのためindex.phpは全てのページの表示に対応するよう作成します。

get_header()、get_sidebar()、get_footer()はそれぞれヘッダ(header.php)、サイドバー(sidebar.php)、フッター(footer.php)のテンプレートを組み込みます。
これは複数のテンプレートでヘッダ、サイドバー、フッタ部分のテンプレートを共有しページの表示を共通化します。なのでヘッダを編集したい時はheader.phpを編集するだけで共有する全てのテンプレートに反映されます。もしファイルが見つからない場合はdefaultテーマのファイルが使用されます。
get_header()、get_sidebar()、get_footer()では例えば、get_header('ABC')とするとsidebar-ABC.phpが読み込まれますので、ある条件の場合にヘッダを切り替えたり、テンプレートの種類でサイドバーを使い分けるような事も可能です。
テンプレートに直接ヘッダ等を書き込む場合はget_header()、get_sidebar()、get_footer()が無くても問題ありません。

if (have_posts())
これは表示する投稿がある場合に実行するということ。

while (have_posts())
これは表示する投稿がある間 endwhile までを繰り返し実行するということ。
なので


○○

△△

□□

というのは投稿があればthe_post()（投稿をテンプレートタグにセットする）と○○を繰り返し実行。繰り返し終了後に△△を。投稿が無ければ□□を実行。
デフォルトテーマなら○○が投稿内容、△△が次の投稿へのナビゲーションリンク、□□が「お探しの物はここにはありません」というわけ。

wp_head()は内、wp_footer()はの前、wp_meta()はサイドバー、comment_form()はコメントフォームの

WordPressテーマを自作する part1

BLUEFOX — Fri, 02 Apr 2010 13:45:48 +0000

ウェブサイトを作る時、私がまず始めにやることはペイントソフトでウェブデザインを描くこと。

ソースを書く前にレイヤー機能のあるPhotoshop等のペイントソフトで「どこに何を配置するのか」「どんな色がいいのか」「画像類をどうするか」といったことを決めていきます。設計図というより完成予想図です。
デザインを決めるのが実際にソースやCSS弄ってあれこれやるより簡単で早いし、デザインが決まればあとは一気にソースを書いていけば良い。ペイントソフトで描いた背景、アイコン、ロゴなどの画像もそのままサイトに流用できますし、もし後にちょっとしたデザイン変更する時もこの図面画像が役に立ちます。

というわけでWordPressテーマ配布に向け新たなウェブデザインを。

完成までにいくつか変更があると思うけど大まかなデザインはこんな感じ。英語表記をどこまで日本語にするかもまだ検討中。

第一弾はBLUEFOX用テーマのいくつか機能を移植し同等の表示スタイルを有しますが、基本的には配布用に新たに作り直したテーマにする予定。比較的カスタマイズ性が高そうなシンプルなテーマです。サイドバーもウィジット対応にしユーザーの好みで自由に配置できる。

配布用テーマですがカスタムベース向きかな。

WordPressテーマを自作する part1 by BLUEFOX

ウェブサイトはDIYなり

BLUEFOX — Tue, 30 Mar 2010 16:10:49 +0000

自分のウェブデザインっていつも２週間で飽きてしまう。
でも頻繁に訪問してくれているユーザーさんも気付かないような小さな変更はしょっちゅうやってます。

多趣味で飽き性な自分が珍しく「ウェブデザイン」は何年も楽しんでます。たぶんウェブデザインって流行があったり、自分のその時の好みで比較的簡単に変えられ、そして正解が無い。作り上げていく作業もまた楽しい。
もうひとつの私の昔からの趣味クルマと同じように「コツコツと自分流にカスタマイズ」な作業が自分にハマってるんだと思う。私にとってのウェブ製作はDIYですね。
でもウェブサイトなんていくつも運営してるわけではないのでなかなか「よし！今日は新しいデザインを！」なんてデザイン考えてソースだけ書いてもコンテンツは無い。中身は空っぽ。

そんなわけで、最近はWordPressのカスタマイズも面白いしWordPressテーマでも配布用に作ろうかなと思ってます。
WordPressテーマってたぶん、沢山配布されてるけど日本語版は意外と少ないんじゃないかなって。デフォルト以外のテーマを利用した事ないので実際は知りませんけどぉ。
それに配布用ならコンテンツ不要だし、今あるコンテンツがネタ切れになる日も少しは先延ばしになるかもしれない^^;

というわけで、今後少しずつコツコツとやっていこうじゃないか！

ウェブサイトはDIYなり by BLUEFOX

超リアルタイムなアクセス解析 Woopra

BLUEFOX — Mon, 29 Mar 2010 12:55:11 +0000

「Woopra」というアクセス解析を試しにいれてみたわけですが、これが面白い。
解析内容は無料アクセス解析のごく一般的なものですが、この「Woopra」の最大の魅力はリアルタイムにアクセスを解析して表示するLive機能。
普通のレンタルアクセス解析はブラウザから解析内容にアクセスしますが、このアクセス解析はアプリケーションをダウンロードしデスクトップからJavaを使用してアクセスできる。アクセスから数秒後には解析内容が反映され、ユーザー個人、国、ブラウザなど様々な条件でマークしたアクセスがあると音やポップアップでリアルタイムに知らせてくれる。
また「Woopra」にはチャット機能もあり、ページにアクセスしたユーザーとその場で会話することもできる。

解析はページに解析用のJavascriptを貼る必要があるのでJavascriptがオフになってたり解析スクリプトがブロックされていると使えない。そのためアクセスログとしては正確性に欠けるが統計をとる程度には問題無いし、何よりただ見ているだけでリアルタイムに情報が表示される様子が面白い。

日本語版は無いので使用方法はGIGAZINEを参考に
Google Analytics以上の超強力なリアルタイムアクセス解析ができる「Woopra」を試しに使ってみました

Woopra : http://www.woopra.com/

「Woopra」を自動で設置するWordPressプラグインもあります。

デスクトップ常駐型のリアルタイムなアクセス解析ソフトは以前から他にもありましたが、実際使ってみると面白いっスねぇ。
…が！私のサイトにはアクセスが殆ど無いのは誤算でした。自分でアクセスして「おぉ！」って…。

超リアルタイムなアクセス解析 Woopra by BLUEFOX

WordPressのタグをメタキーワードに!

BLUEFOX — Sat, 27 Mar 2010 13:52:33 +0000

今時メタキーワードは意味無いのですが、All in One SEO Pack等WordPressのタグをHTMLヘッダ内のメタキーワードに設定できるプラグインは多々あると思います。
当サイトの場合はBLUEFOX専用の自作テーマだし、不要な部分は省きたいので複雑な処理でなければテーマ固有の設定で直接テーマに処理を組み込んでしまいたいな、と。プラグインがコンフリクトして動作しないものもあったので、それを回避する目的もありプラグインを使用しない方法をとりたいわけです。
ということで、テーマファイル側でメタキーワードの自動設定を組み込んでみました。

add_action('wp_head', 'meta_name');
function meta_name() {
	global $wp_query;
	if ($wp_query->is_single){
		$query = get_the_category($wp_query->post->ID);
		if ( !empty( $query ) ) {
			foreach ( $query as $cat ) {
				$list[] = $cat->cat_name;
			}
		}
		$query = get_the_tags($wp_query->post->ID);
		if ( !empty( $query ) ) {
			foreach ( $query as $tag ) {
				$list[] = $tag->name;
			}
		}
		$query = get_post_meta($wp_query->post->ID, 'keywords');
		$desc = get_post_meta($wp_query->post->ID, 'description');
		$author = get_the_author_meta('display_name', $wp_query->post->post_author);
		$list = array_merge($list, $query);
		$list = array_unique($list);
		$list = join(",",$list);
	}elseif($wp_query->is_page){
		$query = get_post_meta($wp_query->post->ID, 'keywords');
		$desc = get_post_meta($wp_query->post->ID, 'description');
		$list = join(",",$query);
		$author = get_the_author_meta('display_name', $wp_query->post->post_author);
	}elseif($wp_query->is_category){
		$list = get_category_parents($wp_query->get('cat'), false, ',', false);
	}elseif($wp_query->is_tag){
		$list = single_tag_title('',false);
	}
	echo meta_get("description",$desc);
	echo meta_get("keywords",rtrim($list, ","));
	echo meta_get("author",$author);
}
function meta_get($name='', $content=''){
		if(!$content)
			return false;

		return '' . "\n";
}

上記をfunction.phpに記述すれば動きます。

個別記事のページではカテゴリ名+タグをメタキーワードに設定します。
更にカスタムフィールド名「keywords」の値をメタキーワードに追加できます。
固定ページではカスタムフィールド名「keywords」の値をメタキーワードに設定できます。
個別記事および固定ページではカスタムフィールド名「description」の値をメタdescriptionに設定できます。
カテゴリページではカテゴリ名と親カテゴリ名をメタキーワードに設定します。
タグページではタグ名を設定します。
個別記事および固定ページでは著者名をメタAuthorに設定します。
コレが不要な場合は上記の19,27,35行目を削除。

PHPはあまり知らないので不具合あったらゴメンなさい。

ちなみに最初に申したように、スパム行為や適切なキーワードを設定しないユーザーが多いのかGoogleなど多くの検索エンジンでメタキーワードは無視されるため設定してもメリットはありません。サイト情報を自動収集する一部のサイトでカテゴリ分けに使用されるくらいでしょうか。Alexaとか。

WordPressのタグをメタキーワードに! by BLUEFOX

WordPressにOpenSearchを導入してみた

BLUEFOX — Thu, 25 Mar 2010 15:34:46 +0000

何か面白いmetaタグやlinkタグがないかと探していたら

rel="search" type="application/opensearchdescription+xml"

なるlinkタグをWikipediaで発見。
ナニコレ！と調べてみますとOpenSearchという何だかよくわからないものだったが、ブラウザの検索ボックスでサイト内検索ができるそうなので、早速導入してWordPressのブログ内検索をOpenSearchで使えるようにしてみた。

たぶんIE7,8、Firefoxの検索ボックスに「BLUEFOX Web Search」という選択肢が追加され、当サイトのブログ内検索が行えるようになるはずです。
Googleサジェスト使ってサジェスト機能を導入できないかやってみたが上手く動かず断念。

OpenSearch description document サンプル



	検索エンジン名
	検索エンジン概要
	
	http://www.example.com/icon16.ico
	http://www.example.com/icon64.png

WordPress用のUrl設定は当サイトのXMLを実際にご覧いただくのが良いかも。

と、こんなサイトじゃまずOpenSearch使わないと思うので格好だけですけど、検索ボックスから検索に限らずクエリを送信できるのでOpenSearchって使いようによってはかなり便利かもしれませんね。

WordPressにOpenSearchを導入してみた by BLUEFOX

同一URLでPC・モバイル振分はクローキングになるのか？

BLUEFOX — Sat, 20 Mar 2010 00:50:18 +0000

先日 WordPress にモバイル対応化プラグインを入れたわけですが、ふと思ったわけです。

クローキングとは、ユーザーと検索エンジンとで異なるコンテンツや URL を表示することです。user-agent に基づいて異なる結果を表示するサイトは、偽装の意図があると見なされ、Google インデックスから削除される場合があります。

…!!!
同一 URL で PC 版とモバイル版を UserAgent（以下 UA ）で振り分けた場合はどうなのか？と。

結論からいいますと、クローキングではない。

クローキングはあくまで一般ユーザーと検索エンジンで異なるコンテンツを見せること。
PC版とモバイル版が同一URLでも、各クローラーを一般ユーザーと同じく適切に振り分ければ公式に OK なわけですね。

そして

Googlebot と Googlebot-Mobile で受け取るコンテンツが違っていても問題ありません

と、モバイル側の文字数とか色々な制限で同一コンテンツの表示は当然厳しいですからね。有難きお言葉でございます。

ところで、クローキングのチェックってどうやってるんでしょう？

例えば内容が常に変化するような動的なページだと、その瞬間の内容はクローラーしか見れないわけで、ある意味ではユーザーとクローラーで異なる内容を表示していることになる。
この例でいえば単にコンテンツが頻繁に更新されているだけでクローキングではないのですが、もし機械的単純に「ユーザーとクローラーで内容が異なる」を判断するクローラーだったらクローラーはそのページをクローキングと判断するかもしれない。

実際のクローラーはページの更新時刻から動的と静的の区別し内容が変化することを理解するかもしれませんが、一般ユーザーがどう見ているか情報が無い限りクローラーは表示の違いを比較してクローキングと判断することはできない。

やっぱり、検索順位の変化とか不自然な挙動から判断してリスト作って、他のいくつかの検索エンジンスパムも同様に最終的には人手で判断するしか無いでしょうね。機械だけで判断できたらスパムリポートのフォームは必要ないもんね。

ていうか人間が判断を間違ったら意味無いよね。

同一URLでPC・モバイル振分はクローキングになるのか？ by BLUEFOX

ケータイ対応してみました

BLUEFOX — Fri, 19 Mar 2010 03:54:46 +0000

アクセスログを見ると携帯からのアクセスも無くはないようで、一応対応しておきました。
WordPressを携帯対応化するプラグインはいくつかあったのですが、機能が不十分とか WP Super Cache との互換がイマイチだとか、ただ自分好みじゃないとか。
で、結局 WP Super Cache で正式対応している「WordPress Mobile Edition」を入れてみました。

WordPress Mobile Edition : http://wordpress.org/extend/plugins/wordpress-mobile-pack/

設定もシンプルだし携帯用のページもクールだしテーマファイルも比較的カスタムしやすいと思う。
でも投稿フォームが英語表記になったり文字数のカウントが変になったり。現在 WP2.9.2 使ってますが wp_enqueue_script を管理画面で使うと不具合出るようで、プラグイン側の問題ではないのですが応急処置として「WordPress Mobile Edition」の wp-mobile.php もちょっと弄って、 wp_enqueue_script を使わずに admin_head のフックで CSS と一緒に呼び出すよう修正。Head Cleanerプラグインは同時使用するとヘッダ以降出力されないので停止。とりあえずテーマファイルからヘッダ内の並び替えだけ変更しておいた。

メジャーな携帯ならある程度対応してると思いますが、海外製のプラグインなので国内機種全てに対応しているわけでもないし文字コードもUTF-8なので古い機種なんかは文字化けするかもしれません。なので「見れないぞ！」という方は諦めてください。もともと携帯で見るようなサイトではないので変換サービスとか家のパソコンからどうぞ。ていうか「モバイルコンテンツ向け AdSense」を使ってみたかっただけだもん。
携帯ページへはUserAgentで切り替えてますので偽装すればPCからでも見れます。または携帯での表示をシミュレートするFirefox用アドオン「FireMobileSimulator」を入れて見れます。

ケータイ対応してみました by BLUEFOX

robots.txtで勘違いしていたこと

BLUEFOX — Tue, 16 Mar 2010 05:25:02 +0000

検索エンジンを制御するrobots.txt。
これでDisallowに指定されたURLは検索エンジンのデータベースに登録されないものだと思ってました。
しかし実際にはそうではなく検索エンジンにクロールさせない、そして内容のキャッシュを作成させないだけ。つまりクローラに対して「進入禁止」と「持ち出し禁止」を指示するだけであって「その場所を登録するな」というものではない。

セキュリティ上インデックスされるのは良くないとされるページも、内容は登録されないがその場所のURLは登録される。
例えばWordPressのログインページ「wp-login.php」もデフォルトでnoindexが指定されているが、その場所のURL http://www.example.com/wp-login.php 等が検索すればズラりとでてくる。
私のサイトでもContactのページもrobots.txtで制御しているがＵＲＬは登録されてしまっているわけで、スパマーが「contact」をURL検索したならそこにメールフォームやメールアドレスが記載されている場所であることを知らせることになるかもしれない。

これらを削除するにはGoogleならウェブマスターツールの削除リクエストで90日間は削除されるそうです。Yahoo!のサイトエクスプローラーも削除機能があったはず。または何処からもそのページにリンクを張らないこと。あるいはクローラに対して存在しないかのように404ステータスを返すかhtaccessでアクセス禁止にすればいいと思う。どれも面倒ですけどね。
ページの存在が見つかれば検索エンジンはrobots.txtに従って進入はしないしキャッシュの作成もしないが、そこにページがあることは記録していくでしょう。
Google の検索結果に表示されないようにする - ウェブマスターツールヘルプ

ＵＲＬだけ検索に載せて何かメリットあるのかな・・・。

robots.txtで勘違いしていたこと by BLUEFOX

XREAでのWordPress高速化

BLUEFOX — Sun, 14 Mar 2010 07:44:02 +0000

時間帯によってXREAでのパフォーマンスがガッツリ落ちるので、なんとかならないかと色々試してみました。共有サーバー、モジュール版PHPそしてセーフモードでの動作なのでやれる事はかなり限られますが。

WP Super Cache

ページをキャッシュして静的ページによる高速化をしてくれるWPプラグイン。定番ですね。
XREAだとインストールがチョットややこしいのですが、Super Cacheではないハーフオンの状態では問題なく動いてくれてます。
パフォーマンスは確実に上がりますが、設定次第で記事を更新してもページに反映されないので注意。アクセス数が多いサイトは効果抜群。

WP Super Cache : http://wordpress.org/extend/plugins/wp-super-cache/

追記：セーフオンでキャッシュ削除するとmetaディレクトリも一旦削除され、XREAなどのモジュール版PHPでは所有者がapacheになってしまいパーミッションも書込不可になりキャッシュが効きません。
wp-cache-phase2.phpの556行目付近

　
$protected_directories = array( $cache_path . '.htaccess', $cache_path . $blog_cache_dir . 'meta'　以下省略～～～

とあるところ

　
$protected_directories = array( $cache_path . '.htaccess', $blog_cache_dir . 'meta'　以下省略～～～

とすることで正しい動作に修正され、キャッシュ削除してもmetaディレクトリは削除されません。

Head Cleaner

HEAD内を整理し、CSSやJavascriptの最適化やgzip転送などフロントエンドの高速化を自動でしてくれるWPプラグイン。
HEAD内の整理だけでもスクリプト等のロード時につまづく感じが解消されパフォーマンスアップ。

Head Cleaner : http://wppluginsj.sourceforge.jp/head-cleaner/

DB Cache Reloaded

クエリ結果をキャッシュしてくれるWPプラグイン。あまりDBにアクセスしないWP Super Cacheとの併用では効果半減ですが。
XREAのような共有サーバーではDBのアクセスが混雑し遅くなることもあるので、キャッシュした場合の効果は大きいと思います。

DB Cache Reloaded : http://wordpress.org/extend/plugins/db-cache-reloaded/

W3 Total Cache

上記３つのプラグインを合わせたようなWordPress用総合高速化プラグイン。
残念ながらXREAではうまく動かせず使用は断念しました。使えるならオススメです。

W3 Total Cache : http://wordpress.org/extend/plugins/w3-total-cache/

DB自動最適化

cronを使用して週一程度でDBを自動最適化
/usr/local/mysql/bin/mysqlcheck -o -r --all-databases -uデータベース -pパスワード

自動で最適化をしなくても「Optimize DB」プラグイン等で定期的に最適化したほうが良いかなと。

Zend Optimizer

PHPの実行速度を最高数十％高速化する最適化モジュール。
/usr/local/Zend/lib/ZendOptimizer.so
なんですが、XREAではCGIモードでしか使えない。
共有サーバーではただでさえ恐縮なWordPressなのでWordPress全体を負荷の高いCGIモードで動かさないこと。
ていうかCGIモードではパフォーマンスも落ちるのでZend Optimizerを使用したとしてもメリットは無し。CGIモードではWordPressの動作不良もあるようです。
ということでアップロード機能など一部の機能はCGIモードで動かす必要があるので、一応その部分だけ設定はしておきました。意味無さそうだけど。
PHPをCGIとして動かす方法について

WordPress テーマの最適化

当サイトで使用してるのはこのサイト専用の自作テーマなのでwp_titleなどの関数のかわりに直接文字列を入れる事で少しは負荷低減できるかも。まだやってない。今のところクエリ数も10から多くても30程度だし、ロード時間も平均して0.300秒前後なのでテーマは特に問題なさそうだけど、広告の読み込みに時間とられちゃってます。
CSS Spliteを使用、画像の最適化、CSSレイヤーや背景固定等を使用しない、無駄なスクリプトをロードしない等細かい点で快適表示のため最適化はしてます。

WordPressの不要な機能を停止

リビジョン等、無駄にDBを肥大化させパフォーマンス低下につながる機能は「disable-revisions-and-autosave」プラグインでオフ。
また投稿内容の自動整形機能wptexturizeもオフ。

と、色々試してみましたが、自分のサイト用にきちんと最適化するにはもう少し時間がかかりそうです。XREAのネットワークが貧弱なためレスポンスの悪さはコレだけでは回避しきれないと思います。

(仮) coreserver/xrea 負荷観測障害メンテナンス情報　サーバーのソフトウェア情報

XREAでのWordPress高速化 by BLUEFOX

寺町沙也さん

BLUEFOX — Fri, 12 Mar 2010 23:18:30 +0000

2007年11月、寺町沙也さんという14歳の女の子が学校の部活中に突然倒れ心停止。
その後一時的に回復し、仙台の病院で補助人工心臓の手術を受けたが、その後余命半年を言い渡されたそうだ。
アメリカでの移植手術に必要な費用1億3千万円がさやちゃんを救う会によって募金が集められついに先日目標額に達したそうです。

実はですね、私先日知ったんですよ。
私の中学校3年間担任だった先生が、沙也さんの担任の先生だったんです。
そして沙也さんが倒れた時、心臓マッサージをしたのがその先生で。って先生がTVに出てましてね。
本当にビックリしましたよ。なんだろうな、中学卒業して10年以上経つけど改めて先生スゲェよと。感動と尊敬。

さやちゃんを救う会のサイトに、沙也さんと先生が並んで写ってる写真がありまして「うわっ！先生だ！」って。
すっかり白髪になっちゃってたけど、でも相変わらずのヒゲで熊っぽい。私が生徒だった頃からそうでした。

とにかく目標額達成して良かったです。でも心臓待ちになっちゃうのかな。
久しぶりだな、マジに人を応援したいと思ったのは。頑張ってほしい。
でも応援しかしてあげられない自分に正直チョット凹みました。

追記：5月8日無事移植手術が成功したそうです。よかったぁ。

寺町沙也さん by BLUEFOX

robots.txtイメージ検索用の調整

BLUEFOX — Fri, 12 Mar 2010 02:27:11 +0000

悪質なクローラーは問答無用で弾いていますが、robots.txtをしっかり読んで従うクローラーにもしっかりサイトに応じた設定をするべきなのかな。
アクセスログを見ると画像への直リンクがズラリ並ぶこと多かった。その直リンク元は某検索エンジンのイメージ検索。気分が良いものではない。転載のされ負荷かけられてるんだもの。CG系等、画像をメインにしたサイトだとイメージ検索というのも結構なダメージになりそうですね。

でもイメージ検索から来てくれる方も多いので、画像すべてをクローラに拾われるのを拒否するのはチョット。
そこでイメージ検索するユーザーにとって不要な画像、たとえばサイトの装飾用の画像やボタン・アイコン類は拒否しておく。それからWordPressでは原寸の元画像の他にもサムネイル画像など数種類の大きさの画像が作られるので、この縮小画像も拒否しておいて良いでしょうね。

Disallow: /files/*-*x

みたいな感じで。
あるいは逆に縮小サムネイルだけ許可するっていうのもアリでしょうか。「原寸見たけりゃサイトに来てね」と検索エンジンに拾われる事ばかりでなく、拒否することもアクセスアップに必要ってことで。SEOの情報とかって画像検索の事書かれてるサイトって殆どないような…。
ていうか検索エンジンの検索結果で直リンクって危険な気がしません？画像を別のものに置き換えたりリダイレクトすればサイトに入られなくても、ある文字を検索されれば持ち主のやりたい放題。画像ではないものにリダイレクトさせたり数GBある画像に置き換えたり。こういう検索サービスとかってよく考えると発案者のお国柄とか人柄とか見える気がしますよねぇ。

robots.txtイメージ検索用の調整 by BLUEFOX

ウェブサイトとモニター解像度

BLUEFOX — Thu, 11 Mar 2010 14:59:50 +0000

BLUEFOXのアクセス統計では、モニターの解像度「1024ｘ768」でのアクセスが最も多い。でもあくまでこれは解像度別であって、幅だけで言えば1024より大きい1280やそれ以上のモニターの方がずっと多い。
以前は1024幅におよそのサイドバー幅を引いた大きさ約800px以下に収まるようウェブサイトを構築してましたが、今回のリニューアルでは、アクセス統計を見た結果幅1024px以下を基準に構築しました。時は満ちた…と。

これにはモニターの統計だけでなくブラウザのシェアと機能も関係してきます。
例えば古いブラウザならずっとサイドバーに表示させていたブックマークも、最近のブラウザはサイドバーが無くてもブックマークが利用しやすくなっているため、サイドバーを表示していないユーザーも多いかもしれないし、サイドバー自体もFirefoxとか簡単に表示・非表示が切り替えれる。それどころかブラウザのブックマークを利用せずソーシャルサービスしか使ってない人もいると思います。
そう考えるとまだ幅1024のモニターを使っているユーザーは多いとはいえ、そろそろ幅1024以下のウェブサイトに移行して良い頃なのかなと思いますね。一番良いのは固定幅のウェブデザインにしないことなんでしょうけど、人間には見やすい1行の文字数とかあると思いますし。
…ウェブデザインは人間の心理を考えたり奥が深いですね。

アクセス解析を設置していない方はXREAのアクセス解析サービスのサンプルを見るだけでも参考になると思います

ウェブサイトとモニター解像度 by BLUEFOX

htaccessでお帰りいただこう

BLUEFOX — Tue, 09 Mar 2010 18:56:22 +0000

どうしてこう中華のクローラはお下品なんでしょうね。
先日もNokia3108/1.0 (03.01) Profile/MIDP-1.0 Configuration/CLDC-1.0という携帯電話（？）か何かのUserAgentを名乗る謎のクローラがrobot.txtを一度も読むことなく、そしてディレイ無しの短時間アクセスという頭の悪い暴れ方していきましたね。悪名高き「百度」のクローラも最近だいぶマシになったようですが…どのみちあちらの国からのアクセスは不要。

さて、こういうクローラには早々お帰りいただくためチョット危険ですがhtaccessでこんな設定をしてみました。

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} (Baidu|Yeti|yodao|Tasap|Qihoo|Sogou|Sosospider|YoudaoBot|Daumoa) [NC]
RewriteRule !robots\.txt$ http://%{REMOTE_ADDR} [R,L]

いわゆるオウム返しというやつで、robot.txt以外にアクセスしたらクローラ自身のIPアドレスにリダイレクトさせちゃいます。効果は・・・どうでしょうかね。
ちなみに百度の場合だと、百度のトップページにリダイレクトするようです。他は調べてない。

そして先日暴れたクローラ用には下記のオウム返しを追加して様子見。

RewriteCond %{HTTP_USER_AGENT} Nokia3108
RewriteCond %{REMOTE_ADDR} ^115\.238\.
RewriteRule . http://%{REMOTE_ADDR} [R,L]

htaccessでお帰りいただこう by BLUEFOX