nicht angemeldet Felix Riesterer
Der Martin
Der Martin
Matthias Apsel
Der Martin
JürgenB
Der Martin
JürgenB
Matthias Apsel
Die Seite a.de ist gut in den Suchmaschinen platziert und soll nach b.de umgezogen werden. Wie mache ich das ohne meine Suchmaschinen-Platzierung zu verschlechtern?
Meine naive Vorstellung:
a wird nach dem Umzug eine Weiterleitung auf b. Wer also a.de im Browser aufruft, wird weitergeleitet, sieht aber immer noch a.de in der Adresszeile (weiß gerade nicht wie diese Art der Weiterleitung heißt).
Ich weiß aber nicht wie Suchmaschinen reagieren wenn
Lieber Oli,
Die Seite a.de ist gut in den Suchmaschinen platziert und soll nach b.de umgezogen werden.
warum?
Ich weiß aber nicht wie Suchmaschinen reagieren wenn
- unter a.de und b.de die gleiche Seite erreichbar ist
- a auf b weitergeleitet wird
Du hast alternative Domains für ein und denselben Content? Das sollte eine Suchmaschine verstehen können, wenn Du aus technischer Sicht dafür sorgst, dass sie eine der beiden Domains als die "eigentliche" Domain für den Content sieht, und die andere Domain als alternativen Weg dazu.
Liebe Grüße
Felix Riesterer
Lieber Oli,
Die Seite a.de ist gut in den Suchmaschinen platziert und soll nach b.de umgezogen werden.
warum?
Die Website a.de hab ich mal für ein Familienmitglied erstellt. Dieses will demnächst selber die Website pflegen. Nur bitte nicht mit meinen Zugangsdaten. Auf Ihrem neuem eigenen Webhosting-Paket (b.de) kann sie dann machen was sie will.
Ich könnte die Domain auch an die Person übertragen lassen. Wäre wohl die beste Lösung.
Hallo Oli,
Die Website a.de hab ich mal für ein Familienmitglied erstellt. Dieses will demnächst selber die Website pflegen. Nur bitte nicht mit meinen Zugangsdaten. Auf Ihrem neuem eigenen Webhosting-Paket (b.de) kann sie dann machen was sie will.
Ich könnte die Domain auch an die Person übertragen lassen. Wäre wohl die beste Lösung.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
Das wäre in der Tat die beste Lösung.
Viele Grüße
Robert
Hallo,
Meine naive Vorstellung:
a wird nach dem Umzug eine Weiterleitung auf b. Wer also a.de im Browser aufruft, wird weitergeleitet, sieht aber immer noch a.de in der Adresszeile
nein, genau das würde ich nicht tun. Weiterleitung ja (am besten per HTTP-Status 302), aber dann so, dass der Besucher das auch "sieht", die Browser-Adresszeile also die neue Domain widerspiegelt.
Was du beschrieben hast, würde ja dem Umzug widersprechen und ist auch technisch nur mit Klimmzügen möglich.
Ich weiß aber nicht wie Suchmaschinen reagieren wenn
- unter a.de und b.de die gleiche Seite erreichbar ist
Duplicate Content wird möglicherweise negativ bewertet, aber die Aussagen darüber gehen auseinander.
- a auf b weitergeleitet wird
Dann wird die Suchmaschine irgendwann die alte Adresse im Index durch die neue ersetzen.
Ciao,
Martin
Weiterleitung ja (am besten per HTTP-Status 302)
301 ist in dem Fall angebracht.
Hi,
Weiterleitung ja (am besten per HTTP-Status 302)
301 ist in dem Fall angebracht.
ja, den meinte ich eigentlich. Die Zuordnung der Codes 301 und 302 zu Moved Permanently bzw. Moved Temporarily verwechsle ich immer wieder, weil sie für mein Empfinden genau verkehrtrum ist.
Ciao,
Martin
Hallo Der Martin,
Die Zuordnung der Codes 301 und 302 zu Moved Permanently bzw. Moved Temporarily verwechsle ich immer wieder, weil sie für mein Empfinden genau verkehrtrum ist.
Das hätte ich gern erklärt: Weil 302 > 301 aber temporarily < permanently?
Bis demnächst
Matthias
Hallo Matthias,
Die Zuordnung der Codes 301 und 302 zu Moved Permanently bzw. Moved Temporarily verwechsle ich immer wieder, weil sie für mein Empfinden genau verkehrtrum ist.
Das hätte ich gern erklärt: Weil
302 > 301abertemporarily < permanently?
das trifft die Semantik ungefähr. Ja, in einer Rangfolge würde temporarily für mich vor permanently kommen, also müsste das auch den kleineren Code haben.
Ciao,
Martin
Das hätte ich gern erklärt: Weil
302 > 301abertemporarily < permanently?das trifft die Semantik ungefähr. Ja, in einer Rangfolge würde temporarily für mich vor permanently kommen, also müsste das auch den kleineren Code haben.
Hmm... auch wenn ich in dem konkreten Fall folgen kann, frage ich mich gerade, wie man die Liste und hier kontrekt der 3er denn bitteschön semantisch korrekt sortieren soll? Solche Konventionen entstehen nun einmal historisch und werden dann halt numerisch hochgezählt.
Den ursprünglichsten (im Sinne von niedrigste Zahl) von allen: "300 Multiple Choices" habe ich z.B. noch nie bewusst gesetzt, auch wenn die Idee ja nachvollziehbar ist. Irgend jemand?
Ich unterstelle mal, fast jeder von uns muss da von Zeit zu Zeit nachschauen, was man genau wofür verwenden sollte.
Hallo,
"300 Multiple Choices"
der kommt bei mir, wenn der Spellchecker nicht mehr weiter weiß.
Gruß
Jürgen
"300 Multiple Choices"
der kommt bei mir, wenn der Spellchecker nicht mehr weiter weiß.
Klingt interessant, aber ich kann nicht ganz folgen. Welches Szenario genau?
Hallo,
"300 Multiple Choices"
der kommt bei mir, wenn der Spellchecker nicht mehr weiter weiß.
Klingt interessant, aber ich kann nicht ganz folgen. Welches Szenario genau?
ich vermute, Jürgen hat da irgendeine Pseudo-Intelligenz, die bei falschen URLs nicht gleich das Handtuch mit der eingestickten 404 wirft, sondern zunächst versucht zu erraten, was der Client denn wohl gemeint haben könnte.
Manchmal funktioniert sowas ja ganz gut.
So long,
Martin
ich vermute, Jürgen hat da irgendeine Pseudo-Intelligenz, die bei falschen URLs nicht gleich das Handtuch mit der eingestickten 404 wirft, sondern zunächst versucht zu erraten, was der Client denn wohl gemeint haben könnte.
OK. Aber ich bin immer noch auf der Suche nach einem sinnvollen Einsatzszenario.
Manchmal funktioniert sowas ja ganz gut.
Ein sinnvolles Einsatzszenario für HTTP 300 wäre dabei welches? 😉
Hallo,
ich setze in die .htaccess einfach
CheckSpelling on
und dann passiert z.B. so etwas:
https://www.j-berkemeier.de/Ritzelrechner
Gruß
Jürgen
ich setze in die .htaccess einfach
CheckSpelling onund dann passiert z.B. so etwas:
Hmmm... Im Sinne von z.B. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/300 verstehe ich den Sinn nicht. Welchen Zweck verfolgst Du damit?
Hallo Mitleser,
Hmmm... Im Sinne von z.B. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/300 verstehe ich den Sinn nicht. Welchen Zweck verfolgst Du damit?
Der Besucher soll mögliche Ziele für den Ritzelrechner wählen können.
Bis demnächst
Matthias
Hmmm... Im Sinne von z.B. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/300 verstehe ich den Sinn nicht. Welchen Zweck verfolgst Du damit?
Der Besucher soll mögliche Ziele für den Ritzelrechner wählen können.
Da kann ich leider weiter nicht folgen, bzw. verstehen, warum das eine gute Idee sein soll. Nur weil jemand einen ungültigen Ressourcenaufruf (falscher Link, Tippfehler...) provoziert hat, sollte man das mit einem "300 Multiple Choices" quittieren? Ist mir weiter unklar. In Jürgens konkretem Beispiel finde ich das mittels "CheckSpelling" sogar kontraproduktiv, weil mir der Apache dann irgendwelche ".js" bzw. ".gz" vorschlägt, die mich garantiert nicht interessiert haben, als ich den Abruf gestartet habe.
Besser wäre dann wohl eine Art von "Sorry, da ist leider etwas schief gelaufen. Meinten Sie evtl. unsere Seite XYZ?"
Abseits davon, dass so etwas m.E. nur auf gescripteter Basis funktionieren kann: HTTP 300 ist in dem Fall doch nur eine Vermutung. Bösartig betrachtet sogar eine Unterstellung. Die Ressource existiert nicht. 404 mit Alternativvorschlägen und fertig.
Also nochmal meine Frage: wofür ist HTTP 300 sinnvoll?
Hallo Mitleser,
Also nochmal meine Frage: wofür ist HTTP 300 sinnvoll?
Ich erachte das beschriebene Szenarion als sinnvoll.
300 - die angeforderte Ressource gibt es nicht, aber du könntest vielleicht eine dieser Ressourcen gemeint haben.
Bis demnächst
Matthias
Ich erachte das beschriebene Szenarion als sinnvoll.
300 - die angeforderte Ressource gibt es nicht, aber du könntest vielleicht eine dieser Ressourcen gemeint haben.
Aber es bleibt doch eine Unterstellung? Wo ist der Gewinn? Du hast doch
http://selfhtml.apsel-mv.de/java-javascript/
online, was das Thema IMHO sehr schön auf den Punkt bringt. Dem User/Client mögliche Alternativen anzubieten, ist eine sehr gute Idee, ja!
Aber die Unterscheidung zwischen HTTP 300 und HTTP 404 ist dabei IMHO komplett nutzlos. Wo liegt da der Sinn?
Hallo,
wenn der Spellchecker für dich keine Hilfe ist, gilt das auch für den 300er.
Ich finde es hilfreich, wenn kleine Tippfehler korrigiert werden, und man dann nicht auf einer „Not found“ Seit landet, wenn sich der Spellchecker mal nicht sicher ist.
Gruß
Jürgen
Hallo Jürgen,
Ich finde es hilfreich, wenn kleine Tippfehler korrigiert werden, und man dann nicht auf einer „Not found“ Seit landet, wenn sich der Spellchecker mal nicht sicher ist.
das mag für viele Nutzer zutreffen. Ich habe kein Problem, mich da als Angehöriger einer Minderheit zu outen: Ich habe es grundsätzlich lieber, eine brutale, aber klare Fehlermeldung zu kassieren, wenn etwas nicht stimmt.
Das gilt nicht nur im Web, sondern auch in anderen Lebenslagen. Ich bin für eindeutige, klare Ansagen.
Das soll aber nicht heißen, dass ich dein Konzept missbillige. Es gibt bestimmt jede Menge Nutzer, denen damit geholfen wäre.
Ciao,
Martin
Hallo Martin,
stell dir vor, du hast irgendwoher eine interessante URL bekommen, abgeschrieben aus einer Zeitung, oder in einem Gespräch. Jetzt willst du die Seite besuchen, hast dir aber die URL fehlerhaft gemerkt. Und jetzt kommt ein Not found. Sonst nichts. Nicht gerade hilfreich.
Gruß
Jürgen
stell dir vor, du hast irgendwoher eine interessante URL bekommen, abgeschrieben aus einer Zeitung, oder in einem Gespräch. Jetzt willst du die Seite besuchen, hast dir aber die URL fehlerhaft gemerkt. Und jetzt kommt ein Not found. Sonst nichts. Nicht gerade hilfreich.
Ob nur "not found" oder etwas hilfreiches ausgegeben wird, hat nichts mit dem Thema HTTP 300 vs HTTP 404 zu tun.
wenn der Spellchecker für dich keine Hilfe ist, gilt das auch für den 300er.
Das verstehe ich nicht.
Ich finde es hilfreich, wenn kleine Tippfehler korrigiert werden, und man dann nicht auf einer „Not found“ Seit landet, wenn sich der Spellchecker mal nicht sicher ist.
Ob die Seite nun nur ein H1 mit „Not found“ ausgibt, oder etwas Hilfreiches, liegt in der Hand des Seitenbetreibers. So betreibst Du das ja auch bei Aufrufen, an denen der Spellchecker mit seiner Heuristik scheitert.
Mir geht es hierbei aber rein um den Statuscode 300 vs 404.
Findest Du es nicht inkonsistent, den Apache mit mit seiner Heuristik entscheiden zu lassen, ob nun ein 404 oder 300 angebracht ist? Es ist und bleibt eine Unterstellung.
Nochmal: das Markup dazu für den Client darf und soll so hilfreich sein, wie nur möglich.
Hallo,
also ich sehe schon einen Unterschied zwischen „Nicht gefunden“ und „Meinst du vielleicht …“, den man auch im Statuscode übermitteln kann.
Gruß
Jürgen
also ich sehe schon einen Unterschied zwischen „Nicht gefunden“ und „Meinst du vielleicht …“, den man auch im Statuscode übermitteln kann.
Theoretisch ja. Nur wer trifft verlässlich die Fallunterscheidung?
Hallo,
Theoretisch ja. Nur wer trifft verlässlich die Fallunterscheidung?
der Webserver, sicher nicht Perfekt, aber besser als nichts.
Gruß
Jürgen
Theoretisch ja. Nur wer trifft verlässlich die Fallunterscheidung?
der Webserver, sicher nicht Perfekt, aber besser als nichts.
Denke ich verstehe Dich: Dir geht es einfach darum, dass laut Deinem Beispiel dem User (hoffentlich) hilfreiche Angebote unterbreitet werden. Eine gute Idee, auch wenn ich bei dem Beispiel bei 3 von 4 false positives skeptisch ob der Ergebnisses bin ;-)
Nur, worum es mir eigentlich geht (sorry, wenn ich so darauf herum hacke): es hat nichts mit dem Thema HTTP 300 vs HTTP 404 zu tun.
Alternativangebote kann ich auch bei HTTP 404 machen.
Hallo,
Alternativangebote kann ich auch bei HTTP 404 machen.
ist der 300 nicht der Code für das Alternativangebot? So ein "Zwar nicht gefunden, aber wie wäre es mit ..."
Gruß
Jürgen
Hallo,
ich habe CheckSpelling eingeschaltet, damit kleine Tipfehler wie falsche Groß-Kleinschreibung korrigiert werden. Das Beispiel mit der fehlenden Extension sollte nur zuverlässig zeigen, wann der 300er kommt.
Gruß
Jürgen
ich habe CheckSpelling eingeschaltet, damit kleine Tipfehler wie falsche Groß-Kleinschreibung korrigiert werden.
Okay. Für diesen konkreten Fall kann ich das nachvollziehen. Klingt stimmig, der Apache antwortet für
https://j-berkemeier.de/RitzelrechneR.html
mit HTTP 301 Location:
https://j-berkemeier.de/Ritzelrechner.html
Perfekt. Alles gut.
Das Beispiel mit der fehlenden Extension sollte nur zuverlässig zeigen, wann der 300er kommt.
Verstehe, Dir ging es ums Prinzip. Mir aber auch: erkläre mir den Sinn von HTTP 300 ;-)
Die Seite a.de ist gut in den Suchmaschinen platziert und soll nach b.de umgezogen werden. Wie mache ich das ohne meine Suchmaschinen-Platzierung zu verschlechtern?
Alle Requests auf a.example.org per HTTP 301(!) nach b.example.org weiterleiten. Best practice. Nach allem, was ich bislang dazu gelesen und in Erfahrung gebracht habe: Dein Ranking bleibt dabei erhalten.
