nicht angemeldet
.htaccess
TS
Auge
JuliusHallo,
als Einsteiger hadere ich mit dem Code in der .htaccess Datei. Die Apache-Dokumentation überfordert mich ehrlich gesagt, zumal ich dringend ein Ergebnis benötige.
Bei dem ersten Codebeispiel schließt die zweite Zeile hinter der domain mit einem „$“ Zeichen ab.
Im zweiten Codebeispiel ist das nicht der Fall. Wo liegt der Unterschied?
Besonders dankbar wäre ich, wenn mir jemand den Code des ersten Beispiels Schritt für Schritt näher bringen könnte (die Bedeutung der Optionen und die "RewriteEngine-Anweisung" sind klar. Auch, dass das Ausrufezeichen für "nicht" steht).
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
RewriteEngine on
RewriteCond %{http_host} !^www\.example\.com [NC]
Rewriterule ^(.*)$ http://www.example.com/$1 [L,R=301]
Würde der folgende Code, das Gleiche bewirken?
Wenn ja, welches wäre die bessere Alternative?
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.example.net [OR]
RewriteCond %{HTTP_HOST} ^www.example.org
RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
Danke vorab!
-
Hallo und guten Morgen,
Bei dem ersten Codebeispiel schließt die zweite Zeile hinter der domain mit einem „$“ Zeichen ab.
Sorry... war Quatsch!
komme später nochmal
Liebe Grüße
TS -
Hallo und guten Abend,
nun habe ich hoffentlich genug Zeit, wenigstens den ersten Teil zu beantworten...
RewriteEngine on RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC] RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]- Umschreibe-Mechanismus einschalten
- Wenn der Wert in HTTP_HOST nicht exakt "www.example.com" beinhaltet
- (!) = nicht
- (^) = am Anfang der Zeichenkette beginnen
- ($) = bis zum Ende der Zeichenkette lesen
- [NC] = Groß-Kleinschreibung missachten
- %{HTTP_HOST} = der ausgeschnittene Domainanteil des Requests ohne Scheme und ohne Query-String
- Nimm den Query-String (also nicht den HTTP_HOST-Anteil) von Anfang bis Ende und hänge ihn
- ($1) hinter den URL-Anteil "http://www.example.com/",
- [K] = Dies ist die letzte zu beachtende Umschreiberegel,
- [R=301] = der Response-Status soll "301 "lauten.
($1) = erste in der Bedingung durch Klammerung extrahierter Treffer auf das dort angegebene (Muster). Wenn Du vorne mehr Klammern (Muster) hast, erscheinen die hinten wieder in ($x), x = Nummer des Klammerpaares.
Liebe Grüße
TS-
Hallo und guten Morgen,
- [K] = Dies ist die letzte zu beachtende Umschreiberegel,
Das sollte "[L] = " heißen!
Irgendwie ist mein alter ComPuter wohl zu langsam. Wenn ich [speichern] klicke, ist die Vorschau oft noch nicht fertig und weicht vom Eingabefenster ab. Ich weiß leider nicht, woraus der Post dann generiert wird...
Liebe Grüße
TS-
Hallo
Irgendwie ist mein alter ComPuter wohl zu langsam. Wenn ich [speichern] klicke, ist die Vorschau oft noch nicht fertig und weicht vom Eingabefenster ab.
Mach' dir nichts draus, dass passiert ab und an auch mit schnellen Rechnern. Die Vorschau wird aus deiner Eingabe mit JavaScript erzeugt, dass kann schon mal haken.
Ich weiß leider nicht, woraus der Post dann generiert wird...
Natürlich aus deiner Eingabe, nicht aus der daraus erzeugten Vorschau.
Tschö, Auge
--
Wenn man ausreichende Vorsichtsmaßnahmen trifft, muss man keine Vorsichtsmaßnahmen mehr treffen.
Toller Dampf voraus von Terry Pratchett
-
Hallo TS !
herzlichen Dank für Deine Erläuterungen!
Bis auf ein paar Kleinigkeiten (z.B. „ohne Scheme und ohne Query-String“ - das gilt dann sicher eher für dynamische Webseiten und Datenbankanbindungen) soweit verstanden - und umgesetzt.Ob man am Ende der zweiten Zeile ein „$“ anhängt oder nicht, dürfte im obigem Beispiel (bei einer statischen Webseite) also gleichgültig sein.
Ich bin erstmal sehr erleichtert, denn das SEO-Utility sagt nun (nach Konfiguration und Bereitstellen der .htaccess), der Server sei richtig konfiguriert (für Zugriffe mit und ohne www. / als auch bzgl. der weiteren Domains, die auf den gleichen Content zeigten). Der Hinweis zur Generierung von Duplicate Content ist WEG ! –puuuh–
Bin nun sehr gespannt, wie sich die Platzierungen in den Suchergebnissen bei Goo... und Co. entwickeln, wenn die Bots demnächst die Seite wieder crawlen.
Vielen lieben Dank nochmals für Deine Hilfe !
Nachtrag zum [K]-Lapsus wäre gar nicht nötig gewesen, das hatte ich schon gecheckt. ;-)
-
Tach!
Ob man am Ende der zweiten Zeile ein „$“ anhängt oder nicht, dürfte im obigem Beispiel (bei einer statischen Webseite) also gleichgültig sein.
Es ist gleichgültig (auch ob am Anfang ein ^ steht), aber aus anderem Grunde. Solange die Hostnamen für deinen VHost eindeutig sind und du den vollständigen Hostnamen angibst, ist es egal, ob die Regel "nimm alles" oder "nimm alles von Anfang bis Ende" lautet. "Nimm alles" beinhaltet bereits alles, da bleibt nichts mehr übrig, dass zwischen "alles" und den Begrenzungen sein könnte.
Anders wäre es, wenn du auf example.com testen möchtest und auch noch www.example.com existiert. Dann wäre example.com ja nicht immer "alles", sondern im Falle von www.example.com nur ein Teil und du müsstest zumindest ^example.com notieren, wenn du die www-lose Variante meinst.
dedlfix.
-
@@dedlfix
Was bedeutet denn dann die zweite Zeile im folgenden Beispiel?
RewriteCond %{HTTP_HOST} !^www\.example\.com [NC] RewriteCond %{HTTP_HOST} !^$ RewriteRule ^/(.*) http://www.example.com/$1 [L,R]-
Hallo und guten Morgen,
@@dedlfix
Was bedeutet denn dann die zweite Zeile im folgenden Beispiel?
RewriteCond %{HTTP_HOST} !^www\.example\.com [NC] RewriteCond %{HTTP_HOST} !^$ RewriteRule ^/(.*) http://www.example.com/$1 [L,R]HTTP_HOST ist nicht gleich <leer>.
Das kann mMn nur bei Fehlkonfiguration in der Grauzone (Server wehrt sich nicht dagegen) vorkommen, wenn ein Webserver sowohl IP-basierte, als auch namebasierte Virtual Hosts betreut.
Da wirst Du jetzt erstmal ein bisschen lesen müssen, um dann gezielt weiter Fragen stellen zu können:
Apache Manual zu ip-basierten und namansbasierten Hosts und das ganze auch nochmal zwei Versionen neuer (hatte ich im ersten Moment nicht gemerkt, dass ich bei V2.0) gelandet war.
Liebe Grüße
TS-
Tach!
HTTP_HOST ist nicht gleich <leer>.
Das kann mMn nur bei Fehlkonfiguration in der Grauzone (Server wehrt sich nicht dagegen) vorkommen, wenn ein Webserver sowohl IP-basierte, als auch namebasierte Virtual Hosts betreut.
Dass ein Request ohne Host-Header daherkommt, ist recht ungewöhnlich. Ein kurzer Test ergab, dass selbst bei einem Request nach IP-Adresse statt Namen sowohl Chrome, Firefox und Edge eine Host-Zeile mit der IP-Adresse versenden. Ist das nicht sogar eine Pflicht-Angabe? Ich würde jedenfalls solche Requests als defekt, wenn nicht gar maliziös einordnen.
Von einer Fehlkonfiguration des Webservers würde ich nicht ausgehen. Requests ohne Host-Zeile landen im Default-VHost oder werden IP-basiert zu einem VHost durchgestellt. IP-basiert ist auch nicht unbedingt das, was man heutzutage macht, weil das eine eineindeutige Zuordung zwischen Website und IP-Adresse erfordert.
dedlfix.
-
Hallo und guten Morgen,
HTTP_HOST ist nicht gleich <leer>.
Das kann mMn nur bei Fehlkonfiguration in der Grauzone (Server wehrt sich nicht dagegen) vorkommen, wenn ein Webserver sowohl IP-basierte, als auch namebasierte Virtual Hosts betreut.
Dass ein Request ohne Host-Header daherkommt, ist recht ungewöhnlich. Ein kurzer Test ergab, dass selbst bei einem Request nach IP-Adresse statt Namen sowohl Chrome, Firefox und Edge eine Host-Zeile mit der IP-Adresse versenden. Ist das nicht sogar eine Pflicht-Angabe? Ich würde jedenfalls solche Requests als defekt, wenn nicht gar maliziös einordnen.
Von einer Fehlkonfiguration des Webservers würde ich nicht ausgehen. Requests ohne Host-Zeile landen im Default-VHost oder werden IP-basiert zu einem VHost durchgestellt. IP-basiert ist auch nicht unbedingt das, was man heutzutage macht, weil das eine eineindeutige Zuordung zwischen Website und IP-Adresse erfordert.
Danke für die Ergänzung. So weit war ich vorhin auch ungefähr gekommen, nur die Szenarien ausprobieren konnte ich nicht mehr. Denkbar wäre auch noch eine bewusste Fehlkonfiguration im DNS oder die Zwischenschaltung eines (Reverse-)Proxys [Das Thema mit dem "Reverse" wollte ich jetzt nicht vertiefen]. Zumindest hat Apache dieses verrückte Beispiel ganz offiziell in seinen Virt-Host-Beispielen drin. Apache Rewrite Guide.
Vielleicht kann man damit etwas "reparieren", was an anderer Stelle im Netz versaubeutelt wurde?
Liebe Grüße
TS-
Danke Euch beiden, @@TS und @@dedlfix
Zumindest hat Apache dieses verrückte Beispiel ganz offiziell in seinen Virt-Host-Beispielen drin. Apache Rewrite Guide.
Damit hast Du genau jene Quelle gefunden, wo ich dieses Codebeispiel aufgeschnappt habe. ;-)
Meine Interpretation stimmte auch mit Deiner obigen Erklärung
HTTP_HOST ist nicht gleich <leer>.
überein. Einen Reim darauf konnte ich mir aber nicht machen.
Bei meiner Recherche hat sich nun noch eine weitere Frage aufgetan:
Irgendwo (Quelle müsste ich nochmal nachschlagen) habe ich gelesen, dass durch die Möglichkeit, dass Domains sowohl übera) das http-
als auch
b) über das https-Protokollaufgerufen werden können, ebenfalls duplitate content entstehen könne.
Hintergrund: Theoretisch, aber (natürlich) auch praktisch, wäre es ja möglich, dass über jedes dieser Protokolle ein seperater Inhalt auf der gleichen Domain (bzw. ansonsten gleichen URL) angeboten wird. Oder eben auch der selbe Inhalt (was viel praxisnäher ist), einmal eben verschlüsselt und einmal unverschlüsselt, und so könnte sich das für Goo... wieder als duplicate content darstellen.Nun wird meine Webseite grundsätzlich nur über das http-Protokoll aufgerufen. Soll heißen, ich habe keine verschlüsselten Seiten. Bei einem Test habe ich aber festgestellt, man die Seite(n) sehr wohl auch per https aufrufbar sind. Ruft man nicht nur den Domainnamen, sondern eine der Unterseiten auf, habe ich bei einem Test festgestellt, dass die (eigentliche) .html-Datei, dann (automatisch - wohl aufgrund der Serverkonfiguration) zu einer .php-Datei konvertiert wird. Und in der Suchleiste steht eben https://....
So wäre dann ja (wieder) ungewollt duplicate content vorhanden.
Kann und sollte man, z.B. per rewrite-Regel, auch hier festlegen, wenn die Webseite per https aufgerufen wird, dann liefere die Dateien aber trotzdem nur per http aus?
Wie könnte man dies umsetzen?-
Meine Idee war folgende (klappt aber nicht:)
RewriteEngine on RewriteCond %{HTTP_HOST} !^www\.example\.com [NC,OR] RewriteCond %{SERVER_PORT} ^443$ [OR] RewriteCond %{HTTPS} on RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]Sollte also abprüfen, wenn
- eine der "Nebendomains" (z.B. example.net) aufgerufen wird,
- oder die aufgerufene Domain nicht mit "www." beginnt,
- oder die Domain über Port 443 bzw. über das https Protokoll aufgerufen wird,
dann leite per 301 über http an www.example.com weiter.
Wenn ich nach Bereitstellung obiger .htaccess aber eine Redirect-Überprüfung veranlasse (egal ob für die Hauptdomain, https://www.example.com - oder für eine der "Nebendomains", z.B. https://www.example.net) bekomme ich folgendes Ergebnis bei einer "Redirect-Überprüfung" angezeigt:
Result: https://www.example.com 302 Moved Temporarily ./user/index.php 200 OK Problems found: You use a 302 redirect. This means, that the actually content is temporary not reachable and will come back soon. To use a 302 redirection for generally moved pages is a bad idea. Search engine bot might not follow it or handle it as temporary. For SEO this is also a bad idea, because no link juice will be transferred to the linked page.Anmerkung:
Die 302er Weiterleitung und die Angabe "./user/index.php" muss mMn von der Serverkonfiguration herrühren (siehe auch mein Beitrag vom 09.02.2017, 03:03 Uhr, vorletzter Absatz).
Frage:
Wie muss ich die .htaccess anpassen, um zum o.g. Ziel zu kommen? -
Hello,
Bei meiner Recherche hat sich nun noch eine weitere Frage aufgetan:
Irgendwo (Quelle müsste ich nochmal nachschlagen) habe ich gelesen, dass durch die Möglichkeit, dass Domains sowohl übera) das http-
als auch
b) über das https-Protokollaufgerufen werden können, ebenfalls duplitate content entstehen könne.
Hintergrund: Theoretisch, aber (natürlich) auch praktisch, wäre es ja möglich, dass über jedes dieser Protokolle ein seperater Inhalt auf der gleichen Domain (bzw. ansonsten gleichen URL) angeboten wird. Oder eben auch der selbe Inhalt (was viel praxisnäher ist), einmal eben verschlüsselt und einmal unverschlüsselt, und so könnte sich das für Goo... wieder als duplicate content darstellen."Praxisnäher" im Sinne von "gewachsen und nicht nachgedacht" vielleicht, aber sonst würde ich keinen Grund dafür sehen, das Angebot unter http:// genau gleich zu halten zu dem unter https://
Wenn https:// möglich ist, also möglichst ein gängiges Zertifikat vorhanden ist, dann gebietet es die Fürsorge für den Kunden quasi, keinerlei persönliche oder administrative Daten mehr über http:// auszutauschen. Wäre doch schlimm, wenn eine Bank das Banking über http:// anbieten würde!
Da auch das Web mit den Dialogsystemen über den Browser nebst CGI-Techniken u. ä. erst einige Zeit nach dem ersten http enstanden sind, kann man leicht nachvollziehen, dass die Sicherheitsaspekte auch nicht von Anfang an berücksichtigt wurden.
Über "Duplicate Content" würde ich mir überhaupt keine Gedanken mehr machen, sondern eher über "Senseless content" versa "Meaningful Content".
Liebe Grüße
Tom S.--
Die Kravatte ist das Kopftuch des Westens
-
Wäre doch schlimm, wenn eine Bank das Banking über http:// anbieten würde!
Tom, ich bin keine Bank, und über meine Webseite werden auch KEINERLEI persönliche oder sensible Daten ausgetauscht.
Ich bin stolz darauf, als Nicht-Web-Profi eine informative und sehr ansprechende Webseite zu betreiben, die über validen Code verfügt, stets aktuell gehalten wird und die bisher von den Suchmaschinen auch hervorragend gefunden wurde. Und für diese Seite gibt es auch immer wieder ein sehr positives Feedback. Wie das Problem des "duplicate content" entstanden ist, hatte ich schon beschrieben. Und seit kurzem ist das zu einem echten Problem geworden, zu DEM PROBLEM schlechthin.
Daher hat dieses Problem für mich momentan absolute und einzige Prioriät. Ich denke, das ist auch nachvollziehbar.
Da keine persönlichen oder sensiblen Daten bei Nutzung der Webseite ausgetauscht werden, bin ich der Meinung, dass das Thema der verschlüsselten Übertragung zumindest im Moment drittranig ist. Die Webseite muss in den Suchergebnissen aber wieder gefunden werden, das ist DAS THEMA!Dass die Seite aber überhaupt mit vorangestelltem https:// aufgerufen werden kann, eröffnete sich mir erst jetzt im Rahmen meiner vorgenannten Recherche. Alle Details dazu hatte ich ja in meinem letzten Threat dargelegt. Und wenn dies (ebenfalls) zu Duplicate Content führen sollte, dann ist das ein Problem, dass ich (auf einfachem Wege und SOFORT) in den Griff bekommen muss und möchte.
Könnten wir daher nochmal auf die Fragestellung hinsichtlich einer diesbezüglichen LÖSUNG zurückkommen?
-
Hallo Sanddorn22,
Wäre doch schlimm, wenn eine Bank das Banking über http:// anbieten würde!
Tom, ich bin keine Bank, und über meine Webseite werden auch KEINERLEI persönliche oder sensible Daten ausgetauscht.Doch. Geheimdienste und andere Kriminellen können herausfinden, welche Seiten die Nutzer aufrufen. Mit https lässt sich hingegen nur die Domain ablesen.
– Es macht wenig Sinn, in Zeiten von kostenlosen Zertifikaten (bei dir scheint TLS ja zudem schon fertig konfiguriert zu sein), noch auf unverschlüsselte Verbindungen zu setzen.Außerdem bewertet Google https (funktionierendes natürlich) leicht positiv.
Dass die Seite aber überhaupt mit vorangestelltem https:// aufgerufen werden kann, eröffnete sich mir erst jetzt im Rahmen meiner vorgenannten Recherche. Alle Details dazu hatte ich ja in meinem letzten Threat dargelegt. Und wenn dies (ebenfalls) zu Duplicate Content führen sollte, dann ist das ein Problem, dass ich (auf einfachem Wege und SOFORT) in den Griff bekommen muss und möchte.
Wenn beim Aufruf mit https keine Fehlermeldungen kommen, das Zertifikat also gültig ist, dann würde ich den Nutzer stumpf von der http- auf die https-Version umleiten. Das kriegt auch Google mit und du hast kein Problem mit Duplicate-Content.
Gruß
Julius-
Hallo Julius,
danke für Deine Erläuterung samt Links. Klingt soweit ganz schlüssig. Problem: Bei meinem jetzigen Hoster gibt es wohl kein gültiges Zertifikat.
Wenn ich meine Seite im Browser per https:// aufrufe, bekomme ich folgenden Hinweis:
„Diese Verbindung ist nicht sicher“ und weiter....
„www.example.com verwendet ein ungültiges Sicherheitszertifikat.“Jetzt auch noch den Hoster wechseln? Nur, wenn es gar nicht anders ginge.
Lese mich heute Abend/Nacht mal genauer in die von Dir verlinkten Seiten ein.Gruß
Sanddorn22-
Hallo Sanddorn22,
Problem: Bei meinem jetzigen Hoster gibt es wohl kein gültiges Zertifikat.
Nun ja, ich glaube nicht, dass Google dann auf die Idee kommt, die Inhalte zu crawlen und dann als Duplicate-Content abzutun. Außerdem verlinkt wohl niemand die https-Version, wenn die nicht funktioniert...
Hast du dir mal die Google Search Console (du benötigst dafür einen Google-Account und must auf deiner Site eine HTML-Datei mit einer Kennung als „Eigentumsnachweise“ ablegen) angesehen? Dort siehst du den Indexierungsstatus, kannst URLs umleiten und dir von Google Tipps geben lassen (wenn sie ein Problem mit deiner Site hätten, können sie dir das dann mitteilen).
Jetzt auch noch den Hoster wechseln? Nur, wenn es gar nicht anders ginge.
Lese mich heute Abend/Nacht mal genauer in die von Dir verlinkten Seiten ein.Im Moment vermutest du ja nur, dass das ein Problem sein könnte. Vielleicht lässt sich das mit einem Blick in die Search Console klären.
Uberspace ist nebenbei ein empfehlenswerter Hoster. Gute Doku, ausgezeichneter Support. Angenehm ist, dass die meisten in ihrem Wiki notierten Dinge (Konfiguration, htaccess, Befehle in der Kommandozeile) Standard sind und somit auch auf dem eigenen Server funktionieren. Man lernt also auch noch etwas über die Hintergründe und nicht bloß im Webinterface eines Hosters herumzuklicken...
Gruß
Julius-
Hi @@Julius,
habe mir übers verlängerte Wochenende etwas Ruhe gegönnt, daher die verspätete Rückmeldung.
... ich glaube nicht, dass Google dann auf die Idee kommt, die Inhalte zu crawlen und dann als Duplicate-Content abzutun. (...) Im Moment vermutest du ja nur, dass das ein Problem sein könnte.
Ja, damit hast Du Recht. Im Moment liegen bei mir die Nerven blank. Durch den Totalabsturz in den Suchergebnissen bin ich eben zum Handeln einfach gezwungen. Und so kam ich nach ausführlicher Recherche darauf, welche verschiedenen "technischen Aspekte" ungewollt (bei Goo...) zur Bewertung "duplicate content" führen können. Bei Bing, Yahoo und Co taucht meine Seite nach wie vor "on the top" auf.
Die Konfiguration bezüglich Domainaufruf mit und ohne "www." und der "Nebendomains" habe ich mittlerweile ja behoben (zumindest sagt das von mir verwendete Seo-Tool dies aus). Googlebot hat die Seite offenbar auch neu gecrawlt (zumindest ist eine Änderung im Beschreibungstext nun auch in den Suchergebnissen so zu finden). Die Platzierung in den Suchergebnissen hat sich aber kaum merklich verbessert.
Hast du dir mal die Google Search Console angesehen?
Die ehemaligen "webmastertools", meinst Du? Nein, habe ich nicht.
Grund: Ich bin überhaupt kein Freund von Goo.... und dem Ausspähen der Nutzer. Daher habe ich bisher sowohl auf ein dortiges Konto, als auch auf ein Einbinden von Goo... Analy.... auf meiner Webseite verzichtet. Ich finde es auch grauslig, dass über 80% der Nutzer auf diese Suchmaschine fixiert sind. Leider bin ich darauf angewiesen, eben auch dort gefunden zu werden. Bis vor einem viertel Jahr hat das ja auch wunderbar geklappt.Kann man das, was ich über die Search Cons. nachschauen, bzw. konfigurieren kann, nicht auch mit "herkömmlichen Mitteln" (ohne Sear. Cons.) erreichen? Wie "entscheidend" ist es, die Sear. Cons. zu nutzen, um die Seite wirklich nachhaltig wieder nach vorne zu bekommen?
Oder dauert das nach einem Totalabsturz einfach eine ganze Weile, weil Goo.. die betreffende Seite erstmal als "verbrannte Erde" bewertet?-
Hallo Sanddorn22,
nur kurz, später ggf. mehr:
Ich bin überhaupt kein Freund von Goo.... und dem Ausspähen der Nutzer.
Nun, ausspioniert wird in der Search Console niemand. Google kann dich damit nur über eventuelle Probleme informieren. Außer dass man diese Probleme dann beheben und damit sein Ranking verbessern kann, wüsste ich nicht, dass man durch die Eintragung einen direkten Vorteil hätte.
Google Analytics ≠ Search Console
Ob die anderen Anbieter etwas Ähnliches anbieten, müsste man mal recherchieren.
Gruß
Julius
-
-
-
-
-
-
-
Hallo Sanddorn22,
Bei meiner Recherche hat sich nun noch eine weitere Frage aufgetan:
Irgendwo (Quelle müsste ich nochmal nachschlagen) habe ich gelesen, dass durch die Möglichkeit, dass Domains sowohl übera) das http-
als auch
b) über das https-Protokollaufgerufen werden können, ebenfalls duplitate content entstehen könne.
Hintergrund: Theoretisch, aber (natürlich) auch praktisch, wäre es ja möglich, dass über jedes dieser Protokolle ein seperater Inhalt auf der gleichen Domain (bzw. ansonsten gleichen URL) angeboten wird. Oder eben auch der selbe Inhalt (was viel praxisnäher ist), einmal eben verschlüsselt und einmal unverschlüsselt, und so könnte sich das für Goo... wieder als duplicate content darstellen.Ich habe das schon mal irgendwo in Aktion gesehen. Ich finde es aber von der Nutzbarkeit her merkwürdig, ich verstehe nicht, warum das gemacht wird. Außerdem legt man sich Steine in den Weg, falls man irgendwann beide Angebote verschlüsselt anbieten will (→ separate Domains).
Es macht in den seltensten Fällen Sinn, eine Site zusätzlich unverschlüsselt erreichbar zu halten: Woher sollen Nutzer, die die Seite unverschlüsselt aufrufen, dann wissen, dass sie auch verschlüsselt zu erreichen ist und damit eine Sicherheitsverbesserung erzielt wird? Also automatische Weiterleitung. Dann kommt das nächste Problem: Per Man-in-the-Middle-Angriff kann dem Nutzer eine http-Version untergejubelt werden, obwohl er die https-Version aufgerufen hat (der Angreifer entschlüsselt also den Datenverkehr „für“ den Nutzer). Um diesen „Downgrade“ zu verhindern, setzt man den
Strict-Transport-Security-Header.
Das Ende vom Lied: Die Inhalte sind nur via https aufrufbar und Suchmaschinen sehen das nicht als Duplicate-Content, weil ja eine Umleitung von http auf https stattfindet.Gruß
Julius
-
-
-
-
-
-
-