Haruskah saya menggunakan ekstensi file atau tidak?


26

Saya selalu bertanya-tanya tentang hal ini dan tidak pernah menemukan solusi yang baik.

Tetapi pertanyaan ini mengingatkan saya akan hal itu.

Ketika saya memiliki URL di situs web saya, URL itu dapat ditampilkan dan diakses dengan salah satu cara berikut:

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

dll ...

Sekarang, saya bisa memahami manfaat menambahkan kata kunci di URL. Bahkan panduan SEO paling dasar akan menyebutkan untuk melakukan hal itu. ... tetapi demi kewarasan, kejelasan, kemudahan membaca, kemudahan penggunaan, dan sebagainya, termasuk kepatuhan web ...

Apakah lebih disukai memiliki ekstensi file atau tidak?

Sungguh, jauh di lubuk hati logika saya mengatakan: ya, seharusnya begitu. Alasannya adalah ini berasal dari masa lalu ketika internet sebagian besar adalah USENET, FIDONET, FTP dan GOPHER.

Lihat, jika URL tidak memiliki nama file , maka biasanya dianggap sebagai direktori . Di sinilah index.htm muncul, karena ini secara default mendaftar direktori jika tidak ada file indeks yang ditemukan. Namun, tak lama kemudian, pemrogram web mulai menimpanya dan menggunakan index.htm untuk benar-benar menyajikan konten direktori web itu sebagai halaman . Perbedaan utama, adalah bahasa markup ditambahkan, dan ini diuraikan dalam browser. Dengan bahasa markup ini, Content-Type:text/html;tag di header respons menjadi indikator untuk jenis file apa itu untuk file apa pun . HTML tampaknya menjadi satu-satunya "tipe file" yang tidak memiliki ekstensi nama secara konsisten, kecuali ketika mereka disimpan.

Sayangnya, setelah halaman web menjadi hal utama, itu menjadi kesalahan keamanan untuk benar-benar menampilkan konten direktori, jadi semuanya tetap tersembunyi dengan hanya konten URL aktual yang ditampilkan.

Belum lagi perang penamaan file lintas-platform .. berbasis windows membutuhkan ekstensi 3 digit atau kurang, dan unix / mac dapat memiliki lebih banyak. Jadi haruskah itu .HTMatau .HTMLatau NONEdan biarkan platform memutuskan?

Jadi intinya, saya kira apa yang saya coba cari tahu di luar SEO dan lebih banyak berurusan dengan estetika dan kepatuhan web.


Bagaimana Anda mengatur ini? Di file .htaccess Anda? Maksud saya, ubah path untuk file .html agar terlihat seperti contoh pertama?
Zolomon

1
@ zolomon Anda dapat melakukannya, atau lebih baik lagi menggunakan parser URI dinamis seperti cara Wordpress lakukan dan mengarahkan kembali *.*ke itu.
Talvi Watia

Jawaban:


20

Gunakan ekstensi. Di mana terdapat lebih dari satu representasi atau di mana perangkat lunak klien benar-benar bodoh dan menolak untuk menerima Tipe-Konten saja (QuickTime, RealPlayer, Outlook, dll. Saya melihat Anda):

  • http://www.somesite.com/subdirectory - ini bisa menjadi versi negosiasi otomatis Anda yang menggunakan tag META Canonical untuk menunjuk ke representasi aktual

  • http://www.somesite.com/subdirectory/ - selalu layak untuk mendukung garis miring pada URL apa pun tetapi menggunakan tag META Canonical (bukan arahan ulang karena ini adalah perlambatan yang tidak perlu) untuk menunjuk ke URL yang benar

  • http://www.somesite.com/subdirectory/index.htmdan http://www.somesite.com/subdirectory/some-relevant-keywords.htm- batas ekstensi tiga karakter tidak berlaku untuk HTTP (hanya FileSystem / OS yang mendasari) sehingga klien dapat menyimpan ini sebagai index.html atau aa jika mereka mau, sementara masih dapat mengaksesnya

  • http://www.somesite.com/subdirectory/index.html - jika Anda menyajikan .atom, .xml, atau versi serupa maka masuk akal juga untuk menghormati versi .html (dan ditautkan secara kanonik melalui tag LINK pada versi yang dinegosiasikan secara otomatis) - gunakan header Lokasi Konten HTTP untuk menunjuk ke versi auto-negotiation - ingat Anda juga bisa menggunakan multi-bahasa (.en, .es, dll ...) atau multi-charset (.utf8, .utf16, dll ...)

  • http://www.somesite.com/subdirectory/index.phpdan http://www.somesite.com/subdirectory/index.asp- kecuali Anda menyajikan kode sumber maka ini tidak masuk akal untuk mendukung

  • http://www.somesite.com/subdirectory/some-relevant-keywords - SEO adalah seni yang terus berubah dan jika ini bekerja untuk Anda maka bagus

  • http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords, http://www.somesite.com/subdirectory/?page=some-relevant-keywordsdan http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords- jika ada banyak cara untuk memanipulasi konten maka ini bagus - tetapi biasanya halaman layak URL mereka sendiri bukan string kueri dan jenis URL ini harus dihindari (coba buat seseorang komputer buta huruf untuk mengetik salah satu dari yang ada di)


1
Ekstensi multibahasa? Itulah pertama kali saya melihat sesuatu seperti itu. Saya ingat pernah membaca bahwa Google lebih suka folder /es/subdirectory/index.htmldaripada bahkan lebih dari subdomain http://es.example.com/subdirectory/index.html. Apakah Anda memiliki informasi tentang seberapa baik ekstensi .es didukung oleh mesin pencari? Karena saya akan senang menggunakannya. (Juga bisakah Anda menggabungkannya? Seperti /index.utf16.es?)
Timo Huovinen

13

Saya akan mengatakan jangan sertakan ekstensi file jika perangkat lunak yang Anda gunakan memungkinkan Anda untuk menghilangkannya. Jadi dari daftar contoh Anda, preferensi saya adalah:

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

Browser tidak peduli apakah sesuatu itu direktori atau tidak di situs, atau apakah itu file HTML, file .asp atau apa pun - mereka hanya membuat permintaan HTTP dan mendapatkan respons HTTP. Jadi, jika ekstensi itu berlebihan, jatuhkan.

Ini juga memiliki manfaat tambahan untuk membuat URL Anda lebih ringkas (dan lebih mudah dibaca di telepon - "contoh produk dot com slash" jauh lebih bagus daripada "contoh produk dot com slash dot htm l"), dan membuatnya lebih mudah untuk beralih teknologi di masa mendatang (karena tidak diperlukan perubahan URL).


4
Saya bergoyang ke arah yang satu ini sebagai praktik terbaik, karena alasan SEO dan astetik.
Talvi Watia

Ya, browser tidak peduli, tetapi server peduli apakah itu asp, aspx, atau jenis lain yang akan membutuhkan pemrosesan tambahan pada server web.
awe

Meninjau kembali ini setelah bertahun-tahun, praktik terbaik tampaknya telah menang. Namun saya masih bertanya-tanya apa yang akan terjadi ketika logika web-crawler akhirnya belajar untuk mengurai operan. misalnya some-relevant-keywordsmemiliki kesetaraan yang (some) (!exclude->relevant) (!exclude->keywords)menyebabkan setiap ahli SEO untuk mengubahnya tiba-tiba untuk some+relevant+keywordsmenghancurkan estetika dan keterbacaan menggunakan tanda hubung sebagai karakter pemisah. Penyebab root: /?query=some-relevant-keywordssudah merupakan pengecualian literal.
Talvi Watia


8

Apakah lebih disukai memiliki ekstensi file atau tidak?

Tidak ada dalam RFC yang diamanatkan memiliki ekstensi file, juga tidak ada yang mengharuskan Anda untuk meninggalkannya. Itu pilihan yang Anda buat.

HTTP URI yang sesuai tidak perlu ekstensi file untuk apa pun. Ada sekumpulan header HTTP yang kaya (terutama tipe MIME) untuk menangani semua yang digunakan untuk ekstensi file.

Yang mengatakan, sebagian besar browser saat ini sebenarnya mengandalkan kombinasi tipe MIME, ekstensi, dan 'sidik jari' biner dari byte pertama untuk menentukan tipe konten. Ini kadang-kadang dapat memberikan hasil yang mengejutkan , dan penting bagi kita webmaster untuk menetapkan header yang tepat (dan mungkin menonaktifkan sniffing jenis konten jika kita 101% yakin header kita benar).

Ada satu situasi di mana ekstensi file berguna: Jika pengguna akhir menyimpan konten dari situs Anda ke komputer lokalnya untuk digunakan nanti. Secara teoritis peramban 'pintar' harus memastikan bahwa konten yang disimpan berfungsi untuk jenis komputer lokal; tetapi dalam praktiknya Anda dapat membantu semua orang dengan menyajikan konten dengan ekstensi standar industri seperti .jpg, .mp4, .css, dll. Dalam pengalaman saya, semua browser menangani jenis HTML dengan benar. Anda tidak perlu menambahkan ekstensi .htm / .html pada HTML sendiri, peramban akan menangani jenis konten khusus ini dengan benar.

Keamanan: Orang bisa berpendapat bahwa ada manfaat keamanan dalam menyembunyikan platform mana yang Anda gunakan (.php / .asp dll). Itu benar. Dalam praktiknya saya pikir setiap peretas yang baik akan segera mengetahui hal ini, jadi saya tidak berpikir menyembunyikan ekstensi ini untuk keamanan saja sepadan dengan masalahnya.

Pertimbangan khusus: Jika Anda berencana untuk menggunakan CDN di masa depan, dan CDN Anda adalah tipe "push" (konten diunggah ke CDN sebelumnya fx melalui SFTP), maka Anda mungkin ingin menyimpan ekstensi file. Sebagian besar sistem pihak ke-3 melihat ekstensi file untuk mengetahui tipe MIME mana yang digunakan untuk menyajikan konten.

Pilihan pribadi saya telah menjadi:

  • Ketika HTML dihasilkan secara dinamis oleh aplikasi web saya, saya tidak menambahkan ekstensi .html 'palsu' untuk meniru direktori dan struktur file yang sebenarnya tidak ada di sana. Saya menormalkan URL dan saya membakukan format URL yang digunakan untuk alasan SEO. Saya pribadi lebih suka memiliki garis miring pada daun terakhir URL, yaitu http://example.org/first/second/, tapi itu masalah selera.

  • Ketika kita sebenarnya berbicara tentang file aktual yang diunggah ke harddisk di suatu tempat, maka saya menyimpan ekstensi file 'normal' untuk jenisnya. Jadi .css / .js / .exe / .mp4 dll digunakan untuk jenis konten ini.


Satu hal, menambah .htmmeniru direktori (agak override index.htm) benar-benar tidak "palsu" karena Anda menyajikan konten HTML. Itu akan palsu jika kontennya bukan HTML.
Talvi Watia

2

Saya telah melakukan sedikit eksperimen informal, dan apa yang saya temukan mengejutkan saya tetapi masuk akal.

Dari sudut pandang konten yang disampaikan kepada pengguna, serta pengikisan layar, Tipe-Konten mengatur hari itu.

Namun, ada atau tidaknya ekstensi, serta apa ekstensi itu, tampaknya mempengaruhi kunjungan mesin pencari.

Ketika saya menghilangkan ekstensi sama sekali, saya mendapat hit yang relatif sedikit - seolah-olah URL adalah lokasi atau konten dinamis dan oleh karena itu tidak terlalu layak untuk diindeks.

Ketika saya mengubah tautan yang sama untuk menggunakan ekstensi .xml, karena halaman-halaman itu sebenarnya dihasilkan oleh XSLT (di sisi server), pengindeksan sebenarnya turun lebih jauh - mungkin karena ia mengira itu hanya data atau hasil dari beberapa permintaan terprogram .

Ketika saya mengubah tautan yang sama untuk menggunakan .html, mesin pencari menjadi liar dengan situs tersebut.

Saat ini, situs saya menangani ketiganya secara transparan, tetapi ketika menyediakan tautan yang dapat diklik, saya mengembalikan versi .html dari URL.

Saya ingin berpikir mesin pencari sedikit lebih pintar, atau sedikit kurang bias, tetapi itulah yang saya amati terjadi pada halaman saya.


tidak akan memiliki beberapa URI untuk sumber daya yang sama menyebabkan halaman dupe?
Talvi Watia

Secara teknis, saya kira begitu, dan saya menduga hal yang tepat untuk dilakukan adalah meminta orang lain melakukan redirect.
Walt Stoneburner

ini memang sangat mengejutkan! dapatkah Anda memberikan informasi latar belakang lagi, seperti mesin pencari mana, sejauh mana Anda memperhatikan perubahan, dll.?
damusnet

Saya telah mengalami penurunan besar dalam lalu lintas dan sementara saya masih tidak yakin, saya pikir bertepatan dengan saat saya beralih dari rel kanonik dengan .html ke yang tanpa.
Dan

Maaf untuk membalas begitu terlambat, tapi saya ingat beberapa waktu lalu Matt Cutts menyebutkan untuk menggunakan .html jika memungkinkan. ( lebih lanjut di sini ). Agak masuk akal bahwa mesin pencari sensitif terhadap ekstensi, bayangkan saja melihathttp://example.com/index.exe
Timo Huovinen

2

Tidak, Anda tidak boleh menggunakan ekstensi file untuk tipe halaman normal kecuali Anda benar-benar membutuhkannya karena alasan teknis. Bagaimana cara meningkatkan pengalaman pengguna? Ini lebih banyak untuk diketik, namun memberi tahu mereka tidak ada yang berguna. Apa yang dapat mereka lakukan mengetahui bahwa situs Anda adalah PHP, ASP, dll? URL lebih sederhana, lebih bersih, lebih bermanfaat, dan lebih mudah diingat tanpa ekstensi file.

Lihat, jika URL tidak memiliki nama file, maka biasanya dianggap sebagai direktori.

Saya pikir saya tidak setuju. Secara umum, URL adalah direktori hanya jika memiliki garis miring. Tanpa garis miring, itu dianggap file.


Pengalaman pengguna: jika ekstensi file .phpatau .aspjika pengguna menyimpannya, itu akan menjadi tipe file yang tidak dikenal dan komputer yang buta huruf mungkin tidak tahu cara membukanya kembali. Tanpa filetype, browser akan menambahkannya, tetapi mungkin ini menghambat beberapa mesin pencari?
Talvi Watia

0

Anda hanya perlu menambahkan ekstensi file, jika konten di balik URI sebenarnya adalah file. Tetapi bahkan kemudian Anda bisa menjatuhkannya, jika hanya ada satu representasi darinya (JPG, PDF, ...).

Jika ada beberapa representasi, cara HTTP akan meminta format dinegosiasikan melalui Acceptheader. Tetapi jika Anda ingin pengguna Anda memiliki suara di dalamnya, Anda mungkin ingin memiliki ekstensi sehingga mereka dapat memilih representasi yang mereka inginkan (JPG, PNG, ...) dengan meminta URI yang satu atau yang lain.


Ini lebih dari sekadar gambar atau sumber daya lainnya. Untuk sumber daya non-html, saya akan selalu menggunakan ekstensi file. Sebagian besar browser tidak akan tahu apa yang harus dilakukan jika ditinggalkan jika pengguna melakukan "save-as". Tentu Anda dapat menambahkan filetype di header, tetapi begitu komputer klien yang disimpan tidak akan tahu cara membuka kembali file.
Talvi Watia
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.