ฉันควรใช้นามสกุลไฟล์หรือไม่?

ฉันเคยสงสัยเกี่ยวกับเรื่องนี้และไม่เคยพบทางออกที่ดี

แต่คำถามนี้ทำให้ฉันนึกถึงมัน

เมื่อฉันมี 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 ที่สุดจะพูดถึงการทำเช่นนั้น ... แต่เพื่อความมีสติชัดเจนอ่านง่ายใช้งานง่ายและอื่น ๆรวมถึงการปฏิบัติตามเว็บ ...

มันต้องการที่จะมีนามสกุลไฟล์หรือไม่?

จริง ๆ แล้วตรรกะของฉันบอกฉันว่า: ใช่มันควรจะเป็น เหตุผลก็คือสิ่งนี้เกิดขึ้นในสมัยของอดีตเมื่ออินเทอร์เน็ตส่วนใหญ่เป็น USENET, FIDONET, FTP และ GOPHER

ดูถ้า URL ที่ไม่มีชื่อไฟล์แล้วมันปกติถือว่าเป็นไดเรกทอรี นี่คือที่ index.htm มาเกี่ยวกับเพราะโดยปกติรายการไดเรกทอรีหากไม่พบไฟล์ดัชนี อย่างไรก็ตามในไม่ช้านักโปรแกรมเมอร์เว็บก็เริ่มเอาชนะสิ่งนี้และใช้ index.htm เพื่อแสดงเนื้อหาของสารบบเว็บนั้น ๆ ความแตกต่างหลักคือภาษามาร์กอัปถูกเพิ่มเข้ามาและนี่คือการแยกวิเคราะห์ในเบราว์เซอร์ ด้วยภาษามาร์กอัปนี้Content-Type:text/html;แท็กในส่วนหัวของการตอบสนองกลายเป็นตัวบ่งชี้เพื่อสิ่งที่มันเป็น filetype สำหรับไฟล์ใด ๆ HTML ดูเหมือนจะเป็น "ประเภทไฟล์" เดียวที่ไม่ได้มีนามสกุลอย่างต่อเนื่องยกเว้นเมื่อมีการบันทึก

น่าเสียดายที่เมื่อหน้าเว็บกลายเป็นสิ่งสำคัญแล้วมันก็กลายเป็นข้อผิดพลาดด้านความปลอดภัยในการแสดงเนื้อหาของไดเรกทอรีจริงๆดังนั้นทุกสิ่งจึงถูกซ่อนไว้โดยมีเพียงเนื้อหา URL ที่แท้จริงเท่านั้นที่ถูกแสดง

ไม่ต้องพูดถึงสงครามการตั้งชื่อไฟล์ข้ามแพลตฟอร์ม .. หน้าต่างที่ใช้ต้องมีนามสกุล 3 หลักหรือน้อยกว่าและ unix / mac สามารถมีได้มากกว่า ดังนั้นควรเป็น.HTMหรือ.HTMLหรือNONEและให้แพลตฟอร์มตัดสินใจ

ดังนั้นในสาระสำคัญฉันคาดเดาสิ่งที่ฉันพยายามคิดออกเป็นเกิน SEOและจัดการกับความสวยงามและการปฏิบัติตามเว็บ

ใช้. ส่วนขยายที่มีการแสดงมากกว่าหนึ่งรายการหรือในที่ที่ไคลเอ็นต์ซอฟต์แวร์นั้นโง่และปฏิเสธที่จะยอมรับประเภทเนื้อหาเพียงอย่างเดียว (QuickTime, RealPlayer, Outlook และอื่น ๆ ที่ฉันกำลังมองหาคุณ):

• http://www.somesite.com/subdirectory - นี่อาจเป็นเวอร์ชันการต่อรองอัตโนมัติของคุณที่ใช้แท็ก Canonical META เพื่อชี้ไปที่การแสดงที่แท้จริง

• http://www.somesite.com/subdirectory/ - เป็นสิ่งที่ควรค่าแก่การสนับสนุนเครื่องหมายสแลชต่อท้ายบน URL ใด ๆ แต่ใช้แท็ก Canonical META (ไม่เปลี่ยนเส้นทางเนื่องจากนี่คือการชะลอตัวที่ไม่จำเป็น) เพื่อชี้ไปยัง URL ที่ถูกต้อง

• http://www.somesite.com/subdirectory/index.htmและhttp://www.somesite.com/subdirectory/some-relevant-keywords.htm- ขีด จำกัด ส่วนขยายสามตัวอักษรใช้ไม่ได้กับ HTTP (เฉพาะ FileSystem / OS) เพื่อให้ลูกค้าสามารถบันทึกสิ่งนี้เป็น index.html หรือ aa หากพวกเขาต้องการในขณะที่ยังสามารถเข้าถึงได้

• http://www.somesite.com/subdirectory/index.html - หากคุณให้บริการ. atom, .xml หรือรุ่นที่คล้ายกันคุณควรเคารพรุ่น. html (และลิงก์ตามปกติผ่านลิงก์แท็กในเวอร์ชันที่เจรจาต่อรองอัตโนมัติ) - ใช้ส่วนหัวเนื้อหา HTTP ที่ตั้งตำแหน่งเพื่อชี้ เป็นเวอร์ชันการเจรจาต่อรองอัตโนมัติ - โปรดจำไว้ว่าคุณยังสามารถใช้หลายภาษา (.en, .es, etc ... ) หรือชุดอักขระหลายชุด (.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 ที่จะต้องหลีกเลี่ยง (ลองรับไม่รู้หนังสือคอมพิวเตอร์คนที่จะพิมพ์หนึ่งของ ผู้ที่อยู่ใน)

ฉันจะบอกว่าไม่รวมนามสกุลไฟล์หากซอฟต์แวร์ที่คุณใช้อยู่อนุญาตให้คุณข้ามได้ ดังนั้นจากรายการตัวอย่างการตั้งค่าของฉันจะเป็น:

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

เบราว์เซอร์ไม่สนใจว่าบางอย่างเป็นไดเรกทอรีหรือไม่อยู่ในไซต์หรือไม่ว่าจะเป็นไฟล์ HTML, ไฟล์. asp หรืออะไรก็ตามพวกเขาเพียงแค่ร้องขอ HTTP และรับการตอบกลับ HTTP ดังนั้นหากส่วนขยายฟุ่มเฟือยให้ลดลง

สิ่งนี้ยังมีประโยชน์เพิ่มเติมในการทำให้ URL ของคุณกระชับยิ่งขึ้น (และง่ายต่อการอ่านทางโทรศัพท์ - "ตัวอย่างผลิตภัณฑ์ดอทคอมสแลช" มีเสียงที่ดีกว่า "ตัวอย่างผลิตภัณฑ์ดอทคอมสแลช dot htm l") และทำให้ง่ายขึ้น เพื่อเปลี่ยนเทคโนโลยีในอนาคต (เนื่องจากไม่จำเป็นต้องเปลี่ยน URL)

ปยูริไม่เปลี่ยน (ไปที่หัวข้อ "ฉันควรทำอย่างไรดีการออกแบบ URI")

มันต้องการที่จะมีนามสกุลไฟล์หรือไม่?

ไม่มีสิ่งใดใน RFCs ที่จะบังคับให้มีนามสกุลไฟล์และไม่มีสิ่งใดที่คุณต้องการปล่อยทิ้งไว้ มันเป็นทางเลือกที่คุณทำ

เป็นไปตาม HTTP URI ไม่จำเป็นต้องมีนามสกุลไฟล์เพื่ออะไร มีชุดส่วนหัว HTTP ที่หลากหลาย (โดยเฉพาะอย่างยิ่งประเภท MIME) เพื่อจัดการทุกอย่างที่นามสกุลไฟล์จะถูกใช้เป็นอย่างอื่น

เบราว์เซอร์ส่วนใหญ่ในปัจจุบันทำในความเป็นจริงขึ้นอยู่กับการรวมกันของชนิด MIME, ส่วนขยาย, และไบนารี 'ลายนิ้วมือ'ของไบต์แรกเพื่อกำหนดประเภทเนื้อหา บางครั้งสิ่งนี้สามารถให้ผลลัพธ์ที่น่าประหลาดใจดังนั้นเราจึงจำเป็นต้องให้ผู้ดูแลเว็บกำหนดส่วนหัวที่เหมาะสม (และอาจปิดการใช้งานการดมกลิ่นประเภทเนื้อหาหากเรา 101% แน่ใจว่าส่วนหัวของเรานั้นถูกต้อง)

มีสถานการณ์หนึ่งที่นามสกุลไฟล์มีประโยชน์คือ:หากผู้ใช้ปลายทางบันทึกเนื้อหาจากเว็บไซต์ของคุณไปยังเครื่องคอมพิวเตอร์เพื่อใช้ในภายหลัง ในทางทฤษฎีเบราว์เซอร์ 'สมาร์ท' ควรตรวจสอบให้แน่ใจว่าเนื้อหาที่บันทึกไว้ใช้งานได้กับคอมพิวเตอร์ในท้องถิ่น แต่ในทางปฏิบัติคุณสามารถช่วยทุกคนได้โดยการแสดงเนื้อหาด้วยส่วนขยายมาตรฐานอุตสาหกรรมเช่น. jpg, .mp4, .css เป็นต้นจากประสบการณ์ของฉันเบราว์เซอร์ทุกตัวจัดการกับ HTML อย่างถูกต้อง คุณไม่จำเป็นต้องเพิ่มนามสกุล. htm / .html ใน HTML ด้วยตัวคุณเองเบราว์เซอร์จะจัดการประเภทเนื้อหาเฉพาะนี้อย่างถูกต้อง

ความปลอดภัย:หนึ่งอาจยืนยันว่ามีประโยชน์ด้านความปลอดภัยในการซ่อนแพลตฟอร์มที่คุณใช้ (.php / .asp ฯลฯ ) นั่นเป็นเรื่องจริง ในทางปฏิบัติฉันคิดว่าแฮ็กเกอร์ที่ดีจะค้นพบสิ่งนี้ในทันทีดังนั้นฉันจึงไม่คิดว่าการซ่อนส่วนขยายเหล่านี้เพื่อความปลอดภัยเพียงอย่างเดียวนั้นคุ้มค่ากับปัญหา

ข้อพิจารณาพิเศษ:หากคุณวางแผนที่จะใช้ CDN ในอนาคตและ CDN ของคุณเป็นประเภท "พุช" (เนื้อหาถูกอัปโหลดไปยัง CDN ล่วงหน้า fx ผ่าน SFTP) คุณอาจต้องการเก็บนามสกุลไฟล์ไว้ ระบบบุคคลที่สามส่วนใหญ่ดูที่นามสกุลไฟล์เพื่อค้นหาประเภท MIME ที่จะแสดงเนื้อหาด้วย

ทางเลือกส่วนตัวของฉันกลายเป็น:

• เมื่อ HTML ถูกสร้างขึ้นโดย webapp ของฉันฉันจะไม่เพิ่มนามสกุล 'ปลอม' .html เพื่อเลียนแบบไดเรกทอรีและโครงสร้างไฟล์ที่ไม่มีอยู่จริง ฉันทำให้ URL เป็นมาตรฐานและฉันทำให้รูปแบบ URL เป็นมาตรฐานที่ใช้เพื่อการทำ SEO โดยส่วนตัวแล้วฉันชอบที่จะมีเครื่องหมายสแลชที่ท้ายสุดของ URL เช่นhttp://example.org/first/second/แต่นั่นเป็นเรื่องของรสนิยม

• เมื่อเรากำลังพูดถึงไฟล์จริงที่อัปโหลดไปยังฮาร์ดดิสที่ไหนสักแห่งฉันจะเก็บนามสกุลไฟล์ 'ปกติ' ไว้สำหรับประเภทนั้น ดังนั้น .css / .js / .exe / .mp4 เป็นต้นจึงถูกนำไปใช้กับเนื้อหาประเภทนี้

ฉันทำการทดลองอย่างไม่เป็นทางการเล็กน้อยและสิ่งที่ฉันค้นพบทำให้ฉันประหลาดใจ แต่ก็มีเหตุผลบางอย่าง

จากจุดแสดงเนื้อหาที่จัดส่งไปยังผู้ใช้รวมถึงการคัดลอกหน้าจอกฎชนิดเนื้อหาจะควบคุมวันที่

อย่างไรก็ตามการมีหรือไม่มีส่วนขยายรวมถึงส่วนขยายนั้นดูเหมือนจะแกว่งไปมาในเครื่องมือค้นหา

เมื่อฉันละเว้นส่วนขยายใด ๆ เลยฉันได้รับความนิยมค่อนข้างน้อย - ราวกับว่า URL นั้นเป็นที่ตั้งหรือเนื้อหาแบบไดนามิกดังนั้นจึงไม่คุ้มกับการทำดัชนีมากนัก

เมื่อฉันเปลี่ยนลิงก์เดียวกันเพื่อใช้ส่วนขยาย. xml เนื่องจากหน้าเว็บถูกสร้างขึ้นจริงโดย XSLT (ทางฝั่งเซิร์ฟเวอร์) การทำดัชนีลดลงจริงมากขึ้นอีก - บางทีอาจเป็นเพราะมันคิดว่าเป็นเพียงข้อมูลหรือผลลัพธ์ของคำขอบางโปรแกรม .

เมื่อฉันเปลี่ยนลิงก์เดียวกันเพื่อใช้. html เครื่องมือค้นหาจะเปลี่ยนไปตามไซต์

ในขณะนี้ไซต์ของฉันจัดการทั้งสามอย่างโปร่งใส แต่เมื่อมีลิงก์ที่สามารถคลิกได้ฉันจะส่งคืนเวอร์ชัน. html ของ URL

ฉันต้องการคิดว่าเสิร์ชเอ็นจิ้นฉลาดขึ้นเล็กน้อยหรือมีอคติน้อยลง แต่นั่นคือสิ่งที่ฉันสังเกตเห็นเกิดขึ้นกับหน้าของฉัน

ไม่คุณไม่ควรใช้ส่วนขยายไฟล์สำหรับประเภทหน้าเว็บปกติเว้นแต่คุณจะต้องการใช้ด้วยเหตุผลด้านเทคนิค ปรับปรุงประสบการณ์การใช้งานของผู้ใช้ได้อย่างไร มันพิมพ์ได้มากกว่า แต่มันก็ไม่ได้บอกว่ามีประโยชน์ พวกเขาจะทำอะไรได้บ้างเมื่อรู้ว่าเว็บไซต์ของคุณเป็น PHP, ASP และอื่น ๆ URL นั้นง่ายกว่าสะอาดกว่าใช้งานได้มากกว่าและน่าจดจำมากกว่าโดยไม่มีนามสกุลไฟล์

ดูว่า URL นั้นไม่มีชื่อไฟล์หรือไม่ก็ตามโดยปกติถือว่าเป็นไดเรกทอรี

ฉันไม่คิดว่าฉันเห็นด้วย โดยทั่วไปแล้ว URL เป็นไดเรกทอรีเฉพาะเมื่อมีเครื่องหมายสแลชต่อท้าย หากไม่มีเครื่องหมายทับต่อท้ายจะถือว่าเป็นไฟล์

คุณควรเพิ่มนามสกุลไฟล์เท่านั้นหากเนื้อหาเบื้องหลัง URI เป็นไฟล์จริง แต่ถึงอย่างนั้นคุณก็สามารถดรอปได้ถ้ามีเพียงตัวแทนเดียว (JPG, PDF, ... )

หากมีการรับรองหลายวิธี HTTP จะเป็นรูปแบบการเจรจาผ่านAcceptส่วนหัว แต่ถ้าคุณต้องการให้ผู้ใช้ของคุณพูดในนั้นคุณอาจต้องการมีส่วนขยายเพื่อให้พวกเขาสามารถเลือกการแสดงที่ต้องการ (JPG, PNG, ... ) โดยการร้องขอ URI อื่นหรืออย่างอื่น