ファイル拡張子を使用する必要がありますか？
私はいつもこれについて疑問に思っていて、良い解決策を見つけることができませんでした。
しかし この質問 は私にそれを思い出させた。
WebサイトにURLがある場合、次のいずれかの方法で表示およびアクセスできます。
http://www.somesite.com/subdirectory
http://www.somesite.com/subdirectory/
http://www.somesite.com/subdirectory/index.htm
http://www.somesite.com/subdirectory/index.html
http://www.somesite.com/subdirectory/index.php
http://www.somesite.com/subdirectory/index.asp
http://www.somesite.com/subdirectory/some-relevant-keywords
http://www.somesite.com/subdirectory/some-relevant-keywords.htm
http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords
http://www.somesite.com/subdirectory/?page=some-relevant-keywords
http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords
等...
これで、URLにキーワードを追加するメリットを理解できました。最も基本的なSEOガイドでさえ、それを行うために言及します。 ...しかし、健全性、明快さ、読みやすさ、使いやすさなどのために、Webコンプライアンスを含む ...
preferred ファイル拡張子があるかどうか？
本当に、私のロジックの奥深くは私に言う：はい、そうすべきです。理由は、これはインターネットの大部分がUSENET、FIDONET、FTP、Gopherだった過去に遡ることだからです。
URLに filename がない場合、通常は directory と見なされます。これは、index.htmが作成された場所です。これは、インデックスファイルが見つからない場合、デフォルトでディレクトリをリストするためです。しかし、すぐに、Webプログラマーはこれをオーバーライドし、index.htmを使用して実際にそのWebディレクトリのコンテンツをページとして提供し始めました。主な違いは、マークアップ言語が追加されたことで、これはブラウザで解析されました。このマークアップ言語では、応答ヘッダーのContent-Type:text/html;タグが、それがどのファイルタイプであったかを示す指標になりましたfor any file。 HTMLは、保存される場合を除いて、一貫した名前の拡張子を持たない唯一の「ファイルタイプ」のようです。
残念ながら、Webページが主なものになると、ディレクトリの内容を実際に表示することはセキュリティエラーになったため、実際のURLコンテンツのみが表示され、すべてが非表示のままになりました。
クロスプラットフォームのファイル命名戦争については言うまでもありません。ベースのウィンドウには3桁以下の拡張子が必要で、unix/macにはそれ以上のものがあります。 .HTMまたは.HTMLまたはNONEで、プラットフォームに決定させる必要がありますか？
ですから、本質的に、私が理解しようとしているのは、 SEO を超えて、美学とウェブコンプライアンスにもっと対処することです。
複数の表現がある場合、またはクライアントソフトウェアが絶対に愚かで、Content-Typeのみ（QuickTime、RealPlayer、Outlookなど）を受け入れない場合は、.extensionを使用します。
http://www.somesite.com/subdirectory-これは、Canonical METAタグを使用して実際の表現を指すオートネゴシエーションバージョンにすることができますhttp://www.somesite.com/subdirectory/-任意のURLで末尾のスラッシュをサポートする価値がありますが、正しいURLを指すためにCanonical METAタグ（リダイレクトは不要です）を使用しますhttp://www.somesite.com/subdirectory/index.htmおよびhttp://www.somesite.com/subdirectory/some-relevant-keywords.htm-3文字の拡張制限はHTTP（基礎となるFileSystem/OSのみ）には適用されないため、クライアントは必要に応じてこれをindex.htmlまたはaaとして保存できます。アクセスできるhttp://www.somesite.com/subdirectory/index.html-.atom、.xml、または同様のバージョンを提供する場合は、.htmlバージョンも尊重するのが理にかなっています（自動ネゴシエートバージョンのLINKタグを介してCanonicalにリンクする）-HTTPコンテンツを使用します-オートネゴシエーションバージョンを指すロケーションヘッダー-多言語（.en、.esなど）または複数文字セット（.utf8、.utf16など）を使用することもできますhttp://www.somesite.com/subdirectory/index.phpおよびhttp://www.somesite.com/subdirectory/index.asp-ソースコードを提供している場合を除き、これらはサポートする意味がありませんhttp://www.somesite.com/subdirectory/some-relevant-keywords-SEOは絶えず変化する芸術であり、これがあなたに役立つなら素晴らしいhttp://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords、http://www.somesite.com/subdirectory/?page=some-relevant-keywordsおよびhttp://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords-コンテンツを操作する方法が無限にある場合、これは素晴らしいことですが、通常、ページはクエリ文字列ではなく、独自のURLに値します。 URLは使用しないでください（コンピューターの非識字者にそれらの1つを入力させてみてください）
使用しているソフトウェアでファイルの省略が許可されている場合は、do n'tファイル拡張子を含めます。例のリストから、私の好みは次のようになります。
http://www.somesite.com/subdirectory/some-relevant-keywords
ブラウザーは、サイト上の何かがディレクトリであるかどうか、またはそれがHTMLファイル、.aspファイルなどであるかどうかを気にしません。単にHTTPリクエストを作成し、HTTPレスポンスを取得します。したがって、拡張機能が不要な場合は削除してください。
これには、URLをより簡潔にする（および電話で読みやすくする-「ドットコム製品の例」の方がドットコム製品の例のドットHTMLよりもはるかに良い）という利点があり、将来的に技術を切り替えます（URLの変更は必要ないため）。
クールURIは変わりません 。 （「だから私は何をすべきか？URIの設計」というタイトルのセクションに進んでください）
ファイル拡張子を持つことが好ましいですか？
RFCには、ファイル拡張子を持つことを義務付けるものは何もありません。ファイル拡張子を除外する必要があるものもありません。それはあなたの選択です。
適合HTTP URIは、ファイル拡張子を何も必要としません。 HTTPヘッダー（特にMIMEタイプ）の豊富なセットがあり、ファイル拡張子が使用されるすべてを処理します。
とは言っても、今日のほとんどのブラウザは、実際には、コンテンツタイプを決定するために最初のバイトの MIMEタイプ、拡張子、バイナリ「フィンガープリント」の組み合わせ に依存しています。これは時々 驚くべき結果を与える になる可能性があるため、ウェブマスターが正しいヘッダーを設定することが重要です（そしておそらく コンテンツタイプスニッフィングを無効にする ヘッダーが正しいと確信している場合）== 。
ファイル拡張子が役立つ状況が1つあります：エンドユーザーが後で使用するためにサイトからローカルコンピューターにコンテンツを保存する場合。理論的には、「スマート」ブラウザは、保存されたコンテンツがローカルコンピュータータイプで機能することを保証する必要があります。しかし実際には、.jpg、.mp4、.cssなどの業界標準の拡張子を持つコンテンツを提供することで、すべての人を助けることができます。私の経験では、すべてのブラウザーがHTMLタイプを適切に処理します。 HTMLに.htm/.html拡張子を追加する必要はありません。ブラウザはこの特定のコンテンツタイプを正しく処理します。
セキュリティ：使用しているプラットフォーム（.php/.aspなど）を隠すことにはセキュリティ上の利点があると主張することができます。それは本当だ。実際には、優秀なハッカーはすぐにこれを発見すると思うので、セキュリティのためだけにこれらの拡張機能を隠すことは面倒の価値があるとは思わない。
特別な考慮事項：将来CDNを使用する予定で、CDNが「プッシュ」タイプの場合（コンテンツは事前にCDNにアップロードされます） SFX経由のfx）、ファイル拡張子を保持したい場合があります。ほとんどのサードパーティシステムは、ファイル拡張子を見て、コンテンツを提供するMIMEタイプを見つけます。
私の個人的な選択は次のようになりました：
WebアプリケーションによってHTMLが動的に生成される場合、実際には存在しないディレクトリおよびファイル構造を模倣するために、「偽」の.html拡張子を追加しません。 URLを正規化し、SEOの理由で使用されるURL形式を標準化します。個人的には、URLの最後の葉、つまり
http://example.org/first/second/に末尾のスラッシュを付けることを好みますが、それは好みの問題です。実際にどこかにあるハードディスクにアップロードされる実際のファイルについて話しているとき、そのタイプの「通常の」ファイル拡張子を保持します。したがって、これらの種類のコンテンツには.css/.js/.exe/.mp4などが使用されています。
私は少し非公式の実験を行いましたが、私が発見したことは驚きましたが、ある程度理にかなっています。
ユーザーに配信されるコンテンツの観点から、およびスクリーンスクレイピングの観点から、Content-Typeはその日を支配します。
ただし、拡張機能の有無、およびその拡張機能が何であるかは、検索エンジンの訪問を左右するようです。
拡張子をまったく省略した場合、URLが場所または動的コンテンツであり、インデックスを作成する価値がないかのように、ヒットが比較的少なくなりました。
ページが実際に（サーバー側で）XSLTによって生成されたため、同じリンクを.xml拡張子を使用するように変更すると、インデックス付けは実際にはさらに低下しました-おそらくそれが単なるデータまたは何らかのプログラムによるリクエストの結果だと考えたためです。
.htmlを使用するように同じリンクを変更すると、検索エンジンがサイトに突入しました。
現時点では、私のサイトは3つすべてを透過的に処理しますが、クリック可能なリンクが提供されると、.htmlバージョンのURLを返します。
検索エンジンはもう少し賢く、または少し偏りが少ないと思いたいのですが、それは私のページで起こっていることです。
いいえ、技術的な理由で絶対に必要でない限り、通常のページタイプにファイル拡張子を使用しないでください。 ユーザーエクスペリエンスをどのように改善しますか？入力するのは簡単ですが、それでも有用なことは何もありません。あなたのサイトがPHP、ASPなどであることを知って、彼らは何ができるでしょうか？ URLは、ファイル拡張子なしで、よりシンプルで、よりクリーンで、より使いやすく、より記憶に残ります。
URLにファイル名がない場合、通常はディレクトリと見なされます。
私は同意するとは思わない。通常、URLは、末尾にスラッシュがある場合にのみディレクトリです。末尾のスラッシュがない場合、ファイルと見なされます。
URIの背後にあるコンテンツが実際にファイルである場合にのみ、ファイル拡張子を追加する必要があります。ただし、その表現（JPG、PDFなど）が1つしかない場合は、ドロップすることもできます。
複数の表現がある場合、HTTPウェイはAcceptヘッダーを介してネゴシエートされた形式になります。ただし、ユーザーに発言権を持たせたい場合は、拡張機能を使用して、1つまたは他のURIを要求することで、希望する表現（JPG、PNG、...）を選択できるようにします。