HTML Sitemap mit +10.000 internen Links

[ChristianM]

Hallo liebe SEO-Gemeinde,

ich habe da mal ein Anliegen. Stellen wir uns vor wir bauen eine User-Sitemap mit mehr als 10.000 internen Links, das könnten auch 40.000 links sein.

Wir könnten uns nun vorstellen das diese 40.000 Links zum Beispiel zu den Produktpages, in diesem Beispiel unsere Moneypages, verlinken. Jedes Produkt bekommt ein kleines preview Bild mit vielleicht einem Satz an Informationen bzw. 2 Sätzen.

Das ganze könnte man normal machen oder aber auch mit Ifinite Scrolling, das gibt doch Performance Probleme oder? Es geht mir hier jetzt gar nicht so sehr um Google, zur not macht man daraus noindex, follow.

Mein größtes Problem ist wohl eher, ob sich diese massive Anzahl an Links und Bildern (wenn auch nur klein) so sehr auf die Performance auswirkt, dass man dies besser unterlassen sollte.

Gibt es dazu einige Erfahrungen? Ich freue mich über Antworten!

[Hanzo2012]

Was meinst du mit "Performance" im Zusammenhang mit Sitemaps?

[ChristianM]

Es handelt sich in diesem Beispiel um eine HTML Sitemap, keine XML Sitemap. Es ist also eine normales HTML Dokument. Diese Seite würde ja wie im Beispiel beschrieben recht groß werden, macht das Performancetechnisch Sinn? Nicht dass dann die Seite so schwer ist das sie gar nicht mehr wirklich funktioniert, werde ich so oder so testen, wollte aber mal Fragen, ob da jemand was zu sagen kann.

[Hanzo2012]

Achso ... die Ladezeit wäre vermutlich sehr groß, und es könnte gut sein, dass ein Browser die Seite ziemlich "ruckelig" rendern würde. Welchen Sinn hätte denn so eine Seite für einen Benutzer überhaupt?

[ChristianM]

@Hanzo2012

Gut das du fragst, das wollte ich eigentlich auch noch vorweg nehmen: Bitte keine Antworten, wie "Soviele Links machen keinen Sinn, lern mal SEO" :p

Also ich kann hier natürlich nicht im Detail darüber reden aber sagen wir es mal so, mit einigen Überlegungen und Filtersystemen kann der User aus quasi 40.000 Produkten innerhalb von 2 Sekunden genau die auswählen, die er gerne hätte. Das ganze hat nur Usability im Kopf, naja und interner Saft natürlich.

[Efferd]

Hallo,

es müssen dann aber auch 40.000 Bilder auf einem html dokument geladen werden.

Da kommt mir eine ganz andere Frage - wenn das 10 Besucher nun gleichzeitig machen, muss der Server 400.000 Bilder zur verfügung stellen quasi.

Das könnte nicht nur den Browser in die Knie zwingen. Egal wie - ich würde es auf jeden fall Aufteilen. Egal wie gut und strukturiert es auf einer Seite dagestellt wird, es sind und bleiben 40.000 "Auswahlmöglichkeiten" für den Benutzer.

[Efferd]

Ups, Filter und Co hört sich anders an. Das hatte ich beim schreiben meines Beitrages noch nicht gesehen... War zwischendurch nen Kaffee holen *g*

[Hanzo2012]

Bilder kann man direkt im HTML-Code einbetten. Sie sind dann jedoch von der Datengröße her etwas größer, aber es werden keine Server-Requests benötigt. Das lohnt sich, wenn sie sehr klein sind.
https://de.wikipedia.org/wiki/Data-URL

[ChristianM]

@Efferd

Ja ich denke auch man muss es aufteilen. Auswahlmöglichkeiten sind ansich eher weniger. Man könnte ja Beispielsweise eine Sitemap machen mit 2 Auswahlmöglichkeiten "Preis" und "Hersteller" - einfach mal angenommen - Aber ja, ich denke das muss aufgesplittet werden bzw. man muss da etwas anderes finden, die Seite würde defintiv zu groß, vor allem wenn man es unbedingt mit Bildern machen (so wie ich) wird zuviel performance verschwendet. Argh, man kann halt nicht alles haben

[Hanzo2012]

*bitte löschen*

[ChristianM]

@Hanzo2012

Ja das stimmt, kann man machen. Aber ich denke diese enorme Anzahl an Bildern, auch wenn man sie zb durch infinite scrolling nachläd (bleiben dennoch im html code enthalten) ist das eine schiere Masse, wobei ich jetzt nicht genau weiß wie das aussieht wenn sie nachgeladen werden, dann dürfte der Browser das zumindest gut überleben und bricht nicht gleich zusammen.