2017年11月24日(金) 06:59 JST

twitterfeedが重すぎるのでdlvr.itを使ってみる

印刷用ページ

twitterfeed、どうも最近ブログの更新を拾ってくれない。dashboard見ると拾っていないこともあるし、あるいは拾っているけど実際に反映されない。twitterは反映されるんだけどfacebookはタイムラインに反映されていない。一人で5つのfeed登録してそれぞれtwitter, facebook, linkedinに反映させていたツケだろうか?

ということでfriendfeed使ってみたけど、fbでは個人のウォールに反映するだけでfbページには対応していないみたいなので諦めた。そこでdlvr.it。設定してみた感じはサクサクしてる。でもfbページ2つ、twitter1つ登録したら次の登録は出来なかった。これ以上は有料になるんだ

とりあえずここまでで様子を見ていることにした。考えてみたらtweetfeed重いのは1アカウントで登録したサービス多過ぎたのかもしれない。

  • コメント (0件)
  • トラックバック (0件)

adnxs.comはウィルスです

印刷用ページ

ひとつ前のエントリーでadnxs.comのことを報告した。自分の場合facebookでのみ反応するので勝手にfbアプリを埋め込まれたのかと思っていたが、調べてみたらウィルスだった。Yahoo知恵袋では「マルウェアみたいだ」とのことです。この知恵袋記事に出ているanvisoftのforumへのリンクをクリックしたらウィルスバスターが「このWebサイトは、有害なプログラムを転送するか、オンライン詐欺に関係していることが確認されています。」と知らせてきました。オイオイ・・・。

AviraでPCスキャンしたらウィルスとして認識されました。即駆除しました。しかし!

こんな英語記事もありました。非常にタチの悪いウィルスだと書いてあります。windowsのレジストリ情報もいじられてらしいです。レジストリ書き換えられていないか確認します。トホホ・・・。

検知率が高いと言われているAviraでも水際でブロック出来なかったのがちょっとショックです…。

 

adnxs.com facebookスパム?

印刷用ページ

Chromeがやたら重くなったので、この数カ月Firefoxを使っているが、この1ヶ月ほどfacebookのいいね!や通知をclickすると「この53歳の女性が71歳に見える」「Googleでこんなに儲かった」とか怪しい広告がポップウィンドウで開く。ポップアップ禁止に設定してるのになぜだろう?

facebookでスパムアプリを知らない間にインストールした(された)かも、と思って特に使っていないアプリはすべて削除した。また、自宅PCのFirefoxで出ている現象で、職場のFirefoxではこの現象は出現しない。自宅PCで使っているのはAviraでウィルス検出率の高さはお墨付きなのでウィルスでもなさそうだ。

原因を探るべく、今日はポップアップ・ウィンドウのURLを調べてみた。adnxs.comというドメインだ。ここのhomeをブラウザで開いてみるとログイン画面だ。やっぱり怪しい感じ。

  • コメント (0件)
  • トラックバック (0件)

絵文字2テスト

印刷用ページ

[emoji2:E000][emoji2:E008]

  • コメント (0件)
  • トラックバック (0件)

Google、動的URLの扱いに新見解「動的URLのままで問題なし」

印刷用ページ
Googleに対してはSEO的な意味で動的URLを気にしなくてよくなるようだ。
Google Central blogでのコメントを元に渡辺隆弘氏が解説している。
記事はコチラ

渡辺さんも言ってるけどGoogleは言い出したことがcrawlerやindexの挙動に反映されるのには1年くらいかかるから当面は今までと同じ対応がいいんだと思う。以下一部引用。

-------------------
たとえば、ソーシャルブックマークサイトで「SEO」というタグの一覧を表示する時、次のパラメータを持ったURLがあったとします。

1. ?keyword=SEO
(SEOタグのページ一覧、すべて)
2. ?keyword=SEO&userid=ALL&list=all
(SEOタグのページ一覧、すべて)
3. ?keyword=SEO&userid=userA&list=all
(ユーザAのSEOタグのページ一覧)
4. ?keyword=SEO&userid=userB&list=all
(ユーザBのSEOタグのページ一覧)
5. ?keyword=SEO&userid=userC&list=all
(ユーザCのSEOタグのページ一覧、すべて)
6. ?keyword=SEO&userid=userC&list=date
(ユーザCのSEOタグのページ一覧、日別)
7. ?keyword=SEO&userid=userD&list=all
(ユーザDのSEOタグのページ一覧、すべて)
8. ?keyword=SEO&userid=userD&list=year
(ユーザDのSEOタグのページ一覧、年別)
9. ?keyword=SEO&userid=userD&list=weekly
(ユーザDのSEOタグのページ一覧、週別)
10. ?keyword=SEO&list=weekly&userid=userD
(ユーザDのSEOタグのページ一覧、週別)

keyword タグ
user[ ] ユーザID
list 表示形式
date 日
weekly 週
year 年

この条件では、付与されているパラメータは異なっても 1 と 2 が同一内容、5,6,7も同じ内容、さらに8,9,10も同じ内容です。 1 は 2~10の内容を兼ねているに違いありません。従って、パラメータを分析して関係性がわかれば、?keyword=SEO だけインデックスしてその他は重複・類似コンテンツとして除外すれば効率的です。

これらを全て静的URLにされてしまうと、適切な関係性がわからず全部インデックス対象になってしまう恐れがあります。たとえば、9と10のように、パラメータの順序が違うだけでも、静的URLに変換されるとURL構造も変わるので、クローラが両方ともムダにインデックスしてしまうわけです。これはGoogleにとって意味ないですし、検索ユーザーにとっても価値がない、そんな価値がないページを見せてしまうサイト運営者にとってもメリットがない、わけです。Googleとしては「下手に静的URL変換されるくらいなら、動的URLを自分達で分析して、クロールすべきURLを見つける」方がいいでしょう。
-------------------------------------------

  • コメント (0件)
  • トラックバック (0件)

Google Mobile Sitemap

印刷用ページ
GoogleがMobile用Sitemapの新しいタグを発表しています。発表内容はコチラ

今まではMobile用Sitemapは書式としてはPC用と変わらないものをuploadして、GoogleWebmasterToolからサイトの記述言語をXHTMLやcHTMLとして申告するだけだったのですが、新しくmobile専用のタグが発表されたことにより、おそらく段階的にGoogleはこれを手がかりにmobileサイトを判別するようになるんでしょう。

詳細は下記の通り。


<URLSET> に
xmlns:mobile="http://www.google.com/schemas/sitemap-mobile/1.0"

<url>に
<mobile:mobile/> と言う新しいTAGが記述してあります。

例: サンプルSITEMAP
http://www.google.co.jp/xhtmlsitemap.xml
http://www.google.co.jp/wmlsitemap.xml
http://www.google.co.jp/chtmlsitemap.xml


<?xml version="1.0" encoding="UTF-8" ?>
<urlset xmlns="http://www.google.com/schemas/sitemap/0.84"
xmlns:mobile="http://www.google.com/schemas/sitemap-mobile/1.0">
<url>
<loc>http://mobile.example.com/article100.html</loc>
<mobile:mobile/>
</url>
</urlset>


Shif-JISで記述しないとmobileサイトと認識されないかと思っていましたが、これからはUTF-8でもオッケーなのかな??



  • コメント (0件)
  • トラックバック (0件)

CMSで携帯サイト

印刷用ページ
SEOに配慮された携帯サイトをCMSで合理的に作りたい。
調べてみると意外と難しい。geeklogは3キャリア対応のテーマ「mobile-3G」があるが気に入らない点。
①携帯端末で見るとヘッダーメニューが最初に出てきて一つずつ選択していかないと記事に行き着かない
②ソースを見るとH1, H2構造はしっかりしているけどchar-setが宣言していない
③ヘッダメニューはtableに入っているのが気になったが、まぁいいか。
④デザインとして「やっつけで作りました」印象を否めない。

「ケータイキットfor Movable Type」は有名みたいだけど高い!企業用途を狙っているんだろうな。無料系のMT用のmt4iとか、いろんなtool、それからASP系も当たってみたけどどれも基本は「PC用blogサイトを携帯でも見れるようにします」が基本姿勢で「携帯サイトをCMSで作ります」というneedsには合わない。

が、[link:ja.wordpress WordPress日本]用に[link:ktaistyle]ってのがあるじゃないですか。デモサイトで見る見栄えも携帯サイトとしてしっかり出来ている感じ。気に入った!あ、でも「リンクは全て中継ページに一度・・・」え?デモサイトでテスト。「PCサイトにジャンプします」なに~~!!!リンク先が携帯サイトだったらどうするんだよおおおお!これもやはり「PC用blogを携帯で見れるようにするtool」だからなんだろうな。その意味ではこの中継ページって凄く親切だよ。パケ代のこともあるからね。なんか直せそうなんだけど自分できると思えない・・。で検索検索。あ!4月のバージョンで改善がっ!!「aリンクにclass=ktaiを設定すると中継ページ不要」ばんざーい!! これ使ってみよ!!yurikoさん、ありがとう!!


携帯SEO tips

印刷用ページ
この記事、すごく役に立つのでコピーさせていただきます。
http://buzz.dendrocacalia.com/2007/01/3_seo.html

最初に注意しておきたいのは、公式サイト内での順位上げ手法と検索エンジン対策はまったく異なるということです。
公式サイトにおいては、キャリアによって程度の差はあれど「直近3ヶ月のユニークユーザ数」というのが最重要ポイントになってきます。
そのため、クリック毎にポイントが加算されるタイプの賞金サイトやメルマガ、多少下品な手法も用いるアフィリエイトなどで、とにかく一度サイトを「踏んでもらう」のがメインの手法になってきます。
登録してもらって毎月300円の課金を得ることが主目的になるサイトが多く、ほとんどのユーザは登録したことも忘れて毎月払い続けるため、リピート率などもそれほど気にしません。
こういった「今月は○×万円で△クリックくらい買う」という発想を続けてきたサイトにとっては、地道なクローラー対策はなかなか馴染み難いものでしょう。

基本的に、携帯サイトにおけるSEOもPCにおける手法は大筋で活用できます。
そして、特にAuのGooglebotでは「人間にとって見やすいサイトが、検索エンジンにとっても好ましいサイト」というポリシーは引き継がれているようです。
とはいえ、前回も挙げたようにキャリアが検索広告ビジネスを捨てたわけではありませんし、小さな携帯端末特有の仕様や癖は存在します。
以下に、それらのTipsを思いつく/メモとして書き留めておいたままに列挙しておきます。

XHTMLで論理構造的に記述する
従来のサイトですと、CHTMLやHDML、WAPなどで記述して(あるいはそれらを動的に切り替えて)いるサイトが多いかと思います。
しかし最近は多くの端末がXHTML+CSSに対応するようになっており、2006年6月の米国データではありますが、実に81%のユーザが XHTML対応の端末を使っているという統計データもあります。携帯先進国である日本ではこの数値は更に高いでしょうし、インターネットアクセスをするようなアクティブなユーザを対象にすれば、この数値は更に上がると思われます。
携帯クローラーもXHTMLを好むらしく、昨年12月に行われたSearch Engine Strategies ConferenceでもYahoo!のPaul Yiu氏やGoogleのSumit Agarwal氏をはじめ、ほとんどのパネラーが口をそろえてXHTMLによる記述を薦めていました。
XHTMLはHTMLなどと同じSGML系の構造ですが、文法が遥かに厳密なためコーディングには気を使うかもしれません。しかし、それだけにコンピュータには理解しやすくレンダリングも高速なため、是非ともリニューアルなどの際には乗り換えたいところです。

論理構造とCSSの利用

テーブルに頼ったり、列挙するのに「・」と改行で行ったりするのは止めましょう。
見栄えを満たすためだけのHTMLから、論理構造に外部ファイルのCSSでデザインを当てるスタイルへ変えることは大きなメリットがあります。
論理化することで、クローラーにコンテンツの部分部分の意味を伝えやすくなります。
また、デザインを外部ファイルにすることでページサイズを軽量化することができます。
CSSはできるだけサイト全体で共通のものが使えるようにしておけばメンテナンス性も上がりますし、端末にキャッシュされれば毎回読み込む必要がなくなり快適なページ遷移を提供できます。
更に、http user-agentやhttp accept、UAProfなどから端末を判別して画面サイズにあわせたCSSを送るなどすれば、テンプレート全体を複数用意したりすることなく端末に最適なデザインを提供することも可能です。

短いコンテンツ、簡潔なタイトル
ユーザに負荷をかけないため、PCよりもかなり短いコンテンツを書くことを心がけましょう。
携帯端末のSERPに出るタイトルやスニペットも当然かなり短いため、見せたいキーワードを極力前にもってきて短く簡潔な言葉で伝わるようにする必要があります。
また、携帯検索エンジンに入力される単語も短いものになる傾向があるため、例えば「ポピュラーミュージック」よりも「ポップス」などのように、短く口語的な言葉に置き換えるのも有効です。

W3Cの携帯標準規格に準拠
W3Cで定めたガイドラインにしたがって記述することは非常に効果的です。
人の目に触れる以前にクローラーに理解されなくては意味がありませんし、整形されて書かれたコードは複数の端末でも期待通りにレンダリングされる可能性が高くなります。
是非とも熟読して、きちんとしたコードを書くよう留意しましょう。
Mobile Web Best Practices 1.0

検索エンジンに存在を知らせる
いくら丁寧にコードを書いても、サイトの存在をクローラーに知ってもらわなければ意味がありません。
GoogleならばWebmaster ToolsのMobile sitemap.xml、Yahoo!であればこのページなどから検索エンジンに通知しましょう。
また、もし既にPC用のサイトを持っているならば、そこからリンクを貼るのも有益です。
プレスリリースなどからリンクを貼るなど、機会を見つけて積極的にリンクを出しましょう。
サイトのトップページにサイトマップへのリンクを付けるなど、サイトが隈なくクロールされるようにすることも大切です。

携帯サイトにおけるSEOはまだまだ黎明期であり、未検証の情報やオカルトに近い手法が流れているのもしばしば眼にします。
ここには、極力オフィシャルに近いところで得た情報や実体験に基づくもの、PCで同様の手法が確立されており害にはならないであろうものを選んでいるつもりですが、「恒久的な必勝法」のようなものではないので、導入の判断は自己責任でお願いします。
ただ、現時点でクローラーがペナルティを課さないからといって、クローキング紛いの手法や隠しリンク、altによるキーワード羅列などを薦めてくるコンサルタントもあります。そういったblack-hatなやり方は、ある日突然八分にされるかもしれません(自分は必ずそうなると思っています)。特に携帯を専門でやってきて、PCでのSEOに疎いサイト運営者は、充分に危険性を確認して必ずしも鵜呑みにしないよう注意しましょう。

ここでは言い換えると完全にwhite-hatな、SEOというよりもサイト作成の心得に近いものの紹介になります。(裏技的なものを期待されている方が居れば申し訳ありませんでしたが、本質的にユーザを幸せにしない手法等を紹介していくつもりは他の記事も含めて全くありません)

文字エンコーディングをきちんと指定する
文字コードの自動判定は曖昧なもので、特に携帯サイトのように1ページあたりの情報量が少なくなると判別が難しいケースも出てきます。
せっかくクローラーを呼び込めても全て文字化けでは意味がありませんので、エンコードは必ず指定しましょう。
DoCoMoの絵文字対応もありShift_JISを使っているサイトも多いのではないかと思います。まともなWeb開発者にとっては気持ち悪いかもしれませんが、現時点ではクローラーもSJISを正式対応にしているところが殆どですので、そのまま見せましょう。
ただしその絵文字ですが、バイナリで入力している場合はauなどで文字化けすることがあります。可能な限り16進のエンティティコードで入力するようにすべきです。(ページサイズの問題もありますが、ちゃんと表示されることが優先でしょう)

携帯用のサブドメインを作り、URLはシンプルに短く

構造的にPC向けのサイトと携帯向けのサイトが混在してしまうと、robots.txtなどでクローラーに棲み分けを知らせるのも大変になってきます。
ここは可能であれば、携帯用のサブドメインを作って独立したサイトとしてシンプルに立ち上げましょう。
端末によっては、少し長いURL(100bytes程度)でエラーを返してしまうものもありますし、QRコードも文字数(=情報量)が多くなると読み取りにくくなったりサイズを大きくする必要が出てきたりします。
サブドメイン名から含めてURLは極力短く、シンプルなものになるよう心がけましょう。

ソース上の順番に気をつける
たとえばページがグローバルナビゲーションメニューとメインコンテンツから成る場合、デザイン上はナビゲーションを前(左上に近い方)に配置したかったとしても、ソースコード上できる限りメインコンテンツを前に書くようにしましょう。
クローラーが上部のコンテンツを重要視するという噂もありますが、何よりもSERPのスニペットにコンテンツの方が表示される可能性を高める意味で重要です。
コードブロック上は重要なコンテンツを前に置き、デザイン上の要件はCSSで賄う形にすることをお勧めします。

全てのページにトップから3クリック以内でアクセス可能にする
単純にユーザビリティを考えても、DLに時間もコストもかかる携帯サイトにおいてはサイト構造を浅く作ることにPC以上に気を使うべきです。
階層の浅さはクロールを容易にする上でも重要です。
ページ数が増えて分類上難しかったとしても、サイトマップを用いるなどして最低限3クリックで辿り着けるルートを用意しましょう。

携帯用SBSやRSSを利用する
PC市場において既に円熟期から衰退期に入りかかっている感もあるSBSやRSSですが、コンテンツ内容をつまみ食い的に得る特にRSS Readerの仕組みは、実は携帯市場にこそ最も適しているのではないかと思えます。
SBSやRSS Readerに登録してもらうことは、被リンクを増やすというSEO的観点でも単純にユーザの眼に触れる機会を増やすというマーケティングの観点でも有益です。
RSS Readerにより定期的な訪問者が増えることは、公式サイトの順位上げにも役立つでしょう。
登録用のアイコンなどを配置し、積極的に登録してもらうことを促しましょう。

繰り返しになりますが、現時点での携帯検索市場は「よちよち歩き」の段階です。
逆に言えば、今であれば少しの工夫ですぐに上位表示されるサイトを作ることが可能でしょう。
しかし、SERPの上位は公式コンテンツが占めていることを忘れてはいけません。
第2回で書いたように、キャリアがこのビジネスを完全に手放すわけではない以上「公式サイトの優遇」は続くでしょうし、キャリアが独自に始めるサービスにおいてはそれが最優先にされるであろうことは確かです。
順番として

1. サイト自身のサービス
2. PPC系の広告
3. 公式サイト内での検索結果
4. 勝手サイトの検索結果

となるようであれば、いくら勝手サイトで1位になっても実質的には10位以下ということにもなってしまいます。(携帯でのSERPにおいて、ページをどのくらい下までユーザがスクロールダウンするかは検証が必要ですが、そう下までは見ないでしょう)
結局のところ現時点では、SEOよりも公式サイトとして認められること、そしてSEMに重きを置く方が効果は高いように思います。(ここまで書いてきて、こんな結論ですみません)
しかし、今後検索市場が円熟化してきた時に立ち遅れないため、今のうちからSEOを意識したサイトを構築することが無駄だとは思いません。
しつこいようですが、「検索エンジンにとって良いサイトはエンドユーザにとっても良いサイトである」と信じて、良質の携帯ページを作るためのTipsとして扱ってもらえれば幸いです。

  • コメント (0件)
  • トラックバック (0件)