カテゴリー別アーカイブ: ブログ運営

SSL化後のアクセス推移と収益について、やっぱり駄目でした

2017年11月に当ブログもSSL化、それと広告(Google AdSense)の見直しをしました

ブログをAMP化・SSL化してるサイトが最近増えてきていて気になっていたのでなんとか時間を確保して、とうとう当ブログでも導入しました すぐ終...

今回はその後の経過について書いてみようかと思います

SSL化後のアクセス数推移について

最近、他所様のブログを見てるとどんどんSSL化されてるし、ユーザー数の多いChromeブラウザはSSL化されてるとアドレスバーに「保護された通信」と表示されるようになっていて、地味に差別されてるのもなんとなく嫌な感じです

面倒くさいけど、流れに乗らなきゃなぁと思ったので頑張ってやってみました

そして、SSL化したブログで実しやかに語られてるのが

「SSL化したらアクセス数が減った」

なんですよね

全部のブログではないですが、それでも検索するとぞろぞろ出てくるので結構ある話っぽい

まぁSSL化するとhttp→httpsになる(URLが変わる)のでGoogle(検索エンジン)から見ると別なサイトに扱いになるそうです

それ以後のURLが違うなら別なサイトの可能性はありますが、httpのところのs、一個あるかないかだけだと同じサイトじゃないのかって僕は思うんですけどね

まぁ、僕みたいなITスキルが低い人にはわかんない何かあるのかもしれません

一応、URLが変わってもリダイレクト設定をしておけば、ページ評価は引き継がれるという話なんですが何故か駄目です

僕の体感としてはリダイレクトするようになったのを機会に、もう一度(特に投稿日が古い記事は)評価が見直されてるような印象を受けます

それで、SSL化しての当ブログのアクセス推移についてなんですが

はい、タイトルにある通り駄目でした!

僕のところも減少しました!

アクセス数についてGoogle Analytics・AdSenseの規約的にあまり大っぴらには書いちゃいけないらしいし

元からたいしたのことない数字で恥ずかしいので、どれくらい減ったか曖昧に書きますが・・・

だいたい20%くらい減少してました!イヤッホー!

20%って構大きな数字だとは思うのですが、検索すると40%くらい減ったとか、もっと減少してる人もいるみたいですね、なんてこったい

しかも、この20%減少って数字は11月と12月の比較なんですよね

何もない11月より、いろいろ忙しかったり暇だったりする年末のほうがアクセス数伸びそうな気もするんですが減ってしまったので今後が心配です

そんな訳で、みなさんもSSL化するときは注意して下さい

今現在、SSL化する流れはたしかにあるのですが、ペナルティめいたものも同時に存在するので、それが改善されるまで(されるないかもしれないが)もう少し様子見してもいいかもしれませんね

広告見直し後の収入について

次は見直した広告について

アクセス数が減少した割には意外にも広告収入は増えました

最近、使ってる人が増えてる、おすすめしてる人が多い関連コンテンツユニット

僕も導入しましたがたしかに優秀なデータを出してるなぁ・・・という感想

ただ、Amazonアソシエイトなど成果報酬型の方は少し減少しましたね

もしかしたら、クリック報酬型の方に人が流れてる可能性もありますね

まぁ、ここらは一月だけじゃ判断が難しいところなので(アクセス数の方も含めて)、もう数カ月気長に見守って行きたいです

[WordPress]バックアップは一度復元出来るか確認するべき、BackWPupから復元出来なかったのでバックアッププラグインをUpdraftPlusに乗り換えました

先日、記事が一つ消えてるのに気づいた

ちょうど一つのテーマで分けて連投してる記事だったので歯抜けしていることに運良く気づくことが出来た

その頃に記事の整理を行ったことが有って、時事ネタ的な古い記事を非公開にしたり、不要な下書きを削除したりしたことがあったので、もしかしたら間違えてその記事も削除してしまったのかもしれない

WordPressはシステム上、ゴミ箱に30日間保存してくれるらしいが、そちらを確認してもなかった

何はともあれ記事が見つからないのは事実、しかし僕は抜け目なく日頃からBackWPupでバックアップを取っていたので、ちょっと面倒くさくはあるけど復元は出来るだろうと思っていた・・・のだが駄目だった

まず僕はInstant WordPressというソフトウェアを使ってローカル環境にWordPressをインストール、そのWordPressにバックアップデータを当てて消失した記事を復元し、オリジナルのWordPressに手動でコピーしようとした

理由はバックアップデータ(XML)の復元を行ったとき、どういった挙動をするかよく分からなかったから

差分(消失した記事)だけ復旧されるのなら良いのだが、もし記事をバックアップ時点(古いデータ)に上書きされたら、たった一記事復旧するつもりだったのが、他の記事まで被害が拡大して余計面倒くさいことになるからだ

image

それで、バックアップのXMLファイルをWordPressにインポートしてみると「投稿のインポートが失敗しました」の文字の羅列が発生した

エラーを読むと、いくつかの記事がインポート出来ていない、インポートそのもの出来ないのは予想外だった

更に試すと、WordPress標準のXML出力機能から出力したファイルでも、同じ記事をインポートに失敗する

原因は不明だが、とにかくXML出力機能が壊れている

sqlファイル(データベース)もバックアップがあったので、そちらも試してみたがやっぱり無理だった

これではバックアップとして不完全だ、よろしくない

結局、以前作ったミラーサイトから記事を引っ張って復元することにした

fc2blogから、WordPressに乗り換えて一ヶ月半ほどが経ちました WordPressはカスタマイズすればするだけ、自分好みにする...

ミラーサイトのバックアップは記事を投稿した時点のものしか保存されない

僕が消失した記事は投稿後、何度か修正していたので、その修正が反映されていないため手直しが必要だった

だから、出来たらBackWPupのバックアップデータを使いたかったのだが、無理なら仕方がない

とりあえず、今回、消失した記事はこれでなんとかなったが問題は今後、ブログのバックアップをどうするかである

これはBackWPupからUpdraftPlusという違うバックアッププラグインに乗り換えることにした

試してみたら、UpdraftPlusというプラグインでならブログのバックアップも復元も可能だった

また、調べてみたらどうもBackWPupよりUpdraftPlusの方が世界的にメジャーなプラグインらしく、インストール数を見るとBackWPupよりたしかに多く使われている

UpdraftPlusを使ってみて良いと感じたところは復元までプラグインでサポートしていてとても簡単なところ

BackWPupはあくまでバックアップファイルを作るだけで、復元まではプラグインでサポートしていない

FTPやサーバーのデータベースを駆使する、手動の泥臭い方法で普及しなければならないので面倒だ

また、無料で15GBまで使えるGoogleドライブにもプラグインが無料で対応してくれているのもポイントが高い

そんなわけで、UpdraftPlusは使ってみるとなかなか良いバックアッププラグインだった

こんにちは 先日、ブログの記事が一部消失してることがわかったんですよ 理由はわからないんですけど、一部記事を編集・削除したりしていたので...

ただ、フルバックアップはUpdraftPlusに任せることにしたが、部分バックアップにはまだBackWPupを使ってる

具体的には記事を投稿したら、メールアドレスに記事文章のコピーとxmlファイルを送るように設定している

というわけで、皆さんもバックアップはただ取ってるだけでなく、上に書いたようにInstant WordPressというソフトウェアを使えばノーリスクでWordPressをいじることが出来るから、本当に復元出来るかそれで一度試してみたほうが良いと思うよというお話でした

SNSとブログの連携情報伝達表を作って、集客とかSEOとか考えてみた

個人が情報発信をするのが当たり前の時代になりましたが、その情報発信するツールにもいろいろな物があります

定番のものだとブログ、Twitter、Facebook

最近人気のInstagram、一昔流行ったmixi、他にもTumblr、Google+といったマニアックなものまでとたくさん複数使いこなす人も多いです

そして、これらの情報発信ツールは今は連携機能を設定出来るものも多く、複数のサービスに一度で同時に投稿出来るようになりました

しかし、それ故に複数のサービスを使い連携していると「今、どんな流れで連携しているんだっけ?」と全体図がわからなくなってきます

というか、僕がわからなくなりました

そんなわけで、僕が今使ってるSNS及びブログの情報伝達経路を図にしてみました

まぁ、こんな連携方法もあるんだなと参考程度に見て下さい

僕は情報発信はブログを中心に据えて考えています、なので

赤枠サービス→サービスとブログで相互リンクしている

黄枠サービス→サービスからブログに一方通行のリンク(バックリンク)

というように図を使いました

あと、僕がサービスの利用状況も書いておくと、fc2blogとamebaBlogはWordPress(当ブログ)に移る前に使っていた旧ブログですね、万一迷って旧ブログの方に飛んでしまった人のために新ブログのURLだけ書いてます

Tumblr、ミクシィ、Path、Google+は今は利用頻度は低いけど連携だけしてる状態です

WordPress.comはWordPress(当ブログ)にあるSNSとの連携外部サービスですね、一応ブログの機能と分けて図にしました

MirrorBlogとGmailはただの当ブログのバックアップ先なだけで非公開です

結局、主に利用してるのはBlogとTwitter、Facebook、Instagramと定番サービスだけですね

あと僕はせっかく投稿するなら多くの人に見てもらいですし、公式の連携機能を使って出来るだけたくさんの利用しているサービスと連携出来るようにしたつもりです

しかし、IFTTTのような第三者サービスを使えばもっと連携パターンが増やせますし、調べたらHootsuiteのような一度に複数のSNSを管理するツールもあるようですね

そういうは大抵、有料、もしくは有料プランに映らないと制限があるみたいですが

WordPressからの情報伝達表

数えてみると一度の投稿で6サービスにも連携できているんですね

けど、実際のところBlogにまで流入があるのはTwitterかFacebookくらいですはありますが

ただ、一昔ほど効果がなくなったとはいえ、バックリンクがもしかしたらSEOに貢献…してる・・・かも?

Twitterからの情報伝達表

3サービスに連携できています

とはいえ、FC2blogとmixiは死んでる状態なんですが、Facebookからはときたま反応を貰えます

Instagramからの情報伝達表

5サービスと連携できています

ちなみに、Instagramから直接、Facebookと連携することも可能なんですが僕は他のSNSとの連携も考えてTwitterを間に挟んでます

あと、書いてませんがインスタグラム標準のツイッター連携だと写真が投稿されないので、本当は間にIFTTTを挟んでます

伝達経路だけを見ればTwitterにも同時投稿に出来る上位互換になっているので、画像が無ければ投稿出来ないという制限さえもしよければ、多く場所に投稿できるので多くの反応が貰えそうです

ただ、僕はInstagramはパソコンでは基本的に使えないというのが地味に嫌いだったりする

あと、その際はTwitterの文字数制限もあるので気をつける必要はありますが

ところで、僕は最近の流行に乗って最近になってからはじめたのですがちょっとポストするだけですごい反応を貰えますね

mixiもTwitterも少し落ち着いた頃から初めていたので、今熱いSNSというがのこんなに反応が貰えるのかと驚いてます

ただ、仕組み的にかなりクローズドなようなのでブログ等の集客には扱っているジャンルにもよるでしょうけど、あまり向いてないように思えます

Facebookからの情報伝達表

たぶん世界最大のSNSのFacebookですが、意外にもFacebookから伝達出来るサービスは僕が使ってる中ではありませんでした

なので情報の拡散性はいまいちなのですけど、上の図を見ればわかりますが他サービスからの情報はFacebookに集約できるようになってるんですよね

だから自分がした投稿を確認するのにはベストなSNSです、そういう戦略なんでしょうかね

まとめ

いろんなSNSサービスと連携方法があって頭がこんがらがって来ますね!まぁ全部使う必要もないですけど

図を作るだなんてなれないことをしたので疲れました

[WordPress]画像ファイルのアップロードがエラーするようになったときの対処方法

久しぶりにWordPressに記事を投稿しようとしたらWindowLiveWriterが「このブログでは画像の投稿がサポートされていないため、以下の画像を投稿できません。」と表示する現状が起きた

なので、WordPressから直接、新規投稿しようとしたが次は「アップロードしたファイルを~~~に移動できませんでした」と出てしまう、つまるところ画像ファイルがどうしてもアップロード出来ない

WordPressで画像ファイルがアップロードエラーする場合の2つの解決法 | IT便利帳

調べるとファイルのアクセス権かキャッシュプラグインが原因の可能性があると出てきたので試してみたが駄目

次はプラグインを全部止めてから投稿してみると正常にアップロードできた

そんなわけで、どのプラグインが問題を起こしているかチェックしていったら原因は画像圧縮プラグインのEWWW Image Optimizerであった

プラグインの更新をしたのだが、どうもそれで何かがおかしくなってしまったらしい、そんなわけで利用をやめることにした

この問題が起きたとき、前に投稿した記事も画像がアップロード出来ずに放置していたので、てっきり原因は同じかと思っていたら別々だった、なんとも紛らわしいことか

https://dtman.info/post-12136/

[WordPress]画像のアップロードがWindow Live Writerから投稿したとき何故か出来ていないときの対処方法

ノート パソコンのキーボード, コンピュータのキーボード, 白いキーボード, コンピュータ, ラップトップ

僕はブログの投稿にいつもWindow Live Writerを使わせてもらっているのだが、ときたま投稿したのに記事に画像が表示されない、壊れていることなどがあった

どうしたんだろうと思って、Window Live Writerの下書きから記事を呼び出して再投稿しても修正されない

試行錯誤して、もう一度画像フォルダからドラッグ・アンド・ドロップしたみたら治ったのでそうしていたのだが今回、また再発してようやっと原因が分かった

不具合の原因

どうもWLWの再投稿は記事データを全部アップロードし直しているわけではなく、差分だけをアップロードしているようだ

そして、最初の投稿のときに何かしらのでエラーなどで正常に投稿出来ていなくても、WordPress側はアップロードした分のデータはそのまま保存してしまうらしい、WLW側も再投稿の際にそれを正常なデータと扱って差分だけをアップロードしてしまう、つまるとこエラーが起きてもそのチェックがないのだ

そういえば、今回発生した記事はインターネット環境が不安定なところでアップロードしたので、時間が異常にかかったりエラーが起きたりしたような覚えがある、そのためデータの重い画像ファイルが正常にアップロードされなかったのだろう

また、それ以前に起きたときも下書きのアップロードを何度もした記事が起きていたような気がする

これを解決する方法はこうだ

1,記事をコピペして別に保存しておく(僕はWLWを二重起動して新しい記事として一時保管した)

2,全て消して再投稿する

3,1で保存しておいた記事をまたコピペして再投稿

これで行けるはず

分かってみれば単純なことなのだが、僕はこれに気づくまでかなり時間を浪費していた

しかし、この画像が正常にアップロード出来なくなる問題はについては検索をかけるとちらほら書かれているのだが、同じ原因からの記事は見当たらないんだよな

みんなそんなに安定した環境からアップロードしているんだろうか

追記

上記の後、またすぐ画像がアップロードできていない現象が発生した

設定を見直した所、回線が不安定なのではなくサーバー容量がいっぱいだったのだが、今回アップロード出来ていない原因みたいだ(エラー表示はでない)

image

サーバーのディスク容量を見たら見事にゼロだった

どうも、設定していたBackWPupが際限なくバックアップ保存を繰り返していていつのまにか容量上限に達していたらしい

ダッシュボードのBackWPup→バックアップから古いバックアップデータを消去したら治った

設定を見直したらブログのフルバックアップデータ(1GBオーバー)を30日間(世代)保存する設定にしていた原因だった

設定するときにどうせサーバー容量余ってるから大丈夫だと思ったのだろう、とりあえず最近はあまりブログの行進もないので一週間4世代に設定して運用することにした

WLWはやはり差分しかアップロードしてくれない使用なようで、画像が投稿出来なかった記事は上記の手順で再投稿が必要だった

一時的にバックアップデータを消していないのに画像がアップロード出来ていたのはキャッシュやプラグインを削除してたからかな

プライバシーポリシーをコピペしてブログに追加してみた

当サイトはGoogle AdSenseやアマゾンアソシエイトプログラムに参加しています

以前、ブログ作成しているときに、それらを使用している際はたとえ個人ブログでもプログラムに参加している旨を書かなければならないと聞いていのたですが、記事作成の方を優先してしまい今まで手を付けていませんでした

これらのことを記載してない場合は最悪のケースですと広告の停止処置になるそうです

ということで、時間が出来たので重い腰を上げてようやっとプライバシーポリシー(これらのことを記載するのをプライバシーポリシーというらしい)に手を付けてみました

めんどくさいのでコピペで済ませる

とりあえず使ってることを記載してくださいね~といった旨の規約は書かれてるんですけど、そのこと示すための記事は自分らで作らないといけないようです

面倒くさいので、広告会社側がコピペで済ませられるようにしてくれればいいのにね!

というわけで各管理人が自分で文章作成してもいいのですが、それって面倒くさいよね~と思っていたら、例文をコピペフリーで配布してくれてるところがありました

感謝感謝でございます

ほかサイト様のプライバシーポリシーを覗いてみると、このコピペを使ってるところがちらほらありますね

アマゾンアソシエイトプログラムだけは文章が決まってる

で、ほとんどのASPはプライバシーポリシーで書かなければならない文章は決まっていないそうですが、みんな大好き、大手のアマゾンアソシエイトだけは決められているらしいです

10. 乙がアソシエイトであることの表示  乙は、本規約、乙による甲のコンテンツの使用、または本プログラムへの乙の参加に関して、いかなるプレスリリースの発行も、その他の発表・広告もしないものとします。乙は、本規約により明示的に許可される以外には、甲と乙との関係につき不実表明や誇張(甲が慈善活動やその他の運動を支援、後援、支持または貢献しているという表明または暗示を含む。)をせず、甲と乙の間、またはその他のいかなる個人もしくは企業との間の関係または提携を表明したり暗示したりしないものとします。乙のサイト上のどこかに 「Amazon.co.jpアソシエイト」、または「[乙の名称を挿入]は、Amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、Amazonアソシエイト・プログラムの参加者です。」の文言を表示しなければなりません。甲は、この文言あるいはグラフィックロゴを適時変更することがあります。

Amazon アソシエイト(アフィリエイト)

といわけで、僕はプライバシーポリシーをこんな風に作成してみました

プライバシーポリシー
当サイトに掲載されている広告について当サイトでは、第三者配信の広告サービス(Googleアドセンス、Amazonアソシエイトなど)を利用して...

WordPressだけど固定ページをメニューの目立つところじゃなくて、サイドバーの目立たないところに寄せてみた

そんなわけで、礼儀としてプライバシーポリシーを載せなきゃいけないけれども、ブログを覗きに来る人にとっては正直どうでもいいですよね~、普通は見ません

気になるのなんてブログ運営者だけかと思います、なので目立つところにあるのは不親切だと思いました

というわけで作成した固定ページを普通に作成したら出来る上じゃあなくて、横のサイドバーに設置してみました

ここを見て目立つところに出来がちなメニューから外します

そして、ウィジェットのテキストからサイドバーのあまり目立たないところにリンクを作成しました

他の人もフッター(一番下)とかにテーマを編集して設置しているみたいです

まとめ:設置しなくても大丈夫な気がするけど念のため

当ブログの運営も既に6年・・・なんだか今更ですよね・・・

6年間全期間、これらの広告を使っていたわけではないですけども、既に何年間かは使ってます

それでも、ペナルティを受けることなく今まで使えてきました

それを考えると垢バンされる可能性もあるけども、ほぼ可能性としてはゼロで気にしなくてもいいと思うのだけど、ここは心配事をなくすためにも時間があったら設置しておきましよう

なんだかブログの見栄えも立派になるような気がするしね!

死んだ過去記事を蘇らせろ!ブログ運営が続いたら見直してみたい5つのポイント

-shared-img-thumb-TAKEBE160224360I9A0623_TP_V

当ブログも気づいたら6年以上運営してました!

ついさっき、当ブログの過去記事の見直しをしていたら気づいて、我ながらびっくりです!

何をやっても三日坊主な私なのですが、珍しく続いているものです

ブログ開始当初の頃を記事を見てみると、文章も未熟で我ながら中身の無い、恥ずかしいことばかり書いて言います

そして、恥ずかしいだけなら「あの頃は俺も若かった・・・」の一言で済ませて良いのですが、そのような記事はSEO対策上、Googleから悪い評価も貰う可能性があるそうです

SEO対策の指標とするべき、Googleウェブマスターのブログに以下の様な文言があります

なお、低品質なコンテンツがサイトの一部にしか存在しない場合でも、サイト全体の掲載順位に影響を与えることがあるということにご注意ください。低品質なページを削除したり、内容の薄いページをまとめて役に立つコンテンツに改善したり、もしくは低品質なコンテンツを他のドメインに移動させたりすることが、最終的に良質なコンテンツの掲載順位を改善することにつながります。

Google ウェブマスター向け公式ブログ: 良質なサイトを作るためのアドバイス

特に僕の場合は、アメーバ→FC2と移転してきているので、WordPress的なSEO対策が過去記事は全然できていません

そんなわけで、SEO対策としてどのようなところを直せば良いのか、一度、当ブログの見直しをしてみました

その際の、ポイントと対策の記録を残しておこうと思います

僕が利用しているWordPressを基本的に書いていますが、他のブログサービスでも応用が効く所は多いはずです

過去記事のSEO対策ポイント

低品質なコンテンツとはどんな記事なのか?

考え方としては、低品質なコンテンツ→Googleに相手にされてない記事→アクセス数が少ない記事・・・ということになります

また、アクセス数が少ない記事を炙りだすと、自然と

  • 文字数の少ない記事
  • 時事ネタを扱った記事
  • 日記的な記事

・・・といったような記事が出てきて、直感で、あ・・・これ駄目な奴や・・・というのが自分でも分かるかと思います

アクセス数の少ない記事の探し方

Google Analyticsを使う方法

2016-04-24_15h27_06

左側のタブから

行動→サイトコンテンツ→すべてのページを選択することで、ブログ内のすべてのページのアクセス数を見ることができます

ただし、アクセス数が0のものは表示されません

万が一ですがアクセス数0のものもあるかもしれませんので、アクセス解析の期間は長めに設定したほうが良いでしょう

また、プライマリ ディメンションの欄のところを、ページタイトルに設定すれば記事名で見ることができます

ただ、カテゴリーページなど・・・記事タイトル以外も混ざって表示されるため、いまいち見づらいです

しかし、SEOの指標とするべき、Googleの情報なので一番、信頼するべき情報でしょう

Jetpackのサイト統計情報を使う方法

2016-04-24_15h40_20

人気の投稿とページ→概要

そして、統計期間を全期間に指定すると、今までの記事別アクセス数が表示されます

ただし、こちらも、アクセス数が0のものまでは表示されません

また、アナリティクスより、アクセス数の少ない記事が抜けて表示されているようです

simplicityのアクセス数表示機能を使う方法

2016-04-24_15h45_08

simplicityには記事一覧と一緒にPV数を表示してくれる機能があります

そのまま、編集画面へと飛ぶことができるので、便利な機能です

2016-04-24_15h44_30

カスタマイズ→管理画面→管理者のみにPV表示・・・で設定できます

SNS Count Cacheを使う方法

WordPressのプラグインです

これを使うことに寄って、ブログ内のシェア数を表示することができます

2016-04-24_15h57_57

インストールするだけで、自動でシェア数を表示してくれるし、日本語なので使いやすいです

シェア数が少ない→アクセス数が少ないことなので、低品質なコンテンツを探す目安になります

また、このツールはシェアが0のものでも表示してくれるので、上記のsimplicityや、Google提供のアナリティクスのアドオンを使うことで、PV数と組み合わせて、より低品質なコンテンツとやらを炙りだすのに役立つかと思います

参照:ぱぱっとブログのアクセス解析にグッドな『Page Analytics(by Google)』

低品質なコンテンツを非公開にする

僕の日記として続けている当ブログですが、開始当初はホントに酷く、100文字もない記事がザラにありました

当ブログを開始した6年前はまだ、スマートフォンの普及率も低く、ツイッターも今ほど市民権を獲得していませんでした

かくいう私も、当時はツイッターを始めたばかりで「このツール・・・どうやって使えばいいの?」と途方にくれていた覚えがあります

しかし、短文で記録を残しておきたいという、需要は昔からあったのでしょうね~

他所様の古くから運営しているブログでも、同じようなことしてたりするところがあるのですが・・・

ブログをツイッター的に使っていて、短い文章量でポストしている記事が、かなりありました

多くの人にとっては、ブログというシステムより、ツイッターという短文(気負わない)で、よりコミュニティなツールのほうが性に合っているということなんでしょうかね・・・

そんなわけで、上にある、ウェブマスターの記述にある「低品質なコンテンツ」にこれらが該当すると考え、文章量が少なく、かつ中身の無い記事は全て非公開設定にすることにしました

別に、非公開ではなく削除してもSEO上同じなのですが、あくまでも、当ブログは自分の日記の位置づけなので非公開で通すことにしました

もちろん、やる気があれば、非公開・削除ではなく加筆修正して生まれ変わらせても問題ありません

ただ、僕のブログですと、時事ネタの記事も多く、更には労力を考えると、そこまでの手間を掛けるのは難しい記事が多かったです

WordPress Front-end Editorを使えば非公開設定が簡単!

記事ページから記事編集画面へ移動することなく、簡単に記事編集をすることができるプラグインがあります

このプラグインをしようとすると、簡単便利・・・そうではあるのですが、どうやら、僕のケースだと他のプラグインと干渉したのか、使うことが出来ませんでした

一つ一つ非公開設定にしていくのはかなり面倒くさかったので、このプラグインを使えるのならかなり楽になるはずです

一度、試してみてはいかがでしょうか

参照

WordPress記事を直接編集できるプラグイン3選 | Webと人のアマモ場

分割している記事を一つにまとめる

記事を一度に書くのが大変だったり、情報がまだ手元に揃ってないが速報性を重視したいためだったりと・・・

様々な理由で、気付くと分割して書いてしまっている記事がそれなりに出来上がってしまっていました

総合してみると、濃い情報になるのかもしれませんが、そのページ(URL)の中身が必然として薄くなってしまっているため、Google側からは中身の薄い、低品質なコンテンツとして扱われてしまうことがあるようです

そのため、分割して書いてしまっている記事・内容の似通った記事があり、アクセス数が伸びていない物は、まとめてしまうことでGoogleの評価があがり、PV数が伸びる可能性あるそうです

参照

PV倍増するかも!ボリュームの薄い低品質ページをまとめてパンダアップデート対策|Web Shufu

Webサイトのアクセス数アップ、平均2〜3倍、最大で約26倍にした施策

インデックスの整理で検索流入が二倍になった話 | SEO 検索エンジン最適化

Redirectionプラグインを使って、新規投稿する方法がおすすめ!

2016-04-24_16h11_08

記事をまとめた際の投稿方法ですが、新規投稿するのが良いと思います

というのも、新規投稿ならブログの新着一覧の乗りますし、FeedlyなどのRSSに登録してくれている方にも通知がいきます

また私のケースだと新着記事はSNSと連携しているため、そちらにも通知が行きます

問題となるのは、Google側からの既に投稿したURLの評価(ドメインパワー)です

ですが、こちらも301リダイレクト(恒久的な移転通知)を行えば、評価をそのまま新しい記事へと引き継ぐことができるので、問題ないはずです

参照:Redirectionプラグイン(リダイレクトの管理) – WordPressプラグインの一覧

記事タイトルの見直しを行う

中には、文章量が多く、中身にも自身があるのに、読まれてない記事もあるかもしれません

そんな古い記事には、もしかしたら記事タイトルに問題があるのかもしれません

というか、僕のブログにありました

映画や漫画の感想文なのですが、記事タイトルにその作品しか書いてません

「感想」とか「レビュー」とか「読んでみた」とか、そんな文言すらありません

記事タイトルだけだと、何を書いているのかさっぱりです

そんな記事が読まれるはずありませんよね~

というか、この辺りは僕もまだまだ要勉強な領域ですよ

参照

ブログ記事タイトルのつけ方に悩むあなたへ贈る4つのアドバイス

Webライターなら知っておくべき「読まれる」記事タイトルの付け方7選 | 株式会社LIG

ブログタイトルの決め方でアクセスが上がる9つの方法

スラッグの再設定

僕のケースだと、他のブログサービスから移転してきたため、古い記事はパーマリンク設定がデフォルトになっています

記事内容に関係した、パーマリンクを設定してあげることで、一定のSEO効果があるはずです

ただ、その過去記事も結構な量があるので、なかなかの手間です

自身のある、いくつかの記事に絞って書いてみるのが良いかもしれません

また、コレに関してもリンクが変わるため、古いURLでアクセスが出来ない問題が発生します

そのため、本来なら後から変更するべきではないのですが、元々、アクセス数のない記事なのでしたら試してみる価値はあります

そのときのリンク切れの対策として、上述した、Redirectionプラグインを使う方法が有効です

WordPressスラッグの重要な役割と重複回避 – 自分メディアの育て方

メタキーワードを設定する

メタキーワードとは、その記事にとっての重要な単語のことです

これを設定することで、Google側にどのような単語で検索をかけられたときに上位表示して欲しいのかを示すことが出来ます

WordPressのSEO対策プラグインとして、有名なall in one seo packに搭載されている機能で、導入することで、設定することができます

昔からある、定番のSEO対策で多くのサイトで設定がされています

ただ、Googleは現在、このメタキーワードを参考にしないことを表明していて、将来的にはわかりませんが、現在、SEO対策上はあまり意味が無いことになっています

やらないよりはマシといったところですかね

一応、備忘録として書いておきます

参照

【SEO】実施率の高いmetaタグへの重要キーワード設定は効果があるのか? (1/2):MarkeZine(マーケジン)

All in One SEO Pack の設定方法と使い方

SEO上メタキーワードは記述するべき?

まとめ:過去記事の見直しもいいけど、基本は新しいよ記事を書くこと、バランスが大事です

ということで、過去記事のSEO対策・修正ポイントをまとめてみました

時には過去記事の見直しも大事でしょう、今まで私が積み重ねてきた大事な資産ですから

ですが、ブログの基本というのは、新しい有益な情報を生み出すことにあると思います

有限の労力(リソース)をどちらかに振り分けるのなら、新しい記事の方でしょう

何事もバランスが大事ですので、上手く調整して、良いブログ運営が出来るように頑張りましょう

ミニバードにサーバー移転したら瞬速になったので方法を書く@simplicityテーマでGTmetrixがAAで9秒台が0秒台になって笑うしかない

以前使っていた無料レンタルサーバーがもう限界だったようなので、低価格ながら評判の良いミニバードへと移転することにしました

Xdomainの無料レンタルサーバーのデータ転送量の目安を問い合わせした際の記録@意外と制限が厳しく、既にサーバー移転の時期だったようだ
Xdomainの無料レンタルサーバーを利用して、当ブログ(WordPress)を運用していたのだが、サーバー管理画面を見るとCPU使用量がそ...

移転した際に、せっかくの節目なのだからとキャッシュ系プラグインとか・・・いろいろと高速化する方法を試してみたのですが、最速で0秒割って0.8秒の数値を叩きだしてくれてビックリしました

2016-04-03_01h41_58

移転する前にGTmetrixで取ったデータがこちらで9.6秒です

2016-03-29_13h08_22

というのは、実はちょっと盛ってて、実は5~9秒台あたりをいったりきたりな感じでした

当然ですが、サーバー移転して、新しく記事を執筆したりなんかもせず、データを移して、裏側を工夫しただけです

測定結果のブログ画面は違います、テーマも変えずにsimplicityを使って、そこは最新のに更新して、設定を変えたからかな

同じ内容なはずなのに、もう、以前はどれだけ遅かったのかと・・・使っていたサーバーはxdomainの無料レンタルサーバー、これってWordPress専用を歌う、WPXクラウドと同じレンタルサーバーを使っているとエックスサーバー社長の小林尚希さんがブログで公言されています

WordPressしか利用することはできませんが、
非常に簡単にWordPressが利用開始できるようになっており、
また専用に高速カスタマイズしたサーバー仕様となっています。
これは別途当社が提供しており、このブログでも使用しているWpXと完全に同一仕様を取っています。

ドメイン名取得&無料レンタルサーバーのエックスドメイン – エックスサーバー社長ブログ

だから、決して、スペックの悪いサーバーじゃないはずなんです

高速化して当ブログを訪問してくれるユーザーのクオリティを上げるのには、サーバー頼みにするだけではなく、管理側の努力も大事、そしてここまで成果が出るんだなぁと思いました

何故、有名なロリポップではなく、ミニバードを選んだのか

理由としてはミニバードが安価ながらサーバースペックが良い、コストパフォーマンスの良いサーバーだという話だったからです

なんでも、定番の月1000円するエックスサーバーと、同じサーバーだという話もありまして、以前調べてみたこともあります

http://dtman.info/post-5694/

同価格帯のサービスとしては、ロリポップが有名ではありますが、いまいち評判が良くありません

とはいえ、ロリポップ側も頑張っていまして去年、大きくサーバー設備の増強をしたというアナウンスがあり、全プランにて提供しているとのことです

【全プラン】新サーバーへの事前移設受付のご案内 – 2015年11月09日 / 新着情報 / お知らせ – レンタルサーバーならロリポップ!

以前、一度、ロリポップのお試しサービスを利用したことがあり、その際はとてもレスポンスが悪く、印象が良くありませんでした

wpxサーバーとロリポップの応答速度を比較した結果…
測定サイト@サイト表示スピード測定 | サーバレスポンス時間測定 wpxサーバ@→エックスドメインの無料レンタルサーバー ロリポップ@チ...

ですが、そのようなアナウンスがありましたので、改めての、お試しプランに申し込んで試してみたのですけど・・・

やっぱり、遅い・・・遅いです

サーバーレスポンスを測定してみたのですが、0.624秒でした

以前は、2.991秒だったので、大幅に改善されたと言っては良いのですが、それでも、Googleのページ測定サイト、PageSpeed Insightsでは怒られるレスポンスで、一方、ミニバードは0.074秒と8倍以上の差があります

また、ミニバードは新しくて速い、新技術のPHP7を全てのサービスで提供しています

先に書いた無料レンタルサーバーでもです

一方、ロリポップにも高速化を謳う、PHPモジュール版というのがあるのですが、こちらはスタンダートプラン(500円)からの提供なんですよね・・・

1秒以下の世界なので、たかがそれぽっちの差ともいえますが、PageSpeed Insightsにおいて評価が悪いということは、検索順位にも影響してくる可能性がありますし、この僅かなさがユーザーに与える影響が大きいとのデータもありますし、SEOを考えるなら大事にしたいところです

実際に、使用した感想としてもミニバードは、応答が良好でとても良いレンタルサーバーだと感じています

とはいえ、高速化を重要視するのでなければ、ロリポップも良い選択肢だとは思います

まぁ、僕は遅いのが嫌で、ミニバードにしましたけどね

ミニバードとはまた、別の強みがありまして、データ転送量制限がライトプラン(250円)でも60GB/日と制限が大変ゆるくなりました

ミニバードですと150GB/月・・・同じ日単位に直すと5GBですので、とても大きな差です

30万PV以上のブロガーの方でも、現在使ってるプランは、ロリポップのライトプランだと書かれていたので、大きなアクセスにも耐えられるのでしょう

ミニバードでは、そこまでのアクセスには、CDNを使わないと、データ転送量の制限から難しいと思います

使っているテーマ

先にも書いてますがSimplicityを使用しています

私みたいな、大した知識のない人間にも、簡単に自分ごのみにカスタマイズできてすごく良いプラグインです

Simplicity | 内部SEO施策済みのシンプルな無料Wordpressテーマ

高速化のために使ったプラグイン

WP Fastest Cache

2016-04-06_15h16_20

WP Fastest Cache — WordPress Plugins

キャッシュ系プラグインです

このプラグインすごいですね、これだけでも、かなり高速化の効果がありました

定番はW3 Total Cacheですが、トラブルが多く、アンインストールすら一筋縄ではいかないほど、難しいそうでしたので、簡単にキャッシュを使えて安定しているという、このWP Fastest Cacheを使うことにしました

simplicityはキャッシュ系プラグインと相性が悪いと制作者様が言われてますが、その製作者のわいひら様がブログでおすすめしているプラグインです

初心者にも扱いやすいWordpressキャシュプラグイン「WP Fastest Cache」の使い方

私はこのプラグインをブラウザキャッシュ以外全て有効にしています

何故、ブラウザキャッシュを無効にするのかというと、後述する「コピペ一発でSimplicityを結構高速化する方法」でも、ブラウザキャッシュは有効になるのですが、そちらのみ有効にした方がGTmetrixのスコアが上昇したからです

また、このプラグインを、入れて有効化するとsimplicityの表示が崩れました

その対策を次のプラグインにてします

他、何故かロリポップサーバーのWordPressに入れるとデーターベースが壊れてアクセスできなくなったので、ロリポップサーバーの方は注意した方がよさそうです

なお、僕はフリー版を使ってます

ですので、スマートフォンでのアクセスはパソコンほど、早くなかったりするのですが、それでも十分高速です

有料版に移行すると、モバイルでもキャッシュが有効になるそうですが、これまたカエレバの製作者で有名なわかったブログさんところを見ると、有料版でも、モバイルキャッシュが上手く動かなかったそうですね

WordPressのお勧めキャッシュプラグインはこれだ!2016年版

Autoptimize

2016-04-06_15h28_52

Autoptimize — WordPress Plugins

html,javascript,cssを最適化してくれるプラグインとのことで、GTmetrixを見るとページサイズが減り、表示が早くなり、データ転送量が節約できているようです

なかなか効果がある模様

  • Optimize HTML Code?
  • Optimize JavaScript Code?
  • Optimize CSS Code?

を有効化

何故か、このプラグインを入れて有効にすると、WP Fastest Cacheが原因で崩れた、simplicityの表示が元に戻りました

Autoptimize単体でいれると、今度はsimplicityが崩れるとか聞いたのに何故だ・・・?

ただ、僕のお気に入りプラグイン「Table of Contents Plus」の表示が今度は崩れるようになってしまいました

2016-04-06_15h43_01

ただ、実用上、問題ないと判断して僕はこのまま使ってます

001 Prime Strategy Translate Accelerator

2016-04-06_15h44_27

001 Prime Strategy Translate Accelerator — WordPress Plugins

本来、英語圏であるWordPress

WordPressで使われている日本語はいちいち、英語から翻訳(動的ページ)からキャッシュして静的にして高速化するというプラグイン

正直、効果はわかんね、なくてもいいかも

管理画面は早くなるかもしれない

EWWW Image Optimizer

2016-04-06_15h48_22

EWWW Image Optimizer — WordPress Plugins

画像圧縮の定番プラグイン

以前使っていた、サーバーでは不具合が起きて使えなかったプラグインだ

正直、ログを見ると、あまり画像サイズを削減できていないようで、効果に疑問を感じるが、それでもやらないよりはマシなのは間違いない

なお、気付いたらブログの画像が一部、消失していることがあった

タイミング的にコイツの可能性がある、私の場合は、今までアップロードした画像をまとめて圧縮したので、何か不具合が起きたのかもしれない

とりあえず、しばらく様子見して、続くようなら、削除しようかなと考えている

コピペ一発でSimplicityを結構高速化する方法

プラグインではないのだけど、Simplicityのサイトに載る、製作者のわいひらさんが推奨する手法です

試してみたところ、たしかにGTmetrixのスコアは大きく上がりました

ただ、ページロード時間だけを見ると、私の環境では、それほど上昇しているような実感は持てませんでした

このコードを制作されたのは、わいひらさんではなく、別の方なのですが、その方のブログを見ると改訂版が掲載されています

私はこちらの方を使用しました

PHPバージョンを7.0.3に変更する

2016-03-29_14h07_59

これはネットオウル系(エックスサーバー含む)のサーバーをレンタルしている場合の話

サーバー管理画面から、より新しく高速なPHPである、PHP7に変更します

ただ、メジャーアップデートですので、何か不具合が起きるかもしれません

というか、起きました、私の環境で

プラグインが一つ、動作しなくなりましたが、古いバージョンでしたので、最新のものに更新してみたところ、PHP7に対応するアップデートがあったのか、問題なく動きました

PHP7に変更して何か問題が起きたら、プラグインを更新してみるのが良いのかもしれませんね

どうやら、多くの方はトラブルなくPHP7に移行できているようです

そして、効果の程はというと、まぁ・・・よくわかんないですね

まぁ、今後は少しづつ、こちらのほうが主流になっていくはずですし、謳い文句通りなら、高速化もしているはずなので、トラブルがなければ、導入するべきです

ここまでのプラグインを導入して約3秒ほど

2016-03-29_14h13_47

以上の処置をほどこして、だいたい3秒くらいのページロードを叩きだすようになりました

ページサイズも2.24MB→1.20MB

リクエスト数も105→61

と半分近くにまでスリムなっていますね

同じページのはずなのに、如何に無駄な部分が多かったのが、数値で出されて分かります

とどめはCDNサービス「CloudFlare」だ!

2016-04-06_16h23_59

CloudFlare – The web performance & security company

最後に、CDNサービス「CloudFlare」をぶっこみます

なお、独自ドメインじゃないと導入できない模様

ただ、このサービスはネット上を見るとチラホラと悪い噂も聞きますね

CloudFlareの解除と「Phonton」の導入方法 | ネットビジネスで稼ぐkyoheiのブログ

返って遅くなったとか、ユーザーとブログが入ってるサーバーの間を、CloudFlareを通して通信する関係上、CloudFlare側のサーバーが落ちて、ブログにアクセスできなくなっただとか

最近は、どうもより安定しているとのことでWordPressが提供するCDNサービス「Photon」が人気なようです

人気テーマのStinger3を開発したエンジさんも、以前、CloudFlareのトラブルが原因でPhotonに乗り換えたそうです

CloudFlareよサヨナラ! WordPressの表示速度が改善するプラグイン「Photon」

けどね、僕の環境だとPhotonの方が何故かトラブルんだよね

昔はPicasa(ウェブフォトサービス)から画像を引っ張ってきて、帯域を節約していたのですが、どうも、その画像たちがダメみたいなんですよ

また、ブログパーツのカエレバでも表示が大きく崩れる不具合を確認しています

どちらも、結構な量があるため僕に取ってはPhotonへの乗り換えは鬼門です

データ転送量節約と高速化のためにも、何かしらのCDNサービスは使用してみたかったので

以上の理由から、僕はCloudFlareを利用し始めました(ホントはPhoton使いたかったんだけどね)

今のところはトラブルなく使えていますが、一応、注意はしています

それに、サーバーダウンに関しては、WordPress側のサーバーがダウンしていても、CloudFlare側にあるキャッシュを表示する機能(alwaysonline機能というらしい)どっこいどっこいな気もするぞ

まぁ、話を戻して、CloudFlare登録→ログイン

2016-04-06_16h46_29

そうすると、Add Websitesとかいうページがでるので、自サイトのURLを入力→スキャン

しばらく、CloudFlareの説明が流れたりしますが、進めていくとネームサーバーの書き換えの案内をされるので、契約している会社の、ドメイン管理画面へ行き書き換え

つまり

ユーザ<>CloudFlare<>サーバー

の順の通信に書き換えするのよね

とりあえず、これで、CloudFlare自体はブログに適用されます

けど、まだやってほしいことがあります

2016-04-06_16h53_08

CloudFlareの管理画面から上のSpeedを開きましょう

2016-04-06_16h57_34

2016-04-06_16h57_52

そしてAutoMinifyのJavascript、CSS、HTMLをチェック

Rocketloader(ロケットローダー)のAutomatic(オートマチック)をクリック

以上で完了です

なお、CloudFlareを入れるとLazyloadが無効になっているような気がします

遅れて表示されることなく、ページを開くと一気に読み込まれている気がする

これで爆速の0秒台の世界へ…

以上のセッティングを終えたら、調子がいいと、GTmetrixでこの数値を叩きだしてくれます!

2016-04-03_01h41_58

測定結果を見ると

ページサイズも2.24MB→1.20MB→627KB

リクエスト数も105→61→29

どうやれば、ここまで減らせるのか謎の圧縮技術にてこんなにスリムになりました

目を疑いつつもう一度測定してみると・・・

2016-04-03_01h51_26

さ・・・さらにページサイズとリクエストが減った!?

ページサイズも2.24MB→1.20MB→627KB→348KB

リクエスト数も105→61→29→9

ホントにどうやったら、容量を減らすことが出来るんだよ・・・

・・・けど、ページロードが伸びたな

CloudFlare導入によるページサイズのとリクエスト数の現象は謎のロケットローダーなる機能による影響が大きいです

説明を読むとJavascriptをどうにかしているようなんですが・・・・ホントにどうしてるんだろうかなぁ・・・

このくらい速いと、押したと思ったら開いているポルナレフの気持ちが味わえます

CloudFlareは悪い評判もありますが、このように高速化に大きな効果がありますし、データ転送量削減の効果も大きくしっかりとしてくれています

上にも書いたように、注意は必要かと思いますが、今のところトラブルはないですし、印象は良いです

当訳で、ブログ高速化の記事はこれにて終わりです

みなさんも、一度、ブログをスリムにして、高速化を試してみてはいかがでしょうか

ブログというのは自分の城、少しこだわって手を入れてみてはどうでしょうか、実益にも繋がるし

ただ、バックアップだけはしっかり取ってからやるんだぞ!

Xdomainの無料レンタルサーバーのデータ転送量の目安を問い合わせした際の記録@意外と制限が厳しく、既にサーバー移転の時期だったようだ

Xdomainの無料レンタルサーバーを利用して、当ブログ(WordPress)を運用していたのだが、サーバー管理画面を見るとCPU使用量がそろそろ危なかった

危ないというか、真っ赤っ赤だった2016-03-29_12h10_59

以前から、そのことには気付いていて対策は試みていたのだが功を奏せずに、この状態である・・・

xdomainの無料のレンタルサーバーのCPU使用量超過の謎を探れ!
久しぶりにレンタルサーバーのリソースを確認したら、CPU使用料超過の警告が出ている日があったyoku 具体的な数値までは覚えていないものの...

Xdomainの無料レンタルサーバーは負荷の上限については一度考えてみたことがある

エックスドメインの無料サーバーはどのくらいのPVに耐えられるか計算してみる
当ブログは今のところ、エックスドメインの無料サーバーを借りて運用している ちょっとずつではあるが、アクセス数が増えてきているし少し、どのく...

けどまぁ、あくまで推測だったので、改めてちゃんと、カスタマーサポートに問い合わせてみた結果がこちらだ

カスタマーサポートの返信のコピペ

> 【件名】
> 無料サーバーのCPU使用量・転送量、またアクセス制限について
>
> 【URL】
> http://dtman.info/
>
> 【内容】
> 現在、無料レンタルサーバーを使用しているのですが、ときおりCPU使用量超過が起きてしまい気になっています
> このまま、CPU使用量超過が続けば、何かしらの処置がされるようなことはあるのでしょうか?
> 他、同時に転送量も増えてきていることが気になっているのですが、無料レンタルサーバーに転送量上限は決められているのでしょうか?
> もし、上位の有料のレンタルサーバーに移転した時はCPU使用量の制限もゆるくなると考えて良いのでしょうか?
> よろしくお願いします

お問い合わせいただきありがとうございます。
以下、インライン形式にて回答いたします。
> このまま、CPU使用量超過が続けば、何かしらの処置がされるようなことはあるのでしょうか?
慢性的に負荷が掛かっている場合は、
無料サーバーのご利用をお控えいただき、
有料サーバーのご利用をご検討いただく場合がございます。
> 他、同時に転送量も増えてきていることが気になっているのですが、無料レンタルサーバーに転送量上限は決められているのでしょうか?
Xdomainの無料サーバーはいずれも転送量について
特に明確に上限を定めておりません。
あくまでも恒常的な転送量で判断するのであれば
およそ「10GB~20GB/月間」程度を目安にしていただければと存じます。
> もし、上位の有料のレンタルサーバーに移転した時はCPU使用量の制限もゆるくなると考えて良いのでしょうか?
Xserverなどの有料レンタルサーバーをご利用いただくことで、
現在の無料サーバーよりはCPU負荷に耐えられるようになっております。
また、無料サーバーの場合、一時的なアクセス集中などにより
サーバー全体の帯域を占有するようなことがございますと
予告なくサービスのご利用を停止する場合がございます。
そのため、商用のサイトやその他、アクセスの増加などによって
サーバーが停止することによって大きな問題が発生するようでしたら
Xserverやsixcoreなどのサービスのご利用をご検討ください。
※ 例外はございますが、Xserverやsixcoreではアクセスの集中があった場合なども
極力、サービスの利用は停止しない形での対応をいたしております。

データ転送量の目安について

10GB~20GB/月間が目安とのことで・・・

とのことで、低価格帯のレンタルサーバーであるやロリポップミニバードと比較すると、やはりあくまでも無料でのサービスなので、とてもデータ転送量の制限が厳しい返事になった

ミニバードだと、150GB/月間なので15倍ほどの差があるね

CPU使用量の上限について

有料サービスに移行すると、やはりこちらの制限値もゆるくなるそうです

今回、サーバー移転を考えだした理由だったので、当然なのかもしれないが、どこにも書かれていないので、ちゃんと聞けて安心した

・・・サーバー移転したのに、CPU使用量超過のため、対策でプラグイン削除したりとか嫌だからね・・・

新事実!無料サーバーは予告なく停止させられる危険性がある!

制限ではなく停止・・・?垢バンのことでしょうか・・・

有料レンタルサーバーでも、アクセス増加などにより、サーバーに大きな負担を掛けるようなことがあれば、リソース制限をくらうとは聞いたことがありますが

制限ではなく、停止と書かれていますね・・・

もしかしたら、あくまでも、無料のサービスなので、制裁の処置が重いのかもしれません

まとめ:Xdomainの無料レンタルサーバーはあくまでも初心者用

総合的に言うと、Xdomainの無料レンタルサーバーは、当然なのだが、同社の有料サービスである、WPXクラウドミニバードと比べるとかなり厳しかったようだ

あくまでも、WordPressのお試しサービスという立ち位置で、ブログを初めてある程度、軌道に乗るような状況になったら、有料サービスに移転しろということなんだろうな

私は常にCPU使用量が超過する状況に悩まされていたが、データ転送量の目安が10GB~20GB/月間とのことだから、当然、CPU使用量の負荷も、それ相応のアクセス数を考えて制限されていたのだろうし、当然だったのかもしれない

予告のない停止があるというのも怖いね

ただ、私は移転前は常にCPU使用量超過しっぱなしだったし、データ転送量上限の20GBすらも越していたはずなので、処置に関してはだいぶ太っ腹でゆるいような気はする

こんな良いサーバーを無料で使わせてくれていたのだから、とても良いサービスだ

・・・とはいえ、やはり突然の停止とやらは怖いし、有料のレンタルサーバーである、親会社が運営するミニバードへと移転することにした

って、上位サービスのWPXクラウドじゃねーかよ!と思う人も居るだろうけど理由は、以前調べた時なかなか良さそうだったからです

我がブログも、そろそろ乗り換え先を検討しているのですがネットを徘徊していると、このような事を書いてる人をちらほら見かけました 曰く「ミニバ...

というか、既に移転して、ミニバードで運営していますが、なかなか良いサーバーですよ

そこら辺のことも、また別途記事にしていくかもしれません

Windows Live Writerで同時に複数ウィンドウを開いて記事を同時作成・更新する方法メモ

hand-1106927_640

僕のブログの執筆スタイルは記事を一度に書き溜めておき、予約投稿で日付をずらしてやる方法をよくしているのですが、続けてブログを書くときに、前と後の記事が関係していることがあり、見直したい時があります

また、一つの記事に画像を大量に使い、記事が長くなってしまうと、重くなってしまうため(Windows Live Writer自体もブログから記事を読み込むのも・・・)分割して書くこともあります

アップロード待ちの時間が長くて、イライラするときもあるかな、ブログ更新にテンポって大事だよね

そんなときに、Windows Live Writerが複数開ければいいのに!と思っていたのでメモ

方法1:Windows Live Writerをダブルクリックして開く

・・・え!?知らなかったの!?とか言われそうですが、はい知りませんでした

試したことありませんでした・・・はい

これだけで、複数ウィンドウ開いて、並列作業が出来たとは・・・うむむ

方法2:Windows Live Writerの設定を変えて新しい記事毎にウィンドウを開くようにする

複数ウィンドウを多用しがちで、マシンスペックに余裕がある人は、こっちの設定を使用したほうが、便利で実用的かも

まずオプションを開きます2016-03-09_20h26_52

そして、基本設定→記事ウィンドウから

記事ごとに新しいウィンドウを開く・・・にチェックします

下の、現在の記事の変更内容を保存されていない場合にのみ、新しいウィンドウを開く・・・でもいいかもしれませんね、お好みで

まとめ:Windows Live Writerは実は最初から多重起動出来ただけ・・・という記事

いやぁ・・・知らないというのは・・・実践というのは・・・思い込みというのは罪ですね・・・

こんな簡単に出来たとは・・・

これで、便利なWindows Live Writerをますます便利に使うことが出来そうです