URL của tôi có nên viết thường không?


17

Theo blog này ("Tìm hiểu thực tiễn cú pháp URL thân thiện với SEO") tôi nên thay đổi

http://example.com/Hello-Dolly

Đến

http://example.com/hello-dolly

Những lý do được đưa ra là:

  • Các URL, nói chung, phân biệt chữ hoa chữ thường
  • nó sẽ đơn giản hóa mọi báo cáo phân tích và SEO nhạy cảm

Theo GIF này mà tôi tìm thấy trên bài viết của Wikipedia về Bình thường hóa URL, tôi nên chuyển đổi URL của mình từ bất kỳ chữ hoa nào sang chữ thường.

Tuy nhiên, tôi sử dụng ASP.NET MVC và theo mặc định, URL của tôi có cấu trúc như thế này ( CamelCase ):

http://www.example.com/Controll/Action/Parameter

http://www.example.com/C chuyên mục / List / Biic

Tôi đã lướt qua RFC1738 nhưng tôi không thấy câu trả lời dứt khoát nào cho vấn đề này.

Tôi có nên đi ra ngoài để buộc khung thay đổi mọi thứ thành chữ thường? Tại sao Microsoft chọn thiết kế khung của họ như thế này nếu mọi người bảo tôi sử dụng chữ thường?


3
Câu hỏi tuyệt vời và trình bày tuyệt vời về truy vấn của bạn cho cộng đồng ở đây tại webmasters.stackexchange.com! Bạn thực sự đã làm 'bài tập về nhà' của bạn về vấn đề này trước khi hỏi!
dvnkiss

Tôi gặp phải một vấn đề trong đó một proxy đã thay đổi URL được yêu cầu thành tất cả chữ thường - và gây ra 404 theo yêu cầu cho máy chủ Linux lưu trữ một trang trong thư mục con ./SO/ của tôi (nơi tôi đặt các ví dụ stackoverflow). Đó là trường hợp sử dụng trong đó chữ thường tạo ra sự khác biệt (bạn có thể cho rằng proxy bị mã hóa kém nhưng đó là cuộc sống thực ...)
Floris

Câu trả lời:


10

Should I go out of my way to force the framework to change everything to lower case?

Không, điều đó không cần thiết. Các hệ điều hành Windows không phân biệt chữ hoa chữ thường, bao gồm các ứng dụng khung và hệ điều hành máy chủ của chúng. Tuy nhiên, các hệ điều hành Linux / Unix rất phân biệt chữ hoa chữ thường.

Các ứng dụng dựa trên Internet (ví dụ: trình duyệt) sẽ bình thường hóa URL, như được nêu trong phần 6 của RFC 3986 :

Một trong những hoạt động phổ biến nhất trên các URI là so sánh đơn giản: xác định xem hai URI có tương đương mà không sử dụng URI để truy cập (các) tài nguyên tương ứng của chúng hay không. Một so sánh được thực hiện mỗi khi truy cập bộ đệm phản hồi, trình duyệt kiểm tra lịch sử của nó để tô màu một liên kết hoặc trình phân tích cú pháp XML xử lý các thẻ trong một không gian tên. Chuẩn hóa mở rộng trước khi so sánh các URI thường được sử dụng bởi các trình thu thập dữ liệu và công cụ lập chỉ mục để cắt xén không gian tìm kiếm hoặc để giảm trùng lặp các hành động yêu cầu và lưu trữ phản hồi.

Vì bạn sẽ sử dụng máy chủ Windows, nên các URL và URI được yêu cầu sẽ được trả lại cho các ứng dụng khách tốt.


Liên quan đến các công cụ tìm kiếm, như đã nêu trong RFC ở trên và trong liên kết Wikipedia của bạn về Chuẩn hóa URL :

Các công cụ tìm kiếm sử dụng chuẩn hóa URL để gán tầm quan trọng cho các trang web và để giảm việc lập chỉ mục các trang trùng lặp.

Và như các nguồn như báo cáo này về chủ đề:

Gần đây, Google bắt đầu hiểu rõ hơn rằng /page1.html và /Page1.html chỉ là hai trường hợp của cùng một nội dung.


Why did Microsoft choose to design their framework like this if everybody is telling me to use lowercase?

Nó tương thích với hệ điều hành của họ và về mặt kỹ thuật không chính xác theo RFC. Họ cũng có cách làm việc riêng của họ, điều này khiến các quản trị web đoán :-)


1
Câu trả lời tuyệt vời, tôi sẽ đăng một câu trả lời rất giống nhau nhưng bạn đã đánh bại tôi! "Tại sao Microsoft lại chọn thiết kế khung của họ như thế này nếu mọi người bảo tôi sử dụng chữ thường? ... Họ cũng có cách làm việc riêng của họ, điều này khiến các quản trị web đoán." - Yêu chút đó. Theo như tôi có thể nhớ, Microsoft đã có những phương tiện riêng để 'làm cho' các nhà phát triển / quản trị web uốn cong theo các quy tắc cứng nhắc của họ!
dvnkiss

4

Tôi không biết rằng bạn nên thay đổi nó nhưng bạn nên đảm bảo nhất quán.

Tôi đã xem xét điều này một vài năm trước và tiêu chuẩn của Google là trường hợp đó trước khi TLD không thành vấn đề nhưng sau TLD thì không.

Tại thời điểm tôi đang làm việc trên một trang web không còn tồn tại được gọi là BusinessForPhotographers.com; rõ ràng điều đó luôn được coi là trường hợp không nhạy cảm.

Sau đó .comlà một vấn đề khác. Google xem /Great-Articlelà khác biệt /great-article, ngay cả khi máy chủ của bạn định tuyến chúng đến cùng một nơi.

Điều này có thể ảnh hưởng đến tiêu chuẩn hóa và các vấn đề nội dung trùng lặp. Tôi nghĩ rằng phương pháp an toàn nhất sẽ là chuyển hướng 301 sang phiên bản chính xác.

Mặc dù điều này có vẻ vô nghĩa khi nghĩ về một dịch vụ như YouTube, /A1B2C3nhưng URL có giống như /a1b2c3không?

Không phải trong mắt của Google.


3

Đường dẫn URI phân biệt chữ hoa chữ thường (nếu không được định nghĩa khác). Xem tiêu chuẩn URI STD 66, mục 6.2.2.1. Bình thường hóa trường hợp :

Các thành phần cú pháp chung khác được coi là phân biệt chữ hoa chữ thường trừ khi được quy định cụ thể theo cách khác

Nếu các chữ cái viết hoa trong đường dẫn HTTP URI sẽ là một vấn đề đối với một số người dùng, Wikipedia sẽ bị phá vỡ đối với họ. Hai URI HTTP này (chỉ khác nhau về chữ thường ovà chữ hoa O) dẫn đến các trang khác nhau:

Vì vậy, không, bạn không phải thay đổi URI của mình.

Tuy nhiên, nếu có thể (nếu bạn không sử dụng trường hợp như Wikipedia), thì nên cho phép tất cả các biến thể trường hợp và chuyển hướng 301 sang một biến thể chính tắc.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.