Tôi có nên sử dụng một phần mở rộng tập tin hay không?

Tôi đã luôn tự hỏi về điều này và không bao giờ tìm thấy một giải pháp tốt.

Nhưng câu hỏi này làm tôi nhớ về nó.

Khi tôi có một URL trên trang web của mình, nó có thể được hiển thị và truy cập theo bất kỳ cách nào sau đây:

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

v.v ...

Bây giờ, tôi có thể hiểu giá trị của việc thêm từ khóa trong URL. Ngay cả hướng dẫn SEO cơ bản nhất cũng sẽ đề cập để làm điều đó. ... nhưng vì lợi ích của sự tỉnh táo, rõ ràng, dễ đọc, dễ sử dụng, v.v., bao gồm cả việc tuân thủ web ...

Có ưu tiên mở rộng tập tin hay không?

Thực sự, sâu bên dưới logic của tôi nói với tôi: có, nó nên. Lý do là điều này bắt nguồn từ những ngày trước khi internet chủ yếu là USENET, FIDONET, FTP và GOPHER.

Xem, nếu một URL không có tên tệp , thì nó thường được coi là một thư mục . Đây là nơi index.htm xuất hiện, bởi vì điều này theo mặc định liệt kê thư mục nếu không tìm thấy tệp chỉ mục. Tuy nhiên, chẳng mấy chốc, các lập trình viên web đã bắt đầu ghi đè lên điều này và sử dụng index.htm để thực sự phục vụ nội dung của thư mục web đó như một trang . Sự khác biệt chính, là ngôn ngữ đánh dấu đã được thêm vào và điều này đã được phân tích cú pháp trong trình duyệt. Với ngôn ngữ đánh dấu này, Content-Type:text/html;thẻ trong tiêu đề phản hồi đã trở thành chỉ báo cho loại tệp nào cho bất kỳ tệp nào . HTML dường như là "filetype" duy nhất không có tên mở rộng liên tục, ngoại trừ khi chúng được lưu.

Thật không may, một khi các trang web trở thành vấn đề chính, nó thực sự trở thành một lỗi bảo mật để thực sự hiển thị nội dung thư mục, vì vậy mọi thứ bị ẩn chỉ với nội dung URL thực sự được hiển thị.

Chưa kể các cuộc chiến đặt tên tệp đa nền tảng .. các cửa sổ dựa trên yêu cầu mở rộng 3 chữ số trở xuống và unix / mac có thể có nhiều hơn. Vì vậy, nó nên .HTMhoặc .HTMLhoặc NONEđể cho nền tảng quyết định?

Vì vậy, về bản chất, tôi đoán những gì tôi đang cố gắng tìm ra là vượt ra ngoài SEO và xử lý nhiều hơn về tính thẩm mỹ và tuân thủ web.

Sử dụng .extension trong đó có nhiều hơn một đại diện hoặc trong đó phần mềm máy khách hoàn toàn ngu ngốc và từ chối chấp nhận Loại Nội dung một mình (QuickTime, RealPlayer, Outlook, v.v. Tôi đang xem xét bạn):

• http://www.somesite.com/subdirectory - đây có thể là phiên bản tự động đàm phán của bạn sử dụng các thẻ META Canonical để chỉ ra đại diện thực tế

• http://www.somesite.com/subdirectory/ - luôn đáng để hỗ trợ dấu gạch chéo trên bất kỳ URL nào nhưng sử dụng thẻ META của Canonical (không phải chuyển hướng vì đây là một sự chậm lại không cần thiết) để trỏ đến đúng URL

• http://www.somesite.com/subdirectory/index.htmvà http://www.somesite.com/subdirectory/some-relevant-keywords.htm- giới hạn mở rộng ba ký tự không áp dụng cho HTTP (chỉ Hệ thống tệp / hệ điều hành cơ bản) để khách hàng có thể lưu tệp này dưới dạng index.html hoặc aa nếu họ muốn, trong khi vẫn có thể truy cập nó

• http://www.somesite.com/subdirectory/index.html - nếu bạn phục vụ .atom, .xml hoặc phiên bản tương tự thì cũng nên tôn trọng phiên bản .html (và liên kết Canon với nó thông qua các thẻ LINK trên phiên bản tự động đàm phán) - sử dụng tiêu đề HTTP Content-Location để trỏ đến phiên bản tự động đàm phán - hãy nhớ rằng bạn cũng có thể sử dụng đa ngôn ngữ (.en, .es, v.v ...) hoặc đa bộ ký tự (.utf8, .utf16, v.v ...)

• http://www.somesite.com/subdirectory/index.phpvà http://www.somesite.com/subdirectory/index.asp- trừ khi bạn đang phục vụ mã nguồn thì chúng không có ý nghĩa gì để hỗ trợ

• http://www.somesite.com/subdirectory/some-relevant-keywords - SEO là một nghệ thuật liên tục thay đổi và nếu điều này làm việc cho bạn thì tuyệt vời

• http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords, http://www.somesite.com/subdirectory/?page=some-relevant-keywordsVà http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords- nếu có một số lượng vô hạn các cách để thao tác các nội dung thì đây là tuyệt vời - nhưng thường trang xứng đáng URL riêng của họ không phải là một chuỗi truy vấn và các loại URL được để tránh (thử nhận biết chữ máy tính một người nào đó gõ một trong những người trong)

Tôi sẽ nói không bao gồm phần mở rộng tập tin nếu phần mềm bạn đang sử dụng cho phép bạn bỏ qua phần mềm. Vì vậy, từ danh sách các ví dụ của bạn, sở thích của tôi sẽ là:

http://www.somesite.com/subdirectory/some-relevant-keywords

Các trình duyệt không quan tâm liệu thứ gì đó có phải là thư mục hay không trên trang web, hoặc đó là tệp HTML, tệp .asp hay bất cứ thứ gì - họ chỉ cần thực hiện một yêu cầu HTTP và nhận được phản hồi HTTP. Vì vậy, nếu phần mở rộng là thừa, hãy bỏ nó.

Điều này cũng có thêm lợi ích là làm cho URL của bạn ngắn gọn hơn (và dễ đọc hơn trên điện thoại - "ví dụ sản phẩm slash dot com" nghe hay hơn nhiều so với "ví dụ dot com slash sản phẩm dot htm l") và làm cho nó dễ dàng hơn để chuyển đổi công nghệ trong tương lai (vì sẽ không cần thay đổi URL).

URI tuyệt vời không thay đổi . (Chuyển đến phần có tiêu đề "Vậy tôi nên làm gì? Thiết kế URI")

Có ưu tiên mở rộng tập tin hay không?

Không có gì trong RFC bắt buộc phải có phần mở rộng tệp, cũng không có gì yêu cầu bạn phải loại bỏ chúng. Đó là một lựa chọn bạn thực hiện.

HTTP URI phù hợp không cần phần mở rộng tệp cho bất cứ điều gì. Có một bộ tiêu đề HTTP phong phú (đặc biệt là loại MIME) để xử lý mọi thứ mà phần mở rộng tệp được sử dụng cho mục đích khác.

Điều đó nói rằng, hầu hết các trình duyệt ngày nay thực tế đều dựa vào sự kết hợp của loại MIME, phần mở rộng và "dấu vân tay" nhị phân của các byte đầu tiên để xác định loại nội dung. Điều này đôi khi có thể mang lại kết quả đáng ngạc nhiên và điều quan trọng là các quản trị viên web của chúng tôi phải đặt đúng tiêu đề (và có thể vô hiệu hóa loại nội dung đánh hơi nếu chúng tôi chắc chắn 101% tiêu đề của mình là chính xác).

Có một tình huống mà tiện ích mở rộng tệp hữu ích: Nếu người dùng cuối lưu nội dung từ trang web của bạn vào máy tính cục bộ của mình để sử dụng sau. Về mặt lý thuyết, trình duyệt 'thông minh' phải đảm bảo rằng nội dung đã lưu hoạt động cho loại máy tính cục bộ; nhưng trong thực tế, bạn có thể giúp mọi người bằng cách cung cấp nội dung với các tiện ích mở rộng theo tiêu chuẩn ngành như .jpg, .mp4, .css, v.v. Theo kinh nghiệm của tôi, tất cả các trình duyệt đều xử lý đúng loại HTML. Bạn không cần phải tự thêm tiện ích mở rộng .htm / .html trên HTML, trình duyệt sẽ xử lý chính xác loại nội dung cụ thể này.

Bảo mật: Người ta có thể lập luận rằng có một lợi ích bảo mật trong việc ẩn nền tảng nào bạn đang sử dụng (.php / .asp, v.v.). Đung. Trong thực tế, tôi nghĩ rằng bất kỳ hacker giỏi nào cũng sẽ phát hiện ra điều này ngay lập tức, vì vậy tôi không nghĩ việc che giấu các tiện ích mở rộng này để bảo mật là đáng để xử lý.

Cân nhắc đặc biệt: Nếu bạn dự định sử dụng CDN trong tương lai và CDN của bạn thuộc loại "đẩy" (nội dung được tải lên CDN trước fx thông qua SFTP), thì bạn có thể muốn giữ các phần mở rộng tệp. Hầu hết các hệ thống bên thứ 3 nhìn vào các phần mở rộng tệp để khám phá loại MIME nào sẽ phục vụ nội dung.

Lựa chọn cá nhân của tôi đã trở thành:

• Khi HTML được tạo một cách linh hoạt bởi ứng dụng web của tôi, tôi không thêm phần mở rộng 'giả' .html để bắt chước cấu trúc thư mục và tệp không thực sự ở đó. Tôi bình thường hóa URL và tôi chuẩn hóa định dạng URL được sử dụng vì lý do SEO. Cá nhân tôi thích có một dấu gạch chéo trên lá cuối cùng của URL http://example.org/first/second/, nhưng đó là vấn đề của hương vị.

• Trong thực tế, khi chúng ta đang nói về các tệp thực tế được tải lên ổ cứng ở đâu đó, thì tôi giữ phần mở rộng tệp 'bình thường' cho loại. Vì vậy, .css / .js / .exe / .mp4 vv được sử dụng cho các loại nội dung này.

Tôi đã thực hiện một thử nghiệm không chính thức, và những gì tôi phát hiện ra làm tôi ngạc nhiên nhưng có ý nghĩa.

Từ quan điểm phân phối nội dung đến người dùng, cũng như quét màn hình, Loại nội dung quy định ngày.

Tuy nhiên, sự hiện diện hay vắng mặt của một phần mở rộng, cũng như phần mở rộng đó là gì, dường như làm ảnh hưởng đến các lượt truy cập của công cụ tìm kiếm.

Khi tôi bỏ qua bất kỳ tiện ích mở rộng nào, tôi nhận được tương đối ít lượt truy cập - như thể URL là một vị trí hoặc nội dung động và do đó không có giá trị lập chỉ mục nhiều.

Khi tôi thay đổi các liên kết tương tự để sử dụng phần mở rộng .xml, vì các trang thực sự được tạo bởi XSLT (về phía máy chủ), việc lập chỉ mục thực sự giảm hơn nữa - có lẽ vì nó chỉ là dữ liệu hoặc kết quả của một số yêu cầu lập trình .

Khi tôi thay đổi các liên kết tương tự để sử dụng .html, các công cụ tìm kiếm đã phát cuồng với trang web.

Hiện tại, trang web của tôi xử lý cả ba trong suốt, nhưng khi nó cung cấp một liên kết có thể nhấp, tôi trả lại phiên bản .html của URL.

Tôi muốn nghĩ rằng các công cụ tìm kiếm thông minh hơn một chút hoặc ít sai lệch hơn một chút, nhưng đó là những gì tôi đã quan sát thấy xảy ra với các trang của mình.

Không, bạn không nên sử dụng tiện ích mở rộng tệp cho các loại trang thông thường trừ khi bạn thực sự cần nó vì lý do kỹ thuật. Làm thế nào để cải thiện trải nghiệm người dùng? Nó là nhiều hơn để gõ, nhưng nó nói với họ không có gì hữu ích. Họ sẽ có thể làm gì khi biết rằng trang web của bạn là PHP, ASP, v.v.? Một URL đơn giản hơn, sạch hơn, dễ sử dụng hơn và dễ nhớ hơn mà không cần phần mở rộng tệp.

Xem, nếu một URL không có tên tệp, thì nó thường được coi là một thư mục.

Tôi không nghĩ tôi đồng ý. Nói chung, URL là một thư mục chỉ khi nó có dấu gạch chéo. Không có dấu gạch chéo, nó được coi là một tệp.

Bạn chỉ nên thêm một phần mở rộng tệp, nếu nội dung đằng sau URI thực sự là một tệp. Nhưng ngay cả sau đó bạn có thể loại bỏ nó, nếu chỉ có một đại diện cho nó (JPG, PDF, ...).

Nếu có nhiều biểu diễn, cách HTTP sẽ có định dạng được thương lượng thông qua Accepttiêu đề. Nhưng nếu bạn muốn người dùng của mình có tiếng nói trong đó, có lẽ bạn sẽ muốn có một tiện ích mở rộng để họ có thể chọn đại diện nào họ muốn (JPG, PNG, ...) bằng cách yêu cầu một hoặc URI khác.