「wordpress」タグアーカイブ

wordpressテーマにアイキャッチ(サムネイル)機能を追加する

wordpressのテーマは多種多様にありますが、ミニマルなものを目指してサムネイルをサポートしていない物があったりします。

そういう場合に、ちゃちゃっとテーマにサムネイル機能を追加しましょう。

テーマのファンクションファイルに下記コードを追加

add_theme_support('post-thumbnails', array('post'));

これでテーマにサムネイル機能を追加する事ができます。

キャッシュプラグイン組み合わせの最適回答を求めて「Quick Cache」「WP File Cache」「DB Cache Reloaded Fix」「WP Super Cache」

前提条件

wordpressのプラグインといえばキャッシュプラグイン。何よりもまずキャッシュ。それほど重要な要素です。こんかいは「Quick Cache」「WP File Cache」「DB Cache Reloaded Fix」「WP Super Cache」の四つのプラグインを利用してどの組み合わせがこのサイトに最適なのかを考えていきます。

「Head Cleaner」「WP Hyper Response」は導入済みとします。

「Head Cleaner」はヘッダーを整理、js/cssを動的出力・キャッシュ・圧縮・結合する事が出来るプラグインです。超お勧めです。→WordPress › Head Cleaner « WordPress Plugins

「WP Hyper Response」はphpの処理が全て終わってから結果を出力するのではなく、処理をしつつ出力もするようになります。こちらもお勧め→WordPress › WP Hyper Response « WordPress Plugins

各種プラグインおさらい

各種プラグインがどういったものなのか、軽くおさらいしましょう。どのキャッシュプラグインがどういう機能があるのか抑えていないと事故になります。

Quick Cache

ページそのものを静的ファイルに出力し、利用者がページを見る場合そのファイルを閲覧する事になります。デフォルトのwordpressでは毎回mysqlに問い合わせてphpが出力・整形を繰り返すので、この部分をスキップしよう。という物ですね。最近有料化しました。→WordPress › Quick Cache (Speed Without Compromise) « WordPress Plugins

WP Super Cache

quick cache同様の効果、というよりWP Super Cacheから派生したのがQuick Cacheです。設定の内容に違いがあります。→WordPress › WP Super Cache « WordPress Plugins

WP File Cache

オブジェクトキャッシュというもので、php関数の結果をキャッシュします。→WordPress › WP File Cache « WordPress Plugins

DB Cache Reloaded Fix

はmysqlからの出力結果をキャッシュし、mysqlへの問い合わせを減らしてくれます。→WordPress › DB Cache Reloaded Fix « WordPress Plugins

全体の流れ

つまりイメージとしては、ページを表示すると記事データを問い合わせの際に「DB Cache Reloaded Fix」を参照し、記事出力の際に「WP File Cache」を参照し、ページ全体の表示に「WP Super Cache・Quick Cache」が参照されるわけですね。それぞれ受け持つ部分が違うわけです。

検証

早速やっていきましょう。利用するクライアントはpale moonです。

「Quick Cache」「DB Cache Reloaded Fix」「WP File Cache」ON

全キャッシュ生成時

Quick Cacheキャッシュ生成時

生成にかかった時間は「<!– This Quick Cache file was built for ( ao-works.net/you-can-control-cache-wordpress-plugin-wp ) in 0.42555 seconds, on Mar 8th, 2014 at 1:28 am UTC. –>」とのことで、0.4秒ですね。

DB Cache Reloaded Fixキャッシュ生成時

Quick Cacheによるページキャッシュが動作しているので利用者に影響はありませんね。

WP File Cacheキャッシュ生成時

こちらも同じです。

「Quick Cache」「DB Cache Reloaded Fix」ON

mysqlキャッシュは検索などの部分で必要になるので必要だとして、WP File Cacheが無い状態での時間を見てみましょう。

Quick Cacheキャッシュ生成時

おお、かなり違いがありますね。quick cacheがキャッシュファイルを読み込むとき、php関数のキャッシュが無いので出力を待っているのでしょうか。

「<!– This Quick Cache file was built for ( ao-works.net/you-can-control-cache-wordpress-plugin-wp ) in 4.99642 seconds, on Mar 8th, 2014 at 1:22 am UTC. –>」とソースに表示されています。キャッシュ作成に4秒の時間がかかったようですね。

「WP Super Cache」「DB Cache Reloaded Fix」「WP File Cache」ON

WP Super Cacheは設定がかなり多いです。設定の詳細については→wordpressのキャッシュを制御できるプラグイン「WP Super Cache」の設定項目解説 » aoringo works

全キャッシュ生成時

quick cacheとあまり変わりませんね。

WP Super Cacheキャッシュ生成

こちらも時間的には同じくらい。

DB Cache Reloaded Fix キャッシュ生成時

WP File Cacheキャッシュ生成時

変わりませんね。

「WP Super Cache」「DB Cache Reloaded Fix」ON

WP Super Cacheキャッシュ生成時

ちょっと遅いですね・・・。

まとめ

どちらも性能的には同じくらいのパフォーマンスとなっているようです。WP Super Cacheは設定によっては裏でキャッシュを生成できたりもするので、今回の比較では遅めですがカスタマイズ次第でかなりのパフォーマンスを引き出せるかと思います。

有料でも簡単に設定できるquick cacheか、多岐に渡る詳細な設定が可能なWP Super Cacheか。検討の参考にしてみてくださいね。

 

wordpress、フッターに表示されるスマイルマークを消す

これです。wordpressを利用しているといつの間にか居るこのスマイル。微妙にデザインを辺高するのでテーマを作ってるとちょっといらっときたりします。

実はこれ、プラグインでアクセス解析を行っていると表示される印みたいなものなのです。割と定番なものみたい。

私の場合はjetpackのアクセス解析がこいつをひょうじしていました。

消すには「ダッシュボード→jetpack→wordpress.com統計情報」を選択します。

「統計のスマイル画像を非表示」にチェックをつけて設定保存すればOKです。

 

wordpressのキャッシュを制御できるプラグイン「WP Super Cache」の設定項目解説

wordpressのキャッシュ系プラグインは数多ありますが、今回は「WP Super Cache」を導入してみました。設定について調べたい所ですが、探せど探せど詳しい説明が無いので軽くメモっておきます。

キャッシュ系プラグインは便利な反面設定を間違えると思わぬ事故に繋がりますので、「推奨」とついているからと全てをオンにするのは得策ではありません。ましてやそれで「何か不具合が出る」や「購入情報が表示される虚弱性がある」というのはちょっとどうなんでしょう。

簡易、詳細、プリロードだけを書いていくので、それら以外の設定を知りたい人は今回はごめんなさいという事で。

簡易

設定に必要な最初のページです。 キャッシングを使用するかどうか、そして生成されたキャッシュが正しく動作しているかを確認する事ができます。

詳細

動作に関しての細かな設定をここで行います。

キャッシング

ヒットしたページをキャッシュし、素早くアクセスさせる。 (推奨)

ページにアクセスした時点で有効期限が切れている、もしくはキャッシュが無い場合はキャッシュを作成し、利用者に見せます。

このチェックをオフにしていると、一番新しいキャッシュを見せます。有効期限が切れている場合、キャッシュは利用せず通常の出力結果を見せるようになります。

キャッシュファイルの提供に mod_rewrite を利用する。 (推奨)

mod_rewriteはリダイレクト機能ですが、おそらくキャッシュした静的ファイルへとクライアント誘導するのだと思われます。サーバーによっては利用できない場合があります。

キャッシュファイルの提供に PHP を利用する。

キャッシュファイルをphp関数によって出力するようになるようです。

レガシーなページキャッシング。

レガシーというのは一般的なファイルキャッシュという意味でしょうか? この中では一番遅いようです。

その他

ページを圧縮し、訪問者により速くページを供給する。 (推奨)

ファイルを圧縮(gzip)?して送信しているようですね。特に理由も無い限りはONにしたほうが良いでしょう。ソースに「<!– Compression = gzip –>」と出るので間違いないかと思われます。

304 Not Modified ブラウザーキャッシング。最後にリクエストされてから変更がないことを示す。 (推奨)

そのページが更新されていない事を伝えます。キャッシュファイルで、元ファイルは更新されていない事を証明するんですかね?

既知のユーザー向けにはページをキャッシュしない。 (推奨)

wordpressにユーザー登録されている(ログインしている)ユーザーにはキャッシュページを表示しないようにします。

Don’t cache pages with GET parameters. (?x=y at the end of a url)

URLにパラメータを含めてきた人へのキャッシュもするかどうか。普通はオフで良いと思います。パラメータを使ってwordpressサイトを作る人は導入を考えても良いかもしれません。検索などのページもキャッシュするのかな?(未検証)

Make known users anonymous so they’re served supercached static files.

ログインしたユーザーがページを表示するとキャッシュを作成します。

オフの場合「<!– Page not cached by WP Super Cache. Check your settings page. Not caching requests by known users. (See Advanced Settings page) –>」
オンの場合「<!– Cached page generated by WP-Super-Cache on 2014-03-08 00:00:06 –>」

お好みでどうぞ。

キャッシュリビルド。新しいファイルの生成中にこのサイトの登録ユーザー以外のユーザーに supercache のファイルを供給する。 (推奨)

ちょっと意味がよくわからない所ですが、キャッシュを再構築してる間は、supercacheという別途静的ファイルを供給するようにする、という所でしょうか。もしくは通常ページを見せる、かな?推奨とあるのでチェックをつけてた方が良いのかな。謎翻訳すぎて、わざわざ原文を覗いてみましたがわからなかったですぅ。誰か教えて。

追記1:おそらく後述するプリロードしたファイルをユーザに見せ、キャッシュ生成→記事表示ではなく、事前キャッシュ→記事表示&キャッシュ生成とするものだと思われます。

Proudly tell the world your server is Stephen Fry proof! (places a message in your blog’s footer)

フッターに誇らしげなメッセージを表示しちゃうぜ! という事らしいです。感謝の気持ちにどうぞ?

詳細

Enable dynamic caching. Requires PHP or legacy caching. (See FAQ or wp-super-cache/plugins/dynamic-cache-test.php for example code.)

phpもしくはレガシーキャッシュのための動的キャッシュを行うらしいです。FAQもしくはサンプルコードを見ろ、との事のようですね。キャッシュする関数や記述などを細かく設定する事ができるようです。細かなカスタマイズしたい人にはこれは嬉しいですね。

Mobile device support. (External plugin or theme required. See the FAQ for further details.)

携帯デバイスのサポートをするそうです。私のサイトは基本的にレスポンシブデザインで、携帯電話(ガラケー)のサポートは鼻から度外視なので切っています。

Remove UTF8/blog charset support from .htaccess file. Only necessary if you see odd characters or punctuation looks incorrect. Requires rewrite rules update.

.htaccessファイルからUTF8 charsetサポート記述を削除します。

Clear all cache files when a post or page is published or updated.

ページもしくは記事が、公開もしくは更新された場合に全てのキャッシュを開放(削除)します。

追加のホームページチェック。(非常にまれにホームページのキャッシングを止めることがあります) (推奨)

またもや謎翻訳。原文は「Extra homepage checks. (Very occasionally stops homepage caching) (Recommended)」です。余分なホームページチェック・・・という事でしょうか。よくわからないです。推測になるのですが、キャッシュを作成するときに、別ページのキャッシュも作成するのでしょうか。推奨とありますし。

コメントが投稿されたときに該当のページだけリフレッシュする。

これがオフだと、コメントされてもキャッシュが更新されないようです。何故オン推奨じゃないのでしょうか。

 

キャッシュされた最新のページを一覧表示する。

キャッシュファイルを一覧で見る事ができるようです。設定を変更した場合などに動作確認がしやすくていいですね。

・・・しかしもうちょっと情報が欲しいかもw

荒削りなファイルロック。おそらく必要ないですが、使用しているサーバーが非力な場合には役に立つかもしれません。警告 ! まれにですがサーバーを止めてしまうことがあります !

キャッシュファイルをロックするんですかね。非力なサーバーで、同じキャッシュファイルを同時に生成しようとした場合などのエラーを回避できるのだと思います。サーバーを止めてしまうという文章ですが・・・。

遅延 init。WordPress が読み込んだ後にキャッシュされたファイルを表示します。レガシーモードで有益です。

wordpress自体の処理が終わってからキャッシュファイルを読み込むという事ですかね。先のキャッシュカスタマイズと絡めて使うのかもしれません。

キャッシュファイルの保存にオブジェクトキャッシュを使用する。 (実験的) DO NOT CACHE PAGE secret key: hogehoge

ファイルキャッシュではなくオブジェクトキャッシュを利用する設定ですね。キャッシュをしないページにはシークレットキーを表示しろとの事です。

有効時間とガーベージコレクション

Cache Timeout

キャッシュの有効時間を設定します。この時間の間はそのキャッシュを利用し続けます。ページ更新頻度と相談して設定してください。秒設定ですね。一時間=3600 一日=86400 一週間=604800 参考にどうぞ。

Scheduler

キャッシュを削除するタイマーを設定するスケジューラ。キャッシュファイルが有効期限を過ぎると、すぐに削除されるわけではなくこのタイマーによって捨てられます。例えば大規模なサイトだと60秒でキャッシュを設定しつつ、90秒でこのタイマーを設定する必要があるようです。デフォルトでは一週間周期で削除するようですね。サイト規模に合わせて決めて下さい。また、キャッシュファイルを削除しない場合はタイマーを0秒に合わせて下さい、とのことです。

スケジュールの予定時間も表示してくれるのでとっても親切。

受け付けるファイル名と除外する URI

チェックをつけた項目はキャッシュしません。「検索」は大体毎回内容が異なると思いますのでチェックをつけてて良いかと思います。あとは運用しながら「記事を書いても○○ページは更新されないな」といった場合につけていけばいいかなと思います。

フロントページとホームページはちょっと違うので注意が必要です。フロントページとは「hoghog.com/」で表示される場所ですね。ホームページは「hoghog.com/」と「記事一覧」が表示されるページです。大抵の場合は記事一覧とhoghog.com/は同一なので問題ありませんが、固定ページをトップに表示していたりする場合は注意が必要ですよ。

あとはファイルパターンですね。サイトによって細かく設定する場合もあるかもしれません。

上で指定した除外文字列にマッチしてもキャッシュするファイル名をここに追加してください。

地味に重要です。これらをキャッシュしないけれど、この条件に当てはまるこれらはキャッシュを作成する。という場合に設定しますよ。

除外するユーザーエージェント

スマフォ専用のcssなどを用意している場合はこちらでスマフォのユーザーエージェントを設定します。また、googleなどのクローラーがやってきた場合、それらのアクセスでキャッシュを一気に作っては負担が大きいので除外した方が良いでしょう。デフォルトではbot類のユーザーエージェントが入っています。

ロックダウン

いきなり大量がアクセスが来た時のための設定のようですね。有無を言わさず静的ファイルを見せるようです。基本的には無効にしていた方が良いかと思われます。

Lockdown | IT用語辞典 | 大塚商会

ダイレクトキャッシュファイル

特定のアドレスだけを指定キャッシュしてしまう設定・・・かな? 巨大なトラフィックが来た時に~とあるので、おそらくページを丸々静的ファイルに書き出しちゃうのだと思われます。

プリロード

予めキャッシュファイルを用意しておき、botなどにはこのキャッシュを見せるようです。「Super Cache の静的ファイル」とあるので、先の「詳細」で設定したユーザー閲覧で生成されたキャッシュとは別のファイルを作っておき、botなどがやってきてキャッシュが作成されてなかった場合はwordpressによる素の表示ではなくこのファイルを見せるようですね。なるほど。

こちらの時間を「一週間」として、通常キャッシュの有効期限を「一日」とかにするのは良い感じに動作するのではないでしょうか。

当然のことながら、単純計算キャッシュファイルを二倍くらい使うのでは無いかと予想します。

プリロードされたキャッシュファイルは 分毎にリフレッシュされます。(0 にすると無効、最小 30 分)

プリロードする場合はこちらを30分以上に設定しましょう。

プリロードモード (レガシーなキャッシュファイルに対してのみガーベージコレクションを実行。推奨)

古いキャッシュファイルを削除する設定、ですかね。ガーページコレクションで設定したスケジュールで削除してくれると思います。

Preload tags, categories and other taxonomies.

タグやカテゴリーなどのタクソノミーページもプリロードします。

ファイルリフレッシュ時にステータスメールを送信する。

メールで状況を報告してくれます。

.htaccessでのjavascriptキャッシュの有効期限が上手く設定できない時の対処

タイトル長いですね。

色々と高速化に向けてサイトを弄っていたのですが、ついに「.htaccess」に手を出そうと思います。サイトには色々なファイルがあり、それらのキャッシュ有効期限や圧縮設定などを記述できます。

普通ならばFTPでファイルをあげたり編集したりという作業が必要なのですが、wordpressは便利ですね。ブラウザ上から編集する事が出来ます。

私は「Yoast WordPress SEO」を利用して編集しました。SEOに関する細かい設定をする事ができるプラグインですよ。とってもお勧めです。

さて、「.htaccess」の記述についてですが、こちらを参考して設定させて頂きました。→WordPressサイト用の.htaccess例 | dogmap.jp

ほとんど同じ内容なので、早速本題に入りましょう。

ちゃんと設定したのに、javascriptのキャッシュが設定されない!

ご覧のように一秒になってます。なんでじゃ。なんでなんじゃ。1秒といったらほとんど意味無しですね。ファックです。

 

<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType text/css "access plus 604800 seconds"
ExpiresByType text/javascript "access plus 216000 seconds"
ExpiresByType application/x-javascript "access plus 216000 seconds"
ExpiresByType application/x-shockwave-flash "access plus 216000 seconds"
</ifModule>

キャッシュ設定はこんな感じです。上記サイトの物をそのまま頂きました。デフォルト設定である「1 seconds」が設定されてて「text/javascript」はスルーされているように見えますね。

解決方法ですが、こちらにありました→ExpiresByType が JavaScript に対して効かない? | Web Design Leaves

探してみる物です。ありがとうございます。なるほど、こういう記述方法でいけるわけですね。

<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType text/css "access plus 604800 seconds"

ExpiresByType text/js "access plus 216000 seconds"
ExpiresByType text/javascript "access plus 216000 seconds"
ExpiresByType application/javascript "access plus 216000 seconds"

ExpiresByType application/x-javascript "access plus 216000 seconds"
ExpiresByType application/x-shockwave-flash "access plus 216000 seconds"
</ifModule>

修正したものがこちらです。javascriptの所を改行してあります。

設定できてます!! 良かった良かった。

スコアもかなり良い感じ。

 

アップロードする画像を自動リサイズ! 過去の画像もリサイズできるwordpressプラグイン「Imsanity」が素敵

画像をアップロードするとき、その画像のサイズがどれくらいの大きさなのか、どれくらいの容量なのかをあまり確認せずにあげてしまうズボラ野郎です。

そんなわけで、毎回のようにアップされる巨大な画像を見つつ「どうにかせねばなるない」とは思ってはおりました。

思ってはいたんですよ?

というわけで今回は画像リサイズするプラグインです。

ダウンロードはこちら→WordPress › Imsanity « WordPress Plugins

細かな設定が出来る

アップロードする場所によって設定を詳細に変更する事ができます。

「Images uploaded within a Page/Post」記事、固定ページ画面でのアップロードで機能

「Images uploaded directly to the Media Library」メディア画面でのアップロードで機能

「Images uploaded elsewhere (Theme headers, backgrounds, logos, etc)」テーマ編集画面んでのアップロードで機能

「JPG image quality」リサイズする画像のクオリティ

「Convert BMP To JPG」BMPをjpgに変更する

という設定がそれぞれできます。横幅、縦幅をそれぞれ設定すれば、アップロードする画像を自動で判別してリサイズしてくれます。実際便利。

「0」に設定するとリサイズが働かないようです。横幅を指定しなければ縦で引っかからない限りどんなに長い画像でもリサイズしないとか出来るかも知れませんね。

説明には「最近はカメラ等からも記事をアップロードできるけれど、それらは解像度が高いのでこのプラグインは最適です。高解像度の画像を使わないサイトに利用するもので、オリジナルの解像度の画像が必要なサイトには導入しないでください」とあります。

過去のアップロード済み画像も一括変換

なんと既にアップロード済みの画像も変換をかける事ができます!素晴らしいですね。

赤い警告には「バックアップ等取らないので気をつけて実行して」と書かれています。

画像を検索して一覧を出した後、さらに下に出てくるリサイズイメージボタンでリサイズを開始できます。

リアルタイムでどんどん作ってる・・・。

これでブログの画像に神経を尖らせる必要もなくなりますね。

wordpressでトップページに固定ページ、メニューに記事一覧を載せる方法

地味にはまったので備忘録として記しておきます。

通常、wordpressでサイトを作っているとこういう感じになります。通常記事が一覧表示されるわけですね。

しかし、店舗サイトなどの場合、トップページは固定ページ一枚の方が良い場合があります。

トップページ→固定ページ一枚

BLOGページ→記事一覧

というようなイメージですね。

割とはまって、普通にテーマファイルに手を加えそうになりましたw

「ダッシュボード>設定>表示設定」に入ると、このような画面になります。

ラジオボタンを「固定ページ」の方にします。

トップに表示させたい固定ページを「フロントページ」に投稿記事一覧を表示させたい固定ページに「投稿ページ」を割り当てます。

ちゃんと設定が出来ています。

記事一覧もしっかりと表示されています。やあ、wordpressの通常機能で出来たんですね。よかったよかった。

手軽に遅延ロードを導入しようwordpressプラグイン「Unveil Lazy Load」

ブログ、いやサイトにとって画像の量というのはとても気になる物ですよね。記事を作成するたびに、どれだけの画像を詰め込むのかで数時間悩んだこともあります。ええ。

そういうわけで、画像の遅延ロードに着手いたしました。なんでもっと早くやらなかったんでしょ。

色々とみてみたのですが、今回チョイスしたのは「Unveil Lazy Load」です。

[試] 速いは正義!WordPressプラグイン Unveil Lazy Load | 表示速度改善のためのこだわり施策を適用 | 試行錯誤ライフハック

詳しい仕様などは製作者様のページをご覧下さい。

使い方は簡単で、プラグインを導入して有効かするだけです。

2012年に読んだ衝撃的だった本たち » aoringo works

動作のほどはこちらのページをご覧下さい。良い感じです。

「head creaner」と「Yoast WordPress SEO」の併用は気をつけてっ

どちらもwordpressのプラグインです。「head creaner」はページの<head>部分を整理するプラグイン、「Yoast WordPress SEO」がSEOに関するプラグインです。どちらもとても素敵なプラグインなのです。この二つのプラグインについては、あまりに有名で丁寧に解説しているブログが沢山あるのでそちらにお任せしますよ。

設定によっては競合するというお話です。

「Yoast WordPress SEO」の「Force rewrite titles」のチェックは外すようにしてください。head creanerが動作しなくなってしまいます。

チェックをオンにした場合

コメントタグで「Yoast WordPress SEO」が動作している事がわかりますね。

次にオフにしてみます。

head cleanerのキャッシュファイルであるcssへとリンクしているのが分かります。

解決してみればなあんだという感じですが、かなり焦りましたよ・・。

ちなみに、head cleanerを使った場合とそうでない場合のスコアをみてみます。

使うのは→PageSpeed Insights

head cleanerオフ

head cleanerオン

恐ろしい違いですね・・・。

それでは、皆さんも気をつけてくださいねー

記事の価値を自負するなら「nofollow」リンクを使わないほうがいいかもよ

SEO的なお話ですよ~。

サイトを運営する上で必要なのは、なんだかんだいってもリンクの存在です。

で、リンクには「nofollow属性」というものがあります。

<a href="http://hoge" rel="nofollow"> hogehoge </a>

このaタグについている「rel=”nofollow”」がそれです。これがついていると、「このリンク先は見る価値無し」と検索エンジンなどに宣言する意味合いになります。

nofollow属性のリンクはどういった時につけるのか

なんとも難しい所ですが、普通に記事を書いてる分には必要無いのではないかと私は思うですよ。

そもそも皆に有益な情報を提供するためにブログをやっているのであって、そこで紹介したリンクはほとんどが重要な物のはずです。それを「価値無し」と宣言して回るのはあまり有効だとは思えません。

記事の本筋とは違う、一応リンク置いておこう、というような時はつけても良いんじゃないでしょうか。

ただし、荒らしの可能性があるコメント欄やトラックバック等は、wordpressを使用している場合「rel=”nofollow”」が原則つくようになっているようですね。

無料ブログ等のブログパーツとかにはこの要素がついていたりするそうです。

nofollow付きとそうじゃないのはどういった違いがあるのか

nofollow属性をリンクに付けるのはどんなとき? | 海外SEO情報ブログ

そのものズバリな回答がありました。翻訳ありがとうございます。

  • すべての外部リンクにnofollowが付いていたからといって、順位付けに関しては他のサイトとなんら違うように扱うことはない。
  • でもそれがいい考えとは思わない。理由は、Googleはnofollowリンクを見るとそのリンクをリンクグラフから除外するから。つまりそのリンクを新しいウェブページの発見に使わないし、スコアリングのためにそのリンクのアンカーテキストを使わない。
  • nofollowを付けてPageRankの流れを制御してため込もうとするPageRankスカルプティングはもう効き目がなくなっている。
  • 外部リンクにすべてnofollowが付いていることはプラスにもならないしマイナスにもならない。

引用させて頂くとこういう事らしいです。SEO的な意味合いで「nofollow」しても意味は無い。さらに、そのリンクを評価しないどころか文字列すらも認識しないという事です。これはとても重要なポイントですね。リンクも記事を構成する文章の一つです。仮に上記のリンクをnofollowすると「nofollow属性をリンクに付けるのはどんなとき? | 海外SEO情報ブログ」という一文がまるまる無視される事になります。

「PageRankスカルプティング」というのは、外部リンクをすべて「nofollow」にして、自分からは外部へリンクを出さず、外からどんどんアクセスを貯めるという手法みたいですが、常に検索エンジンをアップデートしている中で無効化されてるようですね。(極端な例なだけで、的確な構築をしていればpagerankを調整する事は可能のようです)

ノーフォロータグ(nofollow)リンクでSEO | ネットビジネスで20代にて転職して独立したなるひこのブログ

とはいえ、googleで「nofollow リンク」を検索するとこんなページも見つかるわけですが。なんでしょうね「自分のサイトからパワーを流出させないようにします。」っていうふわっとした説明がじわじわ来ます。もちろんこのリンクにはきちんとnofollow設定してます。

まとめ

というわけで、自信を持ってリンクを張っていった方が良いと思いますよ。普通に記述すればいいだけです。簡単ですね。

wikipedia等はスパム防止のために全てのリンクが「nofollow」設定されています。それを差し引いても濃い記事内容ですし、役に立つサイトだから自然と上位に行くわけですね。納得ですよ。

ともあれ、個人的には「nofollow」の記事で使わないリンクと使ったリンク両方とも記述できて満足度高いです!