Suchmaschinenoptimierung

[chris]

Hallo Simon,

Weil er deine start.html noch im Index hat. Mit deinem sitemap sagst du Google, dass es die start.html nicht mehr gibt. In Wirklichkeit gibt es die start.html aber noch. Glaube ja nicht, Google vertraue deinem Googlesitemap.

Wie kommt Google dazu die start.html URL zu indexieren? Diese URL taucht nirgends auf der Website auf! Mit der Googlesitemap Extension teile ich ja Google nicht nur per Sitemap mit, dass es diese URL nicht gibt, sondern die Extension biegt auch noch den entpsrechenden Menülink zur Startseite im Frontend auf die unspezifische URL um! Woher zum Teufel hat also Google die Information, dass es die .../start.html gibt?

LG Chris

[bekanntmacher]

Gründe:

1. Bevor du die Erweiterung installiert hast, gab es die start.html und Google hat die Seite damals indexiert.
2. Irgend ein User Linkt auf die start.html

[chris]

Ich habe soeben jeden verdammten einzelnen Link zu der Webiste , wie ihn die Webmastertoools mir zeigen verfolgt (und das waren gerade mal 45 Links), aber Keiner von denen verlinkt die /start.html!!!!
ein externer Link kann es schon mal mit Sicherheit nicht sein.

Darüber hinaus habe ich die www.afa-ag-partner.de 100%ig nur mit dem Goolgesitemap-Tweak online gestellt. Da bin ich mir mehr als nur sicher (bei der Kongress-Seite weiß ich es zugegebenermaßen nicht mehr genau). Und dennoch hat Google beide verdammte Startseiten irgendwie indiziert. Das nervt!

Jetzt kommts aber noch härter: In den Webmastertools erscheint plötzlich zusätzlich noch eine mir vollkommen unbekannte, dritte URL, die tatsächlich auch zu meiner Startseite führt!!
doppelter_metatag.jpg

Auf dumm hab ich mal die ID am Ende der URL abgeändert (/?page_id=12)... egal, welche Nummer man dafür eingibt, es wird immer die Startseite ausgespuckt!!!!

Das ist nun wirklich echt UNGLAUBLICH!
Die einzige Chance , die man jetzt noch hat, ist bei den Webmastertools unter Parameterbehandlung den entsprechenden Parameter auszuschließen...
parameterbehandlung.jpg

Hallooooo? Was läuft hier bei TL schief? Oder mache ich hier irgend etwas gründsätzlich falsch?

Grüße Chris

[chris]

Die einzige Chance , die man jetzt noch hat, ist bei den Webmastertools unter Parameterbehandlung den entsprechenden Parameter auszuschließen...

Okay, alternativ wäre da noch ne Rewriterule möglich, aber das macht den Kohl auch nicht mehr fett. Ob so oder so, ich habe das Gefühl, Typolight macht einem das Leben in dieser Hinsicht nicht gerade leicht.

[ways2web]

Hallo Simon,
Wie kommt Google dazu die start.html URL zu indexieren? Diese URL taucht nirgends auf der Website auf! Mit der Googlesitemap Extension teile ich ja Google nicht nur per Sitemap mit, dass es diese URL nicht gibt, sondern die Extension biegt auch noch den entpsrechenden Menülink zur Startseite im Frontend auf die unspezifische URL um! Woher zum Teufel hat also Google die Information, dass es die .../start.html gibt?

LG Chris

warum nutzt du TL nicht, um das problem wenigstens temporär zu lösen?
das hab ich so getan, ich nutze nen 301er, weil ich zu beginn des Projektes auch noch eine Startseite hatte, die einen anderen Dateinamen trug..und leider Indiziert. in der zwischenzeit kannst du ja dem Problem auf den Grund gehen.

wenn, und das dauert ja bekanntlich eine weile bei Google, die Seite aus dem index genommen wird, weil diese durch eine neue sitemap.xml nicht mehr aufgenommen wird, kannst du ja auch den 301er löschen..

bei mir funktionierte das in kombi mit robots.txt super....

[vega]

Hallo,

ich hätte da noch ne Frage bzgl. der Fallback-Sprache.

Ist es sinnvoll dieses Feature abzustellen um zu vermeiden dass ein Suchmaschinen Bot nur die Fallback-Sprache crawlt?
Oder wäre es besser für jeden Startpunkt einer Website (jeder Sprache) eine eigene Domain zu verwenden u. Sprachen-Fallback aktiviert zu lassen?

greetz
vega

[Bobi]

Gibt es eine Möglichkeit im Navigationspfad (Breadcrumb) der Startseite nicht domain.de/index.html sondern lediglich domain.de mitzugeben?

Bzw. würde das in dem Rahmen nicht auch Sinn machen anzupassen?

LG
Bobi

Edit: Oben überlesen mit Navi- sorry.....da gehört die Breadcrumb ja dazu

[chris]

@ways2web

warum nutzt du TL nicht, um das problem wenigstens temporär zu lösen?

Wo ist der Unterschied zu...

Okay, alternativ wäre da noch ne Rewriterule möglich, aber das macht den Kohl auch nicht mehr fett.

Ob ich nun ne Htaccesszeile schreibe oder in TL ne 301 setze dürfte doch vollkommen egal sein.

Da fällt mir aber ein, wie kann man denn in der Seitenstruktur die 301 Umleitung setzen, damit von domain.tld/start.html zu domain.tld/ umgeleitet wird? Andersrum ist es ja klar (einfach eine 301 Seite in der Seitenstruktur vor die start.html setzten und auf diese umleiten lassen) aber dass es umgedreht auch auch ginge, wäre mir neu.

Und davon abgesehen ist mir noch immer vollkommen schleierhaft, woher Google die domain.tld/?page_id=12 bekommen hat. Eine solch parametrisierte URL wurde 100%ig nie angeboten, da ich von vornherein nur mit Aliasen gearbeitet habe.

@Vega

ich hätte da noch ne Frage bzgl. der Fallback-Sprache.
Ist es sinnvoll dieses Feature abzustellen um zu vermeiden dass ein Suchmaschinen Bot nur die Fallback-Sprache crawlt?

Gegenfrage: was passiert denn wenn du dieses Feature abstellst und es kommt jmd mit einer anderen Browserspracheinstellung auf deine Seiten?

@Bobi

Gibt es eine Möglichkeit im Navigationspfad (Breadcrumb) der Startseite nicht domain.de/index.html sondern lediglich domain.de mitzugeben?

Ich habe bisher in TL noch keine Breadcrumbs genutzt. Aber wenn die Googlesitemap Extension schon alle Startseiten Links im Frontend auf die domain.tld/ umbiegt, tut sie das dann nicht auch im Navigationspfad?

[Bobi]

Sorry, GoogleSitemap habe ich noch nicht installiert - werde ich nun mal machen.


Edit: Mit der Erweiterung funzt natürlich alles wunderbar

[bekanntmacher]

@vega

Ich empfehle dir, die Sprachen auf unterschiedliche Domains zu verteilen. Nur so kannst du einen sprachspeziefischen Backlinkaufbau machen. Es hat auch noch weitere Vorteile bezüglich SEO.

Auf automatische Spracherkennung würde ich generell verzichten. Hat in meinen Augen auch bezüglich Usability grosse Nachteile. Wenn du die Sprachen auf unterschiedliche Domains verteilst, brauchst du ohnehin keinen Automatismus. Lass doch lieber den User entscheiden, welche Sprache er bevorzugt.

Gruss

[Bobi]

@vega

Auf automatische Spracherkennung würde ich generell verzichten. Hat in meinen Augen auch bezüglich Usability grosse Nachteile.

Gruss

Kannst du das bitte mal aufschlüsseln?
Ich finde eigentlich es hat Usability technisch eher Vorteile.

Ich meine dazu gibt es ja die Möglichkeit, das der Browser die Sprache erkennt....und wer was anderes will kann immernoch "händisch" per Flagge auf die andere Sprache springen...

[chris]

Ich störe eure Unterhaltung nur ungerne, aber weiß bitteschön irgend jemand hier, wie es sein kann, dass Google plötzlich seitenintern einen parametrisierten Link findet (www.domain.tld/?page_id=12) den es nicht geben darf und den ich auch nicht auf den Seiten finde? Schließlich arbeite ich ausschließlich mit Aliasen und das von Anfang an.
WMT_interne_links.jpg

[FloB]

Immer mit der Ruhe. Das ist alles andere als ein Drama, deswegen wirst du nicht wegen DC abgestraft.

Warum die URL mit ID gelistet wird, wird dir keiner sagen können. Vielleicht gab es irgendwann mal einen Link zu dieser URL (vielleicht sogar noch vom "Vorgänger"?). Ist doch einfach über eine schneller Rewrite-Rule zu erledigen.

Du kannst sie home.html, start.html oder default.html nennen... es ist vollkommen egal, solange sie nicht genau index.html genannt wird, kann Google einen DC dahinter vermuten, weil es ja nicht die Apachekonfiguration kennen kann.

Google darf dahinter keinen (absichtlichen) DC vermuten, da es eben möglich ist den Default selbst zu bestimmen. Ist doch auch nicht schwer festzustellen, welche URL die Startseite ist – Pseudocode (JS-Style):

req1.url = 'domain.tld';
req1.content = getContentIfHttp200(req1.url).stripMarkup().normalize();

req2.url = 'domain.tld/default.htm';
req2.content = getContentIfHttp200(req2.url).stripMarkup().normalize();

if( req1.content != req2.content )
{
	doIndex(req1);
}
else
{
	markAsHome(req2.url);
}

Wie du siehst, kein Hexenwerk. Und selbst wenn Google soetwas nicht macht: Bei DC wird erstmal geschaut, wer alles worauf verlinkt, dann wird der vermutlich richtige Link indiziert – und da ist es ehrlich schnurzegal, ob das jetzt mit oder ohne leerem Query-String ist. Der "Link-juice" ist nicht so gefährlich, wie von vielen behauptet wird (sonst müsste Google mal seinen halben Index rausschmeißen, weil es so viel "DC" gibt).

Leider nur wenn man das Problem erkannt hat und dann auch noch gewillt ist seine Startseite so zu bennenen wie du!

Man beachte die Anführungszeichen in meinem Zitat, auf das du dich beziehst: Es ist eigentlich kein Problem. Da gibt's auch nichts zu erkennen oder etwas dagegen zu unternehmen.

Glaubst du nicht auch Google könnte schon ein klein wenig genervt sein, wenn überhaupt DC auftritt, auch wenn es nur bei der Startseite so ist? […] Und damit die Leute auch aus Fehlern lernen, haben sie die Webmastertools ins Leben gerufen.

Der böse Google-Bot kommt gleich vorbei und versohlt dir den Hintern
Ne, ehrlich: Die Tools wurden ins Leben gerufen, um die Fehler bestmöglich zu vermeiden, das stimmt. Aber: Es geht viel mehr darum die horrenden (Zahlen) von Fehlern zu vermindern. Ganz verhindern kann man es eben nicht (außer man setzt pur auf statische Seiten, und selbst da gibt es das "Startseiten-DC-Problem").

Wenn du mir schon nicht sagen willst, welches "Prinzip" ich nicht verstanden habe (siehe Posting zuvor), […]

Du musst einfach schauen, in welchem Zusammenhang ich das gesagt habe. Ich bezog mich auf Folgende Aussage von dir:

Was wäre denn daran nicht praktikabel, der Wurzelseite zB. wie einer regulären Seite Artikel einverleiben zu können, gleichzeitig aber noch die Möglichkeit zu haben ihr einen Alias zu geben (zB "start")?

… woraufhin ich erklärte, dass die Wurzelseite keine "Seite" an sich ist, sondern ein virtuelles Konstrukt ist. Die Startseite ist immer die erste Seite innerhalb der Unterseite.
So viel zum Prinzip.

[…] sag mir wenigstens, was du mit Plattitüden meinst.

http://de.wikipedia.org/wiki/Plattit%C3%BCde
In einem deiner Beiträge findest du besonders viele davon.

oder Leo ändert den Core so wie ich vorgeschlagen habe:

1. alle DC URL's sollen eine 404-Fehlerseite zurückgeben
2. der Link in der Navigation auf die Startseite soll domain.tld/ lauten

Ein 404er wäre SEO-technisch eine Katastrophe, auch die Usability leidet darunter extrem. Warum hier nicht per permanent redirect auf die richtige Seite weiterleiten? Diese Methode wird von den SuMas empfohlen! Ein 404er sagt nur, dass es keine passende Antwort zur Frage gibt. Da hilft auch (den SuMas) kein "Hilfetext", der auf die richtige Seite verweist. Dafür gibt es wie gesagt 301.

Zitat RFC 2616, Sektion 10:

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible.

Den zweiten Punkt könnte man (optional) einbauen. Auch eine automatische Rewrite-Rule auf URLs ohne "index.php/" ist in meinen Augen sinnvoll (eben wenn URL-Umschreibung aktiv ist).

Okay, alternativ wäre da noch ne Rewriterule möglich, aber das macht den Kohl auch nicht mehr fett. Ob so oder so, ich habe das Gefühl, Typolight macht einem das Leben in dieser Hinsicht nicht gerade leicht.

Die Rewrite-Rule (mit permanent redirect) ist hier die einzig richtige Lösung. Du musst der SuMa ja sagen, dass sie die Seite woanders findet.

Auf automatische Spracherkennung würde ich generell verzichten. Hat in meinen Augen auch bezüglich Usability grosse Nachteile.

Also wenn eine automatische Sprachenerkennung keine Usability ist, dann frag ich mich, was du unter Usability verstehst.

Die automatische Sprachenerkennung schließt nicht aus, dass man spezifische Domains (Google empfiehlt im übrigen statt Subdomains / virtuellen Unterverzeichnissen die korrekten Länder-TLDs zu nutzen) nutzt – das wäre vielmehr eine Erweiterung der Funktionalität.

Auch ist der Nutzer in seiner Sprachwahl nicht eingeschränkt, wenn man entsprechende Schaltflächen zum Wechsel der Sprache zur Verfügung stellt. (Hier sei gesagt, dass ich es schade finde, dass TL nicht out-of-the-box zumindest Teile der Funktionalität von changelanguage bietet.)


Ich stelle fest, dass SEO ohne grundlegende Kenntnisse des HTTP-Protokolls zu groben Fehleinschätzungen und Missinterpretationen führt.

[bekanntmacher]

wer was anderes will kann immernoch "händisch" per Flagge auf die andere Sprache springen...

Du sagest es, wer will, kann die Sprache händisch wechseln!

- du navigierst aus Frankreich eine Deutsche Seite an??
- du hast einen Englischen Browser??
- an öffentlichen Clients??
- etc.

Welche Argumente sprechen für eine automatische Erkennung?

[FloB]

Wie oft schaust du dir im Ausland bestimmte Websites an? Bist du mit "deinem" Gerät unterwegs (Laptop, Smartphone)? Wie viel Aufwand ist es in den wenigen Fällen, in denen die "falsche" Sprache geliefert wird, mit einem Klick auf der richtigen Sprache zu landen?

Edit: Vergleiche den Aufwand, wenn alle "ausländischen" Besucher immer die "falsche" Sprache zu sehn bekommen! Das mag für lokal begrenzte Seiten funktionieren, aber sobald du ein internationales Publikum ansprechen willst, ist die automatische Erkennung die richtige Methode.

[bekanntmacher]

@FloB

Gut, du hast ne andere Meinung. Ich überlasse es dir, ob du den Automatismus brauchst oder nicht. Darum sagte ich ja ...würde ich... in meinen Augen...

Betreffend DC-Problem braucht es keine weitere Diskussion mehr. Das Ticket von mir wurde angenommen und das Problem somit angegangen. Die Vorteile von einer 404-Lösung kannst du ev. mit deinen Kenntnissen nicht nachvollziehen, aber wie gesagt das Problem wird behoben.

Gruss und frohes Schaffen

[Bobi]

Du sagest es, wer will, kann die Sprache händisch wechseln!

- du navigierst aus Frankreich eine Deutsche Seite an??
- du hast einen Englischen Browser??
- an öffentlichen Clients??
- etc.

Welche Argumente sprechen für eine automatische Erkennung?

Richtig - Wer will - kann die Sprache händisch wechseln.

Usability = Benutzerfreundlichkeit

- du navigierst aus Frankreich eine Deutsche Seite an??
-> Wenn ich mit meinem deutschen Browser komme(wenn ich in Frankreich bin, hab ich mein Laptop oder mein Handy dabei.. - also doch garkein Problem
Muss ich in ein Internetcafe - gehe ich davon aus das der Browser English oder Französisch ist - WoW, da muss ich dann halt die deutsche Flagge anklicken

Wer als Deutscher in D einen englischen Browser hat, hat diesen auch weil ER es selber will - sonst gibt es keinen Grund hierfür - Dann ist er es gewohnt und gewollt, wenn er eine deutsche Seite sehen will, die deutsche Seite anzuwählen.
Öffentliche Clients? - Also bitte, wieviel deiner Surfzeit verbringst du an öffentlichen Clients?

Als kleines Beispiel aus dem Leben: Wenn du in Deutschland in einem deutschen Geschäft bist, fängst doch auch nicht erstmal an den Verkäufer auf English, oder Spanisch oder sonst eine Sprache anzusprechen, oder?
Oder fragst du Ihn erst ob er gerne Deutsch, Englisch oder Französisch sprechen würde?

Das ist Usability - wenn du dem Browser automatisch sagst, welche Sprache er nehmen soll - natürlich gerne mit Fallback Sprache ausgestattet - Bei den wenigen %, bei welchen es nicht passen sollte, die dürfen gerne ein Knöpfchen drücken

[FloB]

Die Vorteile von einer 404-Lösung kannst du ev. mit deinen Kenntnissen nicht nachvollziehen, aber wie gesagt das Problem wird behoben.

Ja, das Problem wird behoben, du holst dir dabei aber noch ein neues ein. Was ist jetzt besser?


Damit bin ich endgültig aus der Diskussion 'raus. Ich kann meine Zeit besser verschwenden. Es wurde alles gesagt.

[chris]

@FloB
Nun lass dich mal nicht aus der Ruhe bringen von so kleinen Provokationen ("mit deinen Kenntnissen nicht nachvollziehen"), da kannste doch drüberstehen, oder?
Dein Chefgebiet ist ja sowieso eher das Coden und die selbsternannten SEO Profis brauchen ja auch ein Chefgebiet

Ist doch einfach über eine schneller Rewrite-Rule zu erledigen.

Ja alles ist einfach. Aber es wird irgendwann einfach zu viel des Einfachen. Dann nervt es nur einfach noch.

Dein nettes Pseudocodebeispiel zeigt übrigens eindrücklich, dass TL durch das Startseitenproblem den Suchmaschinen Arbeit aufhalst. Das wollen sie aber nicht. Darum gibts unter Umständen auch kleine Abstrafungen vielleicht auch nur aus der erzieherischen Absicht heraus, nach Fehlerbehebung eine entsprechende Besserplatzierung bieten zu können. Keiner kann das genau wissen. Sinn würde es aus Googleperspektive jedenfalls sicherlich machen.

Dazu kommt noch, dass die ganzen WMT-Vorschläge zu den doppelten Metatags, Seitentiteln usw. ja nun wirklich nicht sein müssen. Jeder, der sich da nicht in die Problematik vertieft hat, wird verunsichert sein und beginnen nach der Problemlösung zu suchen. Also selbst wenn es überhaupt kein Problem wäre, wie du behauptest, dann verursacht es dennoch diesen Aufwand.

woraufhin ich erklärte, dass die Wurzelseite keine "Seite" an sich ist, sondern ein virtuelles Konstrukt ist. Die Startseite ist immer die erste Seite innerhalb der Unterseite.
So viel zum Prinzip

Was auch immer du da erklärst. Eine status quo Prinzipienfrage ist doch vollkommen irrelevant. Wir reden doch von einem Vorschlag, der das aktuelle Prinzip ja gerade in Frage stellt. Ist es denn nicht möglich das virtuelle Konstrukt der Wurzelseite in irgendeiner Weise direkt auf die Starttseite anzuwenden?

Zitat Zitat von chris Beitrag anzeigen
[…] sag mir wenigstens, was du mit Plattitüden meinst.
http://de.wikipedia.org/wiki/Plattit%C3%BCde
In einem deiner Beiträge findest du besonders viele davon.

Also in Wikipedia steht ja teilweise schon echt abgefahrenes Zeugs drin. Eine Plattitüde sei eine "...inhaltslose Redewendung, die wenig über den Sprecher aussagt."
Seit wann dienen denn Redewendungen dazu etwas über den Sprecher auszusagen?

Wie du selbst schreibst, sagst du ja, dass das Umbiegen der URL auf die unspez. Startseite durchaus sinnvoll wäre. Siehe hier...

Den zweiten Punkt könnte man (optional) einbauen.

Folgerichtig wird der Außenwelt ja nur vorgegaukelt, dass es die start.html nicht gibt. Dann wäre es doch nur konsequent die "virtuell" nicht existierenden Seite auch in der Realität nicht existieren zu lassen, indem man ihr einen 404 Statuss gibt. Du aber sagst:

Ein 404er wäre SEO-technisch eine Katastrophe, auch die Usability leidet darunter extrem.

Verstehe nichtt wo das Problem sein soll. Weder SEO technisch noch was die Usability betrifft.

Ja, das Problem wird behoben, du holst dir dabei aber noch ein neues ein. Was ist jetzt besser?

Irgendwie stehe ich auf dem Schlauch. Welches ist denn das neue Problem?

Grüße
Chris