Dovrei usare un'estensione di file o no?

Mi sono sempre chiesto questo e non ho mai trovato una buona soluzione.

Ma questa domanda me lo ha ricordato.

Quando ho un URL sul mio sito Web, è possibile visualizzarlo e accedervi in ​​uno dei seguenti modi:

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

eccetera...

Ora capisco i vantaggi dell'aggiunta di parole chiave nell'URL. Anche la guida SEO più semplice menzionerà per fare proprio questo. ... ma per ragioni di sanità mentale, chiarezza, facilità di lettura, facilità d'uso e così via, inclusa la conformità web ...

Si preferisce avere un'estensione di file o no?

Davvero, in fondo la mia logica mi dice: sì, dovrebbe. Il motivo è che ciò risale ai tempi del passato in cui Internet era principalmente USENET, FIDONET, FTP e GOPHER.

Vedi, se un URL non ha un nome file , normalmente viene considerato una directory . È qui che è nato index.htm, perché per impostazione predefinita elenca la directory se non viene trovato alcun file indice. Tuttavia, abbastanza presto, i programmatori web hanno iniziato a sovrascrivere questo e usando index.htm per servire effettivamente il contenuto di quella directory web come pagina . La differenza principale, è stato aggiunto il linguaggio di markup e questo è stato analizzato nel browser. Con questo linguaggio di markup, il Content-Type:text/html;tag nell'intestazione della risposta è diventato l'indicatore del tipo di file che era per qualsiasi file . L'HTML sembra essere l'unico "tipo di file" che non ha estensioni con nome coerente, tranne quando vengono salvate.

Sfortunatamente, una volta che le pagine Web sono diventate la cosa principale, è diventato un errore di sicurezza mostrare effettivamente il contenuto della directory, quindi tutto è rimasto nascosto solo con il contenuto dell'URL effettivo visualizzato.

Per non parlare delle guerre di denominazione dei file multipiattaforma. Windows based richiede un'estensione di 3 o meno cifre e unix / mac può avere di più. Quindi dovrebbe essere .HTMo .HTMLo NONEe lasciare che la piattaforma decida?

Quindi, in sostanza, immagino che ciò che sto cercando di capire va oltre la SEO e si occupa di più dell'estetica e della conformità web.

Usa un'estensione. Dove c'è più di una rappresentazione o in cui il software client è assolutamente stupido e si rifiuta di accettare il solo Content-Type (QuickTime, RealPlayer, Outlook, ecc. Ti sto guardando):

• http://www.somesite.com/subdirectory - questa può essere la tua versione di negoziazione automatica che utilizza tag META Canonical per indicare la rappresentazione effettiva

• http://www.somesite.com/subdirectory/ - vale sempre la pena supportare le barre finali su qualsiasi URL ma utilizzando i tag META Canonical (non reindirizzamenti in quanto si tratta di un rallentamento inutile) per puntare all'URL corretto

• http://www.somesite.com/subdirectory/index.htme http://www.somesite.com/subdirectory/some-relevant-keywords.htm- il limite di estensione di tre caratteri non si applica a HTTP (solo il FileSystem / OS sottostante), quindi il client può salvarlo come index.html o aa se lo desidera, pur potendo accedervi

• http://www.somesite.com/subdirectory/index.html - se servi un .atom, un .xml o una versione simile, ha senso onorare anche la versione .html (e collegarti canonicamente tramite tag LINK sulla versione negoziata automaticamente) - usa le intestazioni HTTP Content-Location per puntare alla versione della negoziazione automatica - ricorda che puoi anche passare a più lingue (.en, .es, ecc ...) o multi-charset (.utf8, .utf16, ecc ...)

• http://www.somesite.com/subdirectory/index.phpe http://www.somesite.com/subdirectory/index.asp- a meno che tu non stia fornendo il codice sorgente, questi non hanno senso supportarli

• http://www.somesite.com/subdirectory/some-relevant-keywords - SEO è un'arte in continua evoluzione e se funziona per te, allora è fantastico

• http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords, http://www.somesite.com/subdirectory/?page=some-relevant-keywordsE http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords- se ci sono un numero infinito di modi per manipolare il contenuto allora questo è grande - ma di solito pagine meritano il loro proprio URL non una stringa di query e questo tipo di URL sono da evitare (provare a ottenere analfabeti del computer a qualcuno di scrivere una delle quelli in)

Direi di non includere l'estensione del file se il software che stai utilizzando ti consente di ometterlo. Quindi dal tuo elenco di esempi, la mia preferenza sarebbe:

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

Ai browser non importa se qualcosa è una directory o meno sul sito, o se si tratta di un file HTML, un file .asp o altro - semplicemente inviano una richiesta HTTP e ottengono una risposta HTTP. Quindi, se l'estensione è superflua, rilasciarla.

Ciò ha anche il vantaggio di rendere gli URL più concisi (e più facili da leggere al telefono - "esempio di prodotti slash dot com" è molto più bello di "esempio di prodotti slash dot com htm l"), e di renderlo più facile per cambiare tecnologia in futuro (poiché non sarebbe richiesto alcun cambio di URL).

Gli URI interessanti non cambiano . (Vai alla sezione intitolata "Quindi cosa devo fare? Progettazione di URI")

Si preferisce avere un'estensione di file o no?

Nelle RFC non c'è nulla che imponga di avere estensioni di file, né c'è nulla che richieda di lasciarle fuori. È una scelta che fai.

Gli URI HTTP conformi non necessitano di estensioni di file per nulla. Esiste un ricco set di intestazioni HTTP (in particolare il tipo MIME) per gestire tutto ciò per cui le estensioni di file sarebbero altrimenti utilizzate.

Detto questo, la maggior parte dei browser oggi si basano infatti su una combinazione di tipo MIME, estensione e "impronta digitale" binaria dei primi byte per determinare il tipo di contenuto. Questo a volte può dare risultati sorprendenti , quindi è importante che noi webmaster impostiamo le intestazioni giuste (e possibilmente disabilitiamo lo sniffing del tipo di contenuto se siamo sicuri al 101% che le nostre intestazioni siano corrette).

Esiste una situazione in cui le estensioni dei file sono utili: se l'utente finale salva il contenuto dal tuo sito sul suo computer locale per un uso successivo. Teoricamente un browser "intelligente" dovrebbe garantire che il contenuto salvato funzioni per il tipo di computer locale; ma in pratica puoi aiutare tutti offrendo contenuti con estensioni standard del settore come .jpg, .mp4, .css ecc. Nella mia esperienza, tutti i browser gestiscono correttamente il tipo HTML. Non è necessario aggiungere un'estensione .htm / .html su HTML da soli, il browser gestirà correttamente questo specifico tipo di contenuto.

Sicurezza: si potrebbe sostenere che ci sia un vantaggio in termini di sicurezza nel nascondere quale piattaforma si sta utilizzando (.php / .asp ecc). È vero. In pratica, penso che qualsiasi buon hacker lo scoprirà subito, quindi non credo che nascondere queste estensioni per la sola sicurezza valga la pena.

Considerazione speciale: se prevedi di utilizzare un CDN in futuro e il tuo CDN è del tipo "push" (il contenuto viene precedentemente caricato sul CDN fx tramite SFTP), potresti voler mantenere le estensioni dei file. La maggior parte dei sistemi di terze parti esamina le estensioni dei file per scoprire con quale tipo MIME servire il contenuto.

La mia scelta personale è diventata:

• Quando l'HTML viene generato dinamicamente dalla mia webapp, non aggiungo un'estensione .html "falsa" per imitare una directory e una struttura di file che in realtà non sono lì. Normalizzo gli URL e standardizzo il formato dell'URL utilizzato per motivi di SEO. Personalmente preferisco avere una barra finale sull'ultima foglia dell'URL, cioè http://example.org/first/second/, ma è una questione di gusti.

• Quando stiamo infatti parlando di file effettivi che vengono caricati su un disco rigido da qualche parte, allora mantengo l'estensione del file "normale" per il tipo. Quindi .css / .js / .exe / .mp4 ecc. Sono in uso per questo tipo di contenuti.

Ho fatto una piccola sperimentazione informale e quello che ho scoperto mi ha sorpreso ma ha un senso.

Dal punto di vista del contenuto consegnato all'utente, oltre allo scraping dello schermo, il tipo di contenuto regola il giorno.

Tuttavia, la presenza o l'assenza di un'estensione, così come quella estensione, sembra influenzare le visite dei motori di ricerca.

Quando ho omesso qualsiasi estensione, ho ottenuto relativamente pochi risultati, come se l'URL fosse una posizione o un contenuto dinamico e quindi non valesse la pena indicizzarlo molto.

Quando ho modificato gli stessi collegamenti per utilizzare un'estensione .xml, poiché le pagine sono state effettivamente generate da XSLT (sul lato server), l'indicizzazione è effettivamente diminuita ulteriormente, forse perché pensava che fossero solo dati o il risultato di una richiesta programmatica .

Quando ho cambiato gli stessi link per utilizzare .html, i motori di ricerca sono diventati selvaggi con il sito.

Al momento, il mio sito gestisce tutti e tre in modo trasparente, ma quando fornisce un link cliccabile, restituisco la versione .html dell'URL.

Mi piacerebbe pensare che i motori di ricerca fossero un po 'più intelligenti o un po' meno distorti, ma è quello che ho osservato accadere con le mie pagine.

No, non dovresti usare un'estensione di file per normali tipi di pagina a meno che tu non ne abbia assolutamente bisogno per motivi tecnici. Come migliora l'esperienza dell'utente? È più da digitare, ma non dice loro nulla di utile. Cosa potranno fare sapendo che il tuo sito è PHP, ASP, ecc.? Un URL è più semplice, più pulito, più utilizzabile e più memorabile senza un'estensione di file.

Vedi, se un URL non ha un nome file, allora normalmente è considerato una directory.

Non credo di essere d'accordo. In genere, un URL è una directory solo quando presenta una barra finale. Senza una barra finale, è considerato un file.

È necessario aggiungere un'estensione di file solo se il contenuto dietro l'URI è in realtà un file. Ma anche allora potresti lasciarlo cadere, se c'è solo una sua rappresentazione (JPG, PDF, ...).

Se ci sono più rappresentazioni, il modo HTTP sarebbe di negoziare il formato tramite l' Acceptintestazione. Ma se vuoi che i tuoi utenti abbiano voce in capitolo, probabilmente vorrai avere un'estensione in modo che possano scegliere quale rappresentazione vogliono (JPG, PNG, ...) richiedendo l'uno o l'altro URI.