Making AJAX Applications Crawlable - Google Code
If you're running an AJAX application with content that you'd like to appear in search results, we have a new process that, when implemented, can help Google (and potentially other search engines) crawl and index your content. Historically, AJAX applications have been difficult for search engines to process because AJAX content is produced dynamically by the browser and thus not visible to crawler
情報セキュリティ技術動向調査（2009 年下期）：IPA 独立行政法人 情報処理推進機構
Web において使われる URI（URL）には様々な情報が埋め込まれるが、その埋め込みの際にはエスケープ（パーセントエンコード）が行われる。埋め込まれた情報は取り出されるときにアンエスケープ（パーセントデコード）される。 たとえば、四則演算を行う電卓の Web アプリケーションを考える。この電卓は HTML の form でユーザに式の入力を求め、式が入力されてサーバに送られたらその結果を表示する。ここで、式は "http://calc.example.org?q=式" というような URI にブラウザがアクセスすることによって、サーバに送られるものとする。この形式は HTML の form で用いられる application/x-www-form-urlencoded という形式であり、HTML の規格で定義される。この場合、"1+1" という式を URI に埋め込むには "+" とい
URI::Template::Restrict 0.04 - 日向夏特殊応援部隊
コラボレータに加えて貰って、0.04 をさっき id:ikasam_a に ShipIt して頂きました。そのうち cpan コマンド等でインストール出来ると思います。id:ikasam_a++ URI::Template::Restrict なんですが、extract() の処理が process() と同様の厳格なルールになっていて、実際に使う際にちょっと困ってました。 例えば、OpenSocial の RESTful API でありがちそうな以下のような URI Template に対して実際の URI をぶつける例、 #!/usr/bin/perl use strict; use warnings; use Data::Dump qw(dump); use URI::Template::Restrict; my $t = URI::Template::Restrict->new(
「重複コンテンツ・重複URL」のおさらい
Google、Yahoo、Microsoftの大手検索エンジンが、重複コンテンツ問題解消のために「rel=”canonical”属性」を共通で導入することになりました。 『rel=”canonical”の正規化で、重複コンテンツを撃退』 いいタイミングなので、「重複コンテンツ」についておさらいしておきましょう。 「重複コンテンツ（英語では”duplicate content“）」とは、ページの内容（＝コンテンツ）がまったく同じにもかかわらず、URLが異なるWebページのことです。 僕たち人間のユーザーにとっては、普通は問題になりません。 しかしコンテンツが同じでもURLが違ければ、サーチエンジンは、独立した別々のページとして認識します。 サーチエンジンは、ダブっているとみなしたページを、SERPに表示しないようにフィルタリングし（ペナルティではない！）、代表と判断したページだけを表示します
Specify your canonical
accessibility 10 advanced 195 AMP 13 Android 2 API 7 apps 7 autocomplete 2 beginner 173 CAPTCHA 1 Chrome 2 cms 1 crawling and indexing 158 encryption 3 events 51 feedback and communication 83 forums 5 general tips 90 geotargeting 1 Google Assistant 3 Google I/O 3 Google Images 3 Google News 2 hacked sites 12 hangout 2 hreflang 3 https 5 images 12 intermediate 205 interstitials 1 javascript 8 job s
index.html「あり・なし」のURL正規化 – 301リダイレクト応用編
“www.example.com/“と”www.example.com/index.html“、人間のユーザーにとっては同じページでも、サーチエンジンにとっては、まったく別のページです。 （余談ですが、example.com,example.net,example.orgは、例を出すときに使用するために予約されたドメインです。例えのドメインを示すときには、これらを使いましょう） 異なるページ（＝異なるURL）ということは、被リンクもそれぞれ別のページへ向けられたものとして処理され、合算されるわけではありません。 たとえ、実際にはまったく同一のページへ張られていてもです。 SEO塾の石崎さんによれば、Yahoo!ではindex.htmlがある場合と、ない場合（スラッシュで終わる場合）では、インデックスに問題が生じるケースがあるとのことです。 Yahoo!検索でindex.html表示、スラッ
Big Daddy症候群 - [追記] URL正規化あるいはwww有り無し問題 :Bigdaddy症候群 ::グーグル(Google)の書
短期集中エントリー：GoogleのBig Daddy問題を研究する 今回は追記。 Bigdaddyの課題の一つがクリアされている件について。 URL正規化(url canonicalization)再録 Big Daddy症候群 - 新型データセンター導入の経緯と背景には、Googleのデータセンター入れ替えの理由の一つとして、次のように記述している。 url canonicalization(カノニカライゼイション) http://www.hyperposition.com/ http://www.hyperposition.com http://hyperposition.com/ http://hyperposition.com http://www.hyperposition.com/index.html http://hyperposition.com/index.ht
「SEO初心者の犯しがちな間違い」その1とその2：使いにくいドメイン名とURLの正規化問題 | Moz - SEOとインバウンドマーケティングの実践情報
ランドが最近、「SEOの意外な裏技」と題した新しいシリーズ（その1、その2、その3、その4、その5）を開始したわ。この連載は、「なんでこんなこと思いつかなかったんだろう？」っていうSEOのヒントやコツ、アドバイスを取り上げているんだけど、実は私も今日、たまたま意外な発見をしたのよ。でもそれは、「なんでこんなこと思いつかなかったんだろう？」の類じゃなくて、むしろ「なぜこんなことをやらかしちゃってるわけ?!」に近いわね。 というわけで、私は正式に「SEO初心者の犯しがちな間違い」シリーズをスタートさせるわ。もちろん読者の多くにとっては、あきれるくらい初歩的なミスがたくさん登場してくるはず。でも、SEOのプロである私にとって意外だったのは、何らかのごく基本的なSEOのミスを犯しているサイトがたくさんあるってことが、いかに忘れられがちかっていうこと。 実は今日、大きな間違いをしでかしてるサイトを見
SEO advice: url canonicalization
(I got my power back!) Before I start collecting feedback on the Bigdaddy data center, I want to talk a little bit about canonicalization, www vs. non-www, redirects, duplicate urls, 302 “hijacking,” etc. so that we’re all on the same page. Q: What is a canonical url? Do you have to use such a weird word, anyway? A: Sorry that it’s a strange word; that’s what we call it around Google. Canonicaliza
What's allowed in a URI?
Java 1.4 introduced the java.net.URI which provides RFC 2936-compliant URI handling. I thought I should try to fix Jing and Trang to use this. So I've been looking through all the relevant specs to figure out to what extent I can leave things to java.net.URI. It's convenient to begin with XLink. Section 5.4 requires the value of the href attribute to be a URI reference after certain characters th
はてなブログ | 無料ブログを作成しよう
フルリノベ後4年間住んでみて思った、よかったところと後悔したところ フルリノベの中古マンションに住んでみて、2024年の5月でちょうど4年経ちました。 良かった点や、もっと考慮すべきだった後悔ポイントなどをまとめてみます。 間取りは、ぜひ完成時のweb内覧で見てみてください。家具を入れる前の写真なので、室内の作りがわかりやすい…
はてなブログ | 無料ブログを作成しよう
ネイルで使う材料で、DIY時の木割れやネジ跡を派手にしたらかわいい OSB合板でちょっとしたボックスをつくりました。 ビス止め下手すぎて木を割ったり穴あけすぎたりした場所に、好きな派手色の樹脂を詰めてパテ代わりにしてみました。 ちょっと某HAYっぽみ出て可愛かったので、自分用にメモです。 手順 塗装 派手色グミジェルで失敗部分…
高木浩光＠自宅の日記 - はてなブックマークを禁止する技術的方法, 追記, 追記2 （23日）
■ はてなブックマークを禁止する技術的方法 ある属性を持つ人々にとって、はてなブックマークは、必要な情報源を巡回するための効率的なツールとなっている。もはや「はてブ」されない記事は存在しないのも同然となってしまている人もいるかもしれない。ソーシャルブックマークサービスはなにも「はてな」だけではないのだが、事実上「はてな」が独占状態にあり（少なくとも一部の分野においては）、「はてなブックマーク」でないと情報源となり得ない状況になっている。この状況はアーキテクチャ的に望ましい状態ではないと思うが、しかたない。 そういう中で一つ問題がある。情報セキュリティの話題を追いかけるには「セキュリティ」タグを見ていればよいわけだが、ここに「JVN」のエントリが出てこない。 JVNの認知度が高まらないのにはいろいろな要因があって、JVNのサイトデザインが最悪だ（ユーザビリティを何も考えていない）という問題も
SBMのURIは正規化するべきか否か? : 404 Blog Not Found
2007年11月22日16:30 カテゴリiTech SBMのURIは正規化するべきか否か? 以下がやっていることは、 Geekなぺーじ : はてなブックマークを禁止する方法 次に「じゃあ、302 redirectはどうだ？」と考えました。 試してみると、見事に成功しました！ ブックマークされるのはリダイレクトされる先のURLになりました。 原理的には 404 Blog Not Found:http://www.amazon.co.jp/ の「二枚舌」に学ぶ究極のSEO そう、正規化されたURIの方にRedirectされているのである。 で紹介したAmazonの「手口」と同様なのだけど、むしろ少し驚いたのは、 Geekなぺーじ : はてなブックマークを禁止する方法 追記：2007/11/22 どうも、途中からブックマークできるようになったようです。 の方である。 私個人は、botにのみSt
Livedoor clipがContent-Locationヘッダの参照先をブックマークする件 (kuruman.org > Kuruman Memo)
Livedoor clipがContent-Locationヘッダの参照先をブックマークする件Livedoor clipはContent-Locationヘッダの参照先をブックマークする仕様のようだ。はじめに言っておくが、仕様上問題はない。しかしこれには一長一短あり、個人的には好ましくないように思う。理由として2点挙げる。Liverdoor clipには是非仕様変更を検討していただきたい。 例えばこんな例を考えてみる。全く同じ内容である最新版(latest)と毎月の文書(YYYYMM)を提供しているサイトがあるとしよう。latestにリクエストを投げると、そのレスポンスにはYYYYMMを指し示すContent-Locationヘッダを含めることができる。このサイトではそれを提供していたとしよう。Content-Locationヘッダの参照先がブックマークされる場合、間違って最新版をブックマ
ソーシャルサイトでURLの重複チェックをすり抜けるハック | 秋元@サイボウズラボ・プログラマー・ブログ
via reddit 悪用厳禁なハック。Diggなどで新しいニュースを投稿する際に、過去に誰か他の人がまったく同じURLで投稿していると、エラーになってしまうという。 「以前はウケなかったけど自分なら面白い紹介文を書ける」という人は、なんとかしてそのURLをシステムにねじ込みたいかもしれない。そんなときには、サーバやスクリプトエンジンの動きを利用することで、別のURLにして投稿できますよ、というもの。 たとえば、 http://example.com/hoge/ がだめなら、 http://example.com/hoge/./ としてみる。 それから、 http://example.com/hoge/?hoge=hoge などと、無意味なパラメータをつけてみる。パラメータがついても目的のページにアクセスできる場合は、これで重複チェックを飛び越せるというものだ。 メールアドレスもそうだと思
[fswiki] FSWikiでページのURLをstaticにする - おいぬま日報(不定期) (2007-07-15)
@ [fswiki] FSWikiでページのURLをstaticにする だいぶ前は色々とソースを書き換える必要があったのですが、バージョン3.6.3-dev1だと、lib/Wiki.pmのcreate_urlメソッドを以下のように書き換えるだけでこと足りました。素晴らしい！ --- Wiki.pm.orig 2007-07-15 19:49:33.000000000 +0900 +++ Wiki.pm 2007-07-15 19:50:08.000000000 +0900 @@ -1180,6 +1180,10 @@ my $url = $self->config('script_name'); my $query = ''; foreach my $key (keys(%$params)){ + if($key eq 'page') { + $url = $params->{$key}
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC 3987: Internationalized Resource Identifiers (IRIs)
http://www.machu.jp/posts/20080708/p01/
http://fswiki.poi.jp/wiki.cgi?page=BugTrack-plugin%2F350