Robots Meta Tags Specifications | Google Search Central | Documentation | Google for Developers
SEO fundamentals Introduction Search Essentials SEO Starter Guide How Google Search Works Do you need an SEO? Crawling and indexing Sitemaps robots.txt Meta tags Crawler management Removals Canonicalization Redirects JavaScript SEO Ranking and search appearance Visual Elements gallery Title links Snippets Images Videos Structured data Favicons Site-specific guides Ecommerce International and multi
Really Simple Syndication Best Practices Profile
RSS Advisory Board Really Simple Syndication specifications, tutorials and discussion Really Simple Syndication Best Practices Profile Editor's Note: This profile contains a set of recommendations for Really Simple Syndication, a web syndication format documented in the RSS 2.0 specification. This is version 1.0 of this document, published Oct. 15, 2007. The current version will always be availabl
[tech]HTTP GETメソッドのURIの長さ制限を調べてみた - Kazumi007の日記
Webの開発者をやっていると良くいわれていることですが、HTTP GETメソッドを使うなという話を聞きます。セキュリティの点もありますが、HTTP GETメソッドですべてのパラメータをサーバに送れないからというのがその理由のようです。 実際どこからでているのか、現在もそうなのか？という疑問を感じたので、HTTP GETの制限を調べてみました。 RFCではどうなっているの？ まずHTTP1.1のRFC2616を調べました。 とりあえず、日本語訳がありましたので、引用いたします。http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616より HTTP プロトコルでは、URI の長さにどんな制限も設けていない。 サーバは、自身が持つどんなリソースのURI も扱えなければならないし、もしそのような URI を生成する GET ベースのフォームを用意するなら、無
![[tech]HTTP GETメソッドのURIの長さ制限を調べてみた - Kazumi007の日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/dc5ae93dec0cf6107772deee61d36de43276fd14/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127136432888%2F17680117127136435012%2F1558043428)
t.co links
<g> <g> <defs> <rect id="SVGID_1_" x="-468" y="-1360" width="1440" height="3027" /> </defs> <clippath id="SVGID_2_"> <use xlink:href="#SVGID_1_" style="overflow:visible;" /> </clippath> </g> </g> <rect x="-468" y="-1360" class="st0" width="1440" height="3027" style="fill:rgb(0,0,0,0);stroke-width:3;stroke:rgb(0,0,0)" /> <path d="M13.4,12l5.8-5.8c0.4-0.4,0.4-1,0-1.4c-0.4-0.4-1-0.4-1.4,0L12,10.6L6.2
Twitter経由のリファラでtwitter.comが減少し、t.coが急増している理由 - F.Ko-Jiの「一秒後は未来」
最近アクセス解析のリファラを見て、t.coが増えてるなぁと思っている人いませんか？ Twitterの公式ドキュメントによると、Twitterの短縮URL「t.co」のリダイレクト処理はアクセス元のサイトやユーザーエージェントによって細かく定義されていて、それによりリファラがアクセス元のサイトになる場合と、t.coになる場合とがあるようなのです。(いつの間に！) t.coでリダイレクトされた時のリファラの仕様 2011年8月31日時点での仕様は以下のようになっています。左側はt.coのクリックが発生したサイトやクライアント、右側はその際のリファラです。 twitter.com以外のサイト → リファラ指定があればリファラを維持、なければ t.co twitter.com以外のサイト、SSL → t.co twitter.com → t.co Twitter公式アプリ → t.co サイトに貼
検索エンジン3社が開始した、rel=canonicalの使い方 | Creazy!
Google、Yahoo!、Live(Microsoft)の3社が「ページの正当なURL」を定義するための方法を導入する事になったようです。 headタグの中にrel=”canonical”というlinkタグを記述すれば良いそうです。 <link rel="canonical" href="http://creazy.net/" /> 詳しい説明は下記ページが参考になりました。 ・検索エンジン3社、正しいサイトURLを認識させるcanonical属性を導入（URLの正規化） :: SEM R ・サイト内の重複コンテンツを防ぐ新たな手段、rel=”canonical”が登場 – F.Ko-Jiの「一秒後は未来」 で、早速色々試してみました。 MT(MovableType)で正統なURLを指定する方法 下記のようなタグをテンプレートのheadの中に指定するだけです。 （※エントリーアーカイブ用
HTML 5 / A vocabulary and associated APIs for HTML and XHTML / W3C Working Draft 22 January 2008
Table of contents 1 Introduction2 Common infrastructure3 Semantics, structure, and APIs of HTML documents4 The elements of HTML5 Microdata6 User interaction7 Loading web pages8 Web application APIs9 Communication10 Web workers11 Worklets12 Web storage13 The HTML syntax14 The XML syntax15 Rendering16 Obsolete features17 IANA considerationsIndexReferencesAcknowledgmentsIntellectual property rights F
Final: OpenID Authenticaion 2.0 - 最終版
Abstract OpenID AuthenticationはエンドユーザーがIdentifierを取り扱う際に信頼できる方法を提供します。その方法とはRelying Partyがパスワードのようなエンドユーザーのクレデンシャルやメールアドレスのような他のセンシティブな情報にアクセスする必要のないものです。 OpenIDは中央集権的ではありません。Relying PartyやOpenIDプロバイダを承認したり登録したりする中心となる権威も存在しません。エンドユーザーは自由にOpenIDプロバイダを利用するために選択する事ができ、さらにOpenIDプロバイダを変えたとしても自分達のIdentifierを保つ事が可能です。 このプロトコルではJavaScriptやモダンブラウザを必要とはしませんが、この認証スキーマは"AJAX"スタイルのセットアップで上手く動作します。この事が意味するの
ウノウラボ Unoh Labs: ブラウザから使用できる仕様書を書くツールまとめ
こんにちはsatoです。Windows以外の環境で仕様書を書こうと思うと、なかなか良いアプリがなかったりまします。今回はブラウザから使用できる仕様書作成ツールをまとめてみました。 1) オンラインで配置図などを描く Gliffy 配置図などをオンラインで描くことができます。また 画像への出力なども対応しています。いわゆるVisioの代わりになるツールです。 2) pdfファイルをtextに変換する PDFTextOnline pdfをtextに変換することができます。pdfの内容をスクリプトなどで切り出して、データ化するときなどに役に立ちます。他にもいろいろな変換するサイトやツールがあるのですが、ここは日本語が正常に通って見た目通りに変換できます。 3) データベースのテーブル定義などを書く WWW SQL Designer オンラインでER図などが書けます。以前miyakeさんが紹介して
XHTML1.0 Strict 内容モデル
head要素の子要素 <base /> href属性必須 空要素 <link /> 空要素 <meta /> content属性必須 空要素 <object>-</object> 他の内容よりも param要素を先行させるべき param要素 ブロックレベル要素 インライン要素 テキスト <param /> name属性必須 空要素 <script>-</script> type属性必須 スクリプト（PCDATA） <style>-</style> type属性必須 スタイルシート（PCDATA） <title>-</title> head要素内に必ず1個だけ定義 テキストのみ（PCDATA） ブロックレベル要素 <address>-</address> インライン要素 テキスト <blockquote>-</blockquote> ブロックレベル要素 <div>-</div> ブロックレ
ちょっとしたメモ - Dublin Core定義域、値域の案
昨年の6月頃から動きがあったDublin Coreのモデルを再定義するという話の結果、新DCMI抽象モデル案、DCMI名前空間ポリシー改訂案、そしてDCプロパティの定義域、値域案が公開され、3月5日までが公開コメント期間となっている。注目の定義域、値域は、基本15要素には採用せず、その代わりこれらと同じプロパティをdcterms:空間にも定義して、こちらに定義域、値域を持たせるという案だ。 プロパティに定義域、値域を持たせれば、主語、述語のクラスを推論できることに加え、プロパティの使い方に関する約束を示すことにもなる。アプリケーションは、dc:creatorの目的語がリテラルなのかリソースノードなのかについて余計な検証をすることなく、安心して処理できるようになるわけだ。仕様案の言葉でいえば次のようになる。 In practice, this means that the domain in
W3C - W3Cの仕様書等の文書の日本語訳集
注意 日本語翻訳集は w3c-translators@w3.org メーリングリスト上で報告された日本語翻訳文書へのリンクを集めたものです． リンクされた翻訳はボランティアによって行われたものです． またこれらの翻訳には誤りが含まれる可能性もあります． 正式なものはあくまでも英語版ですので， この点をご理解頂いた上でご利用下さい． またコピーライトに関する情報を含め，W3Cの文書の翻訳に関しての一般的な情報や， 翻訳の際のヘルプは， http://www.w3.org/Consortium/Translation/にあるW3C翻訳ページ(英語版) をご覧下さい． TR集 勧告 ・ 勧告案 ・ 勧告候補 ・ 草案 ・ 技術ノート その他の文書等 FAQ集 ・ その他 TR集 勧告 HTML 4 (勧告) http://www.asahi-net.or.jp/~bd9y-ktu/html4re
RSS Autodiscovery
RSS Advisory Board Really Simple Syndication specifications, tutorials and discussion Editor's Note: This is version 1.0 of this document, published Nov. 27, 2006. 1. Introduction RSS autodiscovery is a technique that makes it possible for browsers and other software to automatically find a site's RSS feed, whether it's in RSS 1.0 or RSS 2.0 format. Supported by Mozilla Firefox 2.0, Microsoft Inte
OpenID
Our mission is to lead the global community in creating identity standards that are secure, interoperable and privacy-preserving. Founded in 2007, the OpenID Foundation (OIDF) is a global open standards body committed to helping people assert their identity wherever they choose. We are global vibrant community where identity peers and thought leaders convene to craft the identity ecosystems of tom
ちょっとしたメモ - CSS 2.1の最終草案再び
CSS 2.1仕様のラストコールが11月6日付でまたまた（何回目？）登場。本質的なところでは変化はないものの、4月の草案と比べると多少の手直しが見られる。いい加減に勧告候補に進んで欲しいものだ。 大きな見直しの一つは、min/max-width/heightと画像のような内在アスペクト比を持つ置換要素との関係（セクション10.4）。こうした要素のwidthもしくはheightだけを明示的に指定して、もう一方をmin/max指定したとき、内在比と矛盾が出たらどうしよういう部分だ。たとえば縦横比1:1である画像に対して、 {width:200px; min-height:300px} というスタイルを宣言すると、画像は正方形ではなく縦長になってしまう（というのが従来の仕様）。これに対して、min/maxの場合は内在比を尊重すべきではないかという意見が出て、WGでまとまらないのでコメントを求むと
MIME（Multipurpose Internet Mail Extensions）～後編
MIME（Multipurpose Internet Mail Extensions）～後編：インターネット・プロトコル詳説（4） 複数ファイルを同時送信するマルチパート・メール 前回（第3回「メールにかけられた呪文〜MIME（前編）」）は、主に単一のファイルをインターネットメールに添付する場合について説明した。しかし、実際にメールを送受信する際には、本文にテキストを記載し、アプリケーションのデータや画像ファイルを複数添付することが多い。このような場合に利用するのが、マルチパート（multipart）メディアタイプというものである。 マルチパート・メディアタイプとは、“マルチパート”という言葉が示すように、複数の添付ファイルをまとめたメディアタイプのことである。ここで次の例を見てほしい。 Date: Mon, 19 Feb 2001 04:17:19 +0900 From: "Taro Y
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
Manuals, Specs, and Downloads - Apple Support
TechCrunch Japanese アーカイブ » 速報：Google、「Android」と「Open Handset Alliance」発表
CSS 2.1のエッセンス -- 脱初心者をめざす人のためのホームページ作成講座