Soll ich eine Dateierweiterung verwenden oder nicht?


26

Ich habe mich immer darüber gewundert und nie eine gute Lösung gefunden.

Aber diese Frage erinnerte mich daran.

Wenn ich eine URL auf meiner Website habe, kann diese auf eine der folgenden Arten angezeigt und aufgerufen werden:

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

etc...

Jetzt kann ich die Vorzüge des Hinzufügens von Schlüsselwörtern in die URL verstehen. Selbst die grundlegendste SEO-Anleitung wird erwähnen, um genau das zu tun. ... aber aus Gründen der Vernunft, Klarheit, Lesbarkeit, Benutzerfreundlichkeit usw., einschließlich Web-Compliance ...

Wird eine Dateierweiterung bevorzugt oder nicht?

Im Grunde sagt mir meine Logik: Ja, das sollte es. Der Grund dafür ist, dass dies auf vergangene Zeiten zurückgeht, als das Internet hauptsächlich aus USENET, FIDONET, FTP und GOPHER bestand.

Wenn eine URL keinen Dateinamen hat , wird sie normalerweise als Verzeichnis betrachtet . Hier ist index.htm entstanden, da hier standardmäßig das Verzeichnis aufgelistet wird, wenn keine Indexdatei gefunden wird. Web-Programmierer begannen jedoch schon bald, dies zu überschreiben und index.htm zu verwenden, um den Inhalt dieses Web-Verzeichnisses tatsächlich als Seite bereitzustellen . Der Hauptunterschied war, dass die Auszeichnungssprache hinzugefügt und im Browser analysiert wurde. Bei dieser Auszeichnungssprache wurde das Content-Type:text/html;Tag im Antwortheader zum Indikator für den Dateityp einer Datei . HTML scheint der einzige "Dateityp" zu sein, der keine einheitlich benannten Erweiterungen hat, außer wenn sie gespeichert werden.

Als Webseiten zur Hauptsache wurden, wurde es leider zu einem Sicherheitsfehler, den Verzeichnisinhalt tatsächlich anzuzeigen, sodass alles verborgen blieb und nur der tatsächliche URL-Inhalt angezeigt wurde.

Ganz zu schweigen von den plattformübergreifenden File-Naming-Kriegen. Windows-basierte Programme benötigen eine Erweiterung mit 3 oder weniger Ziffern, und Unix / Mac kann mehr enthalten. Also soll es sein .HTModer .HTMLoder NONEund die Plattform entscheiden lassen?

Ich denke also, was ich herausfinden will, geht über SEO hinaus und beschäftigt sich mehr mit Ästhetik und Web-Compliance.


Wie würden Sie das einrichten? In Ihrer .htaccess-Datei? Ich meine, den Pfad für eine .html-Datei so ändern, dass sie wie das erste Beispiel aussieht?
Zolomon

1
@ zolomon Sie können das tun, oder besser noch einen dynamischen URI-Parser verwenden, wie es Wordpress tut und *.*zu diesem umleiten .
Talvi Watia

Antworten:


20

Verwenden Sie eine Erweiterung, bei der es mehr als eine Darstellung gibt oder bei der die Client-Software absolut dumm ist und den Inhaltstyp allein nicht akzeptiert (QuickTime, RealPlayer, Outlook usw., die ich gerade betrachte):

  • http://www.somesite.com/subdirectory - Dies kann Ihre Auto-Negotiation-Version sein, die Canonical META-Tags verwendet, um auf die tatsächliche Darstellung zu verweisen

  • http://www.somesite.com/subdirectory/ - Es lohnt sich immer, abschließende Schrägstriche auf einer URL zu unterstützen, aber Canonical META-Tags zu verwenden (keine Weiterleitungen, da dies eine unnötige Verlangsamung darstellt), um auf die richtige URL zu verweisen

  • http://www.somesite.com/subdirectory/index.htmund http://www.somesite.com/subdirectory/some-relevant-keywords.htm- die Beschränkung der Erweiterung auf drei Zeichen gilt nicht für HTTP (nur das zugrunde liegende Dateisystem / Betriebssystem), sodass der Client diese als index.html oder aa speichern kann, wenn er dies wünscht, während er weiterhin darauf zugreifen kann

  • http://www.somesite.com/subdirectory/index.html - Wenn Sie eine .atom-, eine .xml- oder eine ähnliche Version bereitstellen, ist es sinnvoll, auch die .html-Version zu berücksichtigen (und über LINK-Tags in der automatisch ausgehandelten Version kanonisch darauf zu verlinken). - Verwenden Sie HTTP Content-Location-Header, um darauf hinzuweisen zur Auto-Negotiation-Version - denken Sie daran, dass Sie auch mehrsprachig (.en, .es, etc ...) oder mehrsprachig (.utf8, .utf16, etc ...) arbeiten können.

  • http://www.somesite.com/subdirectory/index.phpund http://www.somesite.com/subdirectory/index.asp- wenn Sie den Quellcode nicht bereitstellen, ist es nicht sinnvoll, diesen zu unterstützen

  • http://www.somesite.com/subdirectory/some-relevant-keywords - SEO ist eine sich ständig verändernde Kunst und wenn dies für Sie funktioniert, dann großartig

  • http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords, http://www.somesite.com/subdirectory/?page=some-relevant-keywordsund http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords- wenn es unendlich viele Möglichkeiten gibt, den Inhalt zu manipulieren, dann ist das großartig - aber normalerweise verdienen Seiten ihre eigene URL, keine Abfragezeichenfolge, und diese Art von URLs sind zu vermeiden (versuchen Sie, einen Computer-Analphabeten dazu zu bringen, eine der URLs einzugeben) jene in)


1
Mehrsprachige Erweiterung? Das ist das erste Mal, dass ich so etwas sehe. Ich erinnere mich, dass Google Ordner /es/subdirectory/index.htmlsogar mehr bevorzugt als Subdomains http://es.example.com/subdirectory/index.html. Haben Sie Informationen darüber, wie gut die .es-Erweiterung von Suchmaschinen unterstützt wird? Weil ich es lieben würde, es zu benutzen. (Könnten Sie sie auch kombinieren? Wie /index.utf16.es?)
Timo Huovinen

13

Ich würde sagen , dass Sie die Dateierweiterung nicht einschließen, wenn die von Ihnen verwendete Software es Ihnen erlaubt, sie wegzulassen. Aus Ihrer Liste von Beispielen würde meine Präferenz also lauten:

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

Den Browsern ist es egal, ob sich auf der Site ein Verzeichnis befindet oder nicht, oder ob es sich um eine HTML-Datei, eine ASP-Datei oder was auch immer handelt - sie stellen einfach eine HTTP-Anfrage und erhalten eine HTTP-Antwort. Wenn die Erweiterung überflüssig ist, lassen Sie sie fallen.

Dies hat auch den zusätzlichen Vorteil, dass Ihre URLs übersichtlicher (und einfacher auf dem Telefon abzulesen - "Beispiel-Dotcom-Slash-Produkte" klingen viel besser als "Beispiel-Dotcom-Slash-Produkte dot htm l") und einfacher Technologie in Zukunft zu wechseln (da keine URL-Änderung erforderlich wäre).


4
Ich bin aus SEO- und ästhetischen Gründen der Meinung, dass dies die beste Vorgehensweise ist.
Talvi Watia

Ja, es ist den Browsern egal, aber den Servern ist es egal, ob es sich um asp, aspx oder einen anderen Typ handelt, der zusätzliche Verarbeitung auf dem Webserver erfordert.
Ehrfurcht

Nach vielen Jahren scheint sich das Best-Practice durchgesetzt zu haben. Trotzdem frage ich mich, was passieren wird, wenn die Web-Crawler-Logik schließlich lernt, Operanden zu analysieren. ZB some-relevant-keywordsist es gleichbedeutend damit, dass (some) (!exclude->relevant) (!exclude->keywords)jeder SEO-Experte es plötzlich ändert, some+relevant+keywordsum die Ästhetik und Lesbarkeit der Verwendung von Bindestrichen als Trennzeichen zu zerstören. Grundursache: /?query=some-relevant-keywordsist bereits der wörtliche Ausschluss.
Talvi Watia


8

Wird eine Dateierweiterung bevorzugt oder nicht?

Es gibt nichts in den RFCs, das Dateierweiterungen erfordert, und Sie müssen diese auch nicht weglassen. Es ist eine Wahl, die Sie treffen.

Konforme HTTP-URIs benötigen für nichts Dateierweiterungen. Es gibt eine Vielzahl von HTTP-Headern (insbesondere den MIME-Typ), mit denen alle anderen Dateierweiterungen verarbeitet werden können.

Heutzutage verlassen sich die meisten Browser jedoch auf eine Kombination aus MIME-Typ, Erweiterung und binärem 'Fingerabdruck' der ersten Bytes, um den Inhaltstyp zu bestimmen. Dies kann manchmal zu überraschenden Ergebnissen führen. Daher ist es wichtig, dass wir Webmaster die richtigen Header festlegen (und möglicherweise das Sniffing von Inhaltstypen deaktivieren, wenn wir zu 101% sicher sind, dass unsere Header korrekt sind).

Es gibt eine Situation, in der Dateierweiterungen nützlich sind: Wenn der Endbenutzer Inhalte von Ihrer Site auf seinem lokalen Computer zur späteren Verwendung speichert. Theoretisch sollte ein "intelligenter" Browser sicherstellen, dass gespeicherte Inhalte für den lokalen Computertyp funktionieren. In der Praxis können Sie jedoch jedem helfen, indem Sie Inhalte mit branchenüblichen Erweiterungen wie .jpg, .mp4, .css usw. bereitstellen. Meiner Erfahrung nach behandeln alle Browser den HTML-Typ ordnungsgemäß. Sie müssen selbst keine .htm / .html-Erweiterung für HTML hinzufügen, da der Browser diesen bestimmten Inhaltstyp korrekt verarbeitet.

Sicherheit: Man könnte argumentieren, dass das Verbergen der von Ihnen verwendeten Plattform (.php / .asp usw.) einen Sicherheitsvorteil bietet. Das ist richtig. In der Praxis denke ich, dass jeder gute Hacker dies sofort entdecken wird, daher halte ich es nicht für die Mühe, diese Erweiterungen nur aus Sicherheitsgründen zu verstecken.

Besondere Überlegung: Wenn Sie in Zukunft eine CDN verwenden möchten und Ihre CDN vom Typ "Push" ist (Inhalte werden zuvor per SFTP auf die CDN hochgeladen), möchten Sie möglicherweise die Dateierweiterungen beibehalten. Die meisten Systeme von Drittanbietern untersuchen Dateierweiterungen, um herauszufinden, mit welchem ​​MIME-Typ der Inhalt bereitgestellt werden soll.

Meine persönliche Wahl wurde:

  • Wenn HTML dynamisch von meiner Webanwendung generiert wird, füge ich keine gefälschte .html-Erweiterung hinzu, um eine Verzeichnis- und Dateistruktur nachzuahmen, die eigentlich nicht vorhanden ist. Ich normalisiere URLs und ich standardisiere das aus SEO-Gründen verwendete URL-Format. Ich persönlich bevorzuge einen abschließenden Schrägstrich auf dem letzten Blatt der URL http://example.org/first/second/, aber das ist Geschmackssache.

  • Wenn es sich tatsächlich um tatsächliche Dateien handelt, die irgendwo auf eine Festplatte hochgeladen werden, behalte ich die 'normale' Dateierweiterung für den Typ. Für diese Art von Inhalten werden also CSS / JS / EXE / MP4 usw. verwendet.


Eine Sache, das Hinzufügen .htmzu imitieren ein Verzeichnis ( und nicht zwingende index.htm) ist wirklich nicht „fake“ , da Sie dienen HTML - Inhalten. Es wäre falsch, wenn der Inhalt nicht HTML wäre.
Talvi Watia

2

Ich habe ein wenig informell experimentiert und das, was ich entdeckt habe, hat mich überrascht, macht aber Sinn.

Vom Standpunkt des Inhalts, der an den Benutzer geliefert wird, sowie vom Bildschirm-Scraping aus bestimmt der Inhaltstyp den Tag.

Das Vorhandensein oder Fehlen einer Erweiterung sowie deren Bedeutung scheinen jedoch die Besuche in Suchmaschinen zu beeinflussen.

Wenn ich überhaupt eine Erweiterung weglasse, erhalte ich relativ wenige Treffer - als wäre die URL ein Ort oder ein dynamischer Inhalt und daher nicht sehr indizierbar.

Als ich dieselben Links in eine .xml-Erweiterung umwandelte, weil die Seiten tatsächlich von XSLT (auf der Serverseite) generiert wurden, wurde die Indizierung tatsächlich weiter gesenkt - vielleicht weil ich dachte, es handele sich nur um Daten oder das Ergebnis einer programmgesteuerten Anforderung .

Als ich die gleichen Links in .html änderte, waren die Suchmaschinen von der Website begeistert.

Momentan behandelt meine Site alle drei transparent, aber wenn es einen anklickbaren Link gibt, gebe ich die .html-Version der URL zurück.

Ich würde gerne glauben, dass Suchmaschinen ein bisschen schlauer oder weniger voreingenommen sind, aber genau das habe ich bei meinen Seiten beobachtet.


Werden jedoch nicht mehrere URIs für dieselbe Ressource zu falschen Seiten führen?
Talvi Watia

Technisch würde ich das annehmen, und ich vermute, dass das Richtige ist, wenn die anderen einfach eine Umleitung durchführen.
Walt Stoneburner

Das ist in der Tat sehr überraschend! Können Sie weitere Hintergrundinformationen bereitstellen, z. B. welche Suchmaschinen, inwieweit Sie die Änderung bemerkt haben usw.?
Damusnet

Ich habe einen enormen Verkehrsrückgang erlebt, und obwohl ich immer noch nicht sicher bin, denke ich, dass er mit dem Moment zusammenfiel, als ich von rel.
Dan

Es tut mir leid, dass ich so spät antworte, aber ich erinnere mich, dass Matt Cutts vor einiger Zeit erwähnt hat, wenn möglich eine .html-Datei zu verwenden . ( mehr hier ). Es macht Sinn, dass Suchmaschinen empfindlich auf Erweiterungen reagieren. Stellen Sie sich vor, Sie sehenhttp://example.com/index.exe
Timo Huovinen,

2

Nein, Sie sollten keine Dateierweiterung für normale Seitentypen verwenden, es sei denn, Sie benötigen sie aus technischen Gründen unbedingt. Wie verbessert es die Benutzererfahrung? Es ist mehr zu tippen, aber es sagt ihnen nichts Sinnvolles. Was können sie tun, wenn sie wissen, dass Ihre Site PHP, ASP usw. ist? Eine URL ist einfacher, übersichtlicher, benutzerfreundlicher und ohne Dateierweiterung einprägsamer.

Wenn eine URL keinen Dateinamen hat, wird sie normalerweise als Verzeichnis betrachtet.

Ich glaube nicht, dass ich damit einverstanden bin. Im Allgemeinen ist eine URL nur dann ein Verzeichnis, wenn sie einen abschließenden Schrägstrich enthält. Ohne einen abschließenden Schrägstrich wird es als eine Datei betrachtet.


Benutzererfahrung: Wenn die Dateierweiterung "" lautet .phpoder .aspwenn der Benutzer sie speichert, handelt es sich um einen unbekannten Dateityp, und Computer-Analphabeten wissen möglicherweise nicht, wie sie sie erneut öffnen sollen. Ohne Dateityp würde der Browser es hinzufügen, aber möglicherweise behindert dies einige Suchmaschinen?
Talvi Watia

0

Sie sollten eine Dateierweiterung nur hinzufügen, wenn der Inhalt hinter der URI tatsächlich eine Datei ist. Aber selbst dann könnte man es fallen lassen, wenn es nur eine Darstellung gibt (JPG, PDF, ...).

Wenn es mehrere Darstellungen gibt, wäre der HTTP-Weg, das Format über den AcceptHeader auszuhandeln . Wenn Sie Ihren Benutzern jedoch ein Mitspracherecht einräumen möchten, möchten Sie wahrscheinlich eine Erweiterung, damit sie auswählen können, welche Darstellung sie möchten (JPG, PNG, ...), indem Sie den einen oder anderen URI anfordern.


Dies ist mehr als nur Bild oder andere Ressourcen. Für Nicht-HTML-Ressourcen würde ich immer eine Dateierweiterung verwenden. Die meisten Browser wissen nicht, was zu tun ist, wenn sie ausgelassen werden, wenn der Benutzer "Speichern unter" ausführt. Natürlich können Sie den Dateityp in die Kopfzeile einfügen, aber sobald die Client-Computer gespeichert sind, wissen sie nicht, wie sie die Datei erneut öffnen sollen.
Talvi Watia
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.