SEO für Produktseiten

  • Hallo,
    Situation: Online-Shop mit ca. 50 Produkten, die alle auf /produkte/produkte.php aufgeführt sind (gegliedert nach Produktkategorien, untergliedert nach Produktarten). Wählt ein Besucher über die Navigation eine Produktkategorie / -gruppe, etc., wird er auf eine Auswahl-Seite mit gleicher URL (/produkte/produkte.php) geführt.
    Problem: es gibt keine statischen Seiten mit Produktkategorien /-gruppen, etc. –Seiten, die für SEO optimiert werden können.
    Frage: welche technische Lösung wird empfohlen? Ich denke daran, statische Produktseiten mit POST oder GET zu erzeugen. Diese würden aus den entsprechenden Teilen von /produkte/produkte.php bestehen. Welche anderen Möglichkeiten kommen in Betracht und welche Vor- und Nachteile hat GET gegenüber POST?
    Freue mich auf eure Antworten!

  • Hallo Jeanette, erstmal willkommen im Forum.

    Son Salat mit get und post gehört zwar niemals auf meine Baustelle, dennoch wäre es zwecks Problemlösung enorm hilfreich, das Gerüst Deiner Seite zu kennen, also ob es sich um ein CMS handelt, wenn ja welches usw.

    *** Link veraltet ***

    Er war Jurist und auch sonst von mäßigem Verstand.

    (Volker Pispers)

  • Hallo Jeanette, anamaria oder wie auch immer :)

    Wir sind hier also schneller :) Auch ich würde hier nach der Seite nachfragen...

    Da das wohl alles überall und immer über die URL /produkte/produkte.php geht, auch wenn es verschiedene Produkte sind, müsste da wohl eine Session, ein Frame oder Javascript im Spiel sein. Kann mich da aber auch täuschen und hab es vielleicht nur falsch verstanden...

    Zitat

    Welche anderen Möglichkeiten kommen in Betracht und welche Vor- und Nachteile hat GET gegenüber POST?


    Prinzipiell erst mal nur GET, zumindest zu 99%.

    GET ist jeder normale Zugriff auf eine Webseite. POST ist in aller Regel ein Formular, das gesendet, also gePOSTet wird.

    GET wird von Suchmaschinen problemlos aufgenommen bzw. erfasst, POST nicht unbedingt. Da Du hier also von SEO-Optimierung redest wird es wohl GET werden. POST macht an manchen Stellen durchaus Sinn, aber nicht für SEO.

    Grob gesagt, eine Navigation mit den einzelnen Bereichen und jeweils eine eigenständige Seite mit den jeweiligen Produkten aus dem Bereich.

    P.S. @mod / Admin... Meine Smilies gehen nicht *heul*

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Jo, der klassische Crosspost wird perfektioniert. Who cares? Das Prinzip ist annähernd so alt, wie die weiblichen Nicks für bestimmte Zwecke. Wenns denn hilft ^^

    ---

    Die Smilies hat Alex beim Relaunch gleich mit gekillt, aber er ist schon dran.

    Er war Jurist und auch sonst von mäßigem Verstand.

    (Volker Pispers)

  • @ Margin und Synonym. Gebe zu: erwischt! Meine Kollegin ist schon ne Weile woanders angemeldet und wir wollten einfach mal drei (soviele waren's) Foren auf Qualität und Geschwindigkeit testen, weil wir uns auf eines konzentrieren wollen. Und ja, Synonym: ihr seid noch immer die Schnellsten.

    Kein CMS, alles in PHP geschrieben. /produkte/produkte.php enthält alle Produkte. Weil diese aus unterschiedlichen Produktkategorien stammen, unterscheiden sich die entsprechenden Suchanfragen (auf die SEO erfolgen soll) teilweise erheblich.
    Unser Gedanke: wir belassen die /produkte/produkte.php wie sie ist und erzeugen aus den Blöcken dieser Seite mehrere statische .php-Seiten (für jede Produktkategorie eine). Jede dieser Produktkategorie-Seiten wollen wir auf die entsprechenden Suchanfragen optimieren. Diese statischen Seiten wollen wir mit GET erzeugen. Jede dieser Produktkategorie-Seiten soll eine individuelle (SEO-optimierte) URL haben und als statische Seite von den Robots gelesen werden können.
    Der Vollständigkeit halber: bei drei dieser Produktkategorien ist es sinnvoll, neben den Produktkategorie-Seiten auch Produktgruppen-Seiten zu erzeugen (macht inhaltlich und nach Suchanfragen Sinn). Es handelt sich also insgesamt um 4 Ebenen: 1. /produkte/produkte.php, 2. Produktkategorien, 3. Produktgruppen, 4. Einzelprodukt.

    Bevor wir uns an die Arbeit machen, wollen wir den Rat aus Foren einholen. Ich sehe das auch so, dass die POST-Methode eher für Formulare geeignet ist und GET (wie in den meisten Fällen) die vorteilhaftere Methode ist. Vielleicht hat aber jemand auch eine Idee, auf die wir nicht kamen. Und überhaupt: auch im Umgang mit Foren macht Übung wohl den Meister.

    Gruß Jeanette

  • Moinsen,

    also, wenn das nur ca. 50 Artikel sind, würde ich schlichtweg das Shopsystem wechseln und was vernünftiges aufsetzen.
    Was Vernünftiges, das SEO ohne grosses rumgefrickle zulässt.
    Die alten, indexierten/verlinkten URL kannste immer noch per .htaccess umbiegen.
    Dann kannste auch für jeden Artikel und jede Artikelgruppe Landingpages anlegen, was zwar Anfangs Zeit kostet, sich aber (wenn man es richtig macht) auf jeden Fall auszahlen wird: In besserem Ranking und Cash.

    Mal ein Beispiel für Artikelseiten/Artikelgruppenseiten:
    Startseite: *** Link veraltet ***
    Artikelgruppenseite: *** Link veraltet ***
    Artikeluntergruppenseite: *** Link veraltet ***
    Artikelseite: *** Link veraltet ***

    Nicht, daß Du jetzt ein Magento wegen 50 Produkten aufsetzen solltest... aber ein vernünftiges System macht so eine Gliederung fast von alleine.

    Nachschlag:
    Wenn Du ein gutes System hast, kannst Du auch die interne Suche verwenden, um Artikel nach Länge/Breite/Preis/Farbe/Artikelnummer zu sortieren, bzw. anzeigen zu lassen.
    Sowas wie z.B. hier: *** Link veraltet *** (Schals und Tücher aus Baumwolle/Seidenmischungen in einer Breite von 45cm.
    Dann wirft man diese URL in den Shopinternen URL-rewriter und macht was draus wie: http://example.com/schals-45-cm-breite-sonderangebot.html
    Und schon haste eine Landingpage. Ich könnte da jetzt noch einen SEO-Text reinmachen, der nur auf dieser speziellen Seite erscheint.

    Wer zuerst "Datenschutz" sagt, hat verloren.

  • Genau das wars, was mich auch gewundert hat, "nur" 50 Produkte. Mochte nur nix sagen, weil ich ja selber bekanntlich keine Shops betreibe. Aber bei 50 Stück würd ichs ohne überhaupt zu überlegen gleich sauber aufsetzen - stabiler, schneller usw.

    Er war Jurist und auch sonst von mäßigem Verstand.

    (Volker Pispers)

  • Zitat von Jeanette;17743

    Kein CMS, alles in PHP geschrieben. /produkte/produkte.php enthält alle Produkte.


    Gut, ein CMS ist meist auch in PHP. Du meinst wohl eine eigene Entwicklung, oder? Wenn ja, dann sind da die Möglichkeiten ja am einfachsten und nahezu unbegrenzt.

    Zitat von Jeanette;17743

    Unser Gedanke: wir belassen die /produkte/produkte.php wie sie ist und erzeugen aus den Blöcken dieser Seite mehrere statische .php-Seiten (für jede Produktkategorie eine). Jede dieser Produktkategorie-Seiten wollen wir auf die entsprechenden Suchanfragen optimieren.


    Soweit also klar. Eine Seite "produkte.php" mit allen und dann jeweils eine für den einzelnen Bereich. Da müsst Ihr dann aber auch auf DC achten, denn die Produkte der "Kategorieseite" sind dann ja auch auf der "Übersichtsseite".

    Zitat von Jeanette;17743

    Diese statischen Seiten wollen wir mit GET erzeugen. Jede dieser Produktkategorie-Seiten soll eine individuelle (SEO-optimierte) URL haben und als statische Seite von den Robots gelesen werden können.


    Verständlich. GET ist auch normal und hier eher fehl am Platz zu diskutieren :)

    Zitat von Jeanette;17743

    Der Vollständigkeit halber: bei drei dieser Produktkategorien ist es sinnvoll, neben den Produktkategorie-Seiten auch Produktgruppen-Seiten zu erzeugen (macht inhaltlich und nach Suchanfragen Sinn). Es handelt sich also insgesamt um 4 Ebenen: 1. /produkte/produkte.php, 2. Produktkategorien, 3. Produktgruppen, 4. Einzelprodukt.


    Klingt logisch. Aber wie gesagt auf DC achten, denn die Produkte der hinteren Seite sind ja auch in der übergeordneten. Also verschiedene Gruppen sind gleichzeitig ein einer Kategorie. Und verschiedene Kategorien sind gleichzeitig auf der "/produkte/produkte.php"

    Zitat von Jeanette;17743

    Bevor wir uns an die Arbeit machen, wollen wir den Rat aus Foren einholen. Ich sehe das auch so, dass die POST-Methode eher für Formulare geeignet ist und GET (wie in den meisten Fällen) die vorteilhaftere Methode ist. Vielleicht hat aber jemand auch eine Idee, auf die wir nicht kamen. Und überhaupt: auch im Umgang mit Foren macht Übung wohl den Meister.


    Nur GET macht hier sind. POST ist nicht eher für Formulare, sondern eigentlich nur. Man kann es "missbrauchen" oder auch Formulare per GET machen, aber POST ist ein Formular. Ob das nun HTML-technisch ein Formular ist oder nicht ist egal, POST ist ein "Sende-Command"

    Wegen dem Shopwechsel: Das ist natürlich so eine Sache, die man für sich selbst entscheiden muss. Bei 50 Produkten, die eventuell nicht oft geändert werden und auch nicht sonderlich mehr werden, würde ich da eher kein Shop-System nehmen. 50 Produkte kann man auch per Hand anlegen und im eigenen Script hat man mehr Möglichkeiten als in einem CMS. Das ist aber eine Sache der persönlichen Einstellung.

    CatCat hat das mit der Suche ja auch schon angesprochen. Auch hier die Frage, ob man die braucht oder ob die Trennung der Produkte klar und einfach ist und man als User also gar nicht suchen muss.

    Selbiges mit der Sortierung. Sind es klare Trennungen, bei denen es auch keine Vermischungen gibt, und gleichzeitig nur wenige Produkte in einem Bereich, dann braucht man auch keine Sortierung. Ob nun 5 Produkte aufsteigend, absteigend oder sonst wie sortiert werden ist egal.

    Da passt das mit der Seide auch ganz gut. Möchte ich einen Seidenschal und den gibt es eventuell in verschiedenen Qualitäten in verschiedenen Kategorien, dann wäre eine Suche nicht schlecht. Man weiß ja schließlich nicht wo DER gesuchte nun genau ist.

    Hat man aber ein System mit Kühlschränken und Gefriertruhen, dann braucht man bei geringer Stückzahl eher keine Suche. Wenn man einen Kühlschrank möchte, dann braucht man bei den Gefriertruhen ja nicht zu schauen, also auch nicht zu suchen.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Eine gute, sinnvolle Suche ist essentiell!
    Der Otto-Normal-Shopper kommt über einen Preisroboter oder google.
    Der will z.B. Legoklötze in blau. Daran verdienst Du als Shopbetreiber aber wenig. Also bietest Du ihm noch zig. UpSell/CrossSell und Zubehörartikel an, an denen Du wirklich was verdienst.
    Dann fängt der Otto an, wild rumzuklicken und findet den ursprünglichen Artikel "Legoklotz blau" nicht mehr.
    Also sucht er die Suche. Und wenn er die nicht sofort findet und die auch das richtige Ergebnis ausspuckt, ist er wieder beim Preisroboter oder bei google.

    Oder Otto fällt ein, das er doch eigentlich lieber Klötzchen in lila haben will und es müssen auch keine von Lego sein, sondern die billigeren von Hersteller xyz. Also wieder in die Suche oder besser noch: Eine Sortierfunktion!^^

    Wenn ich hier meine Logs auswerte... alter Schwede! Da wird gesucht, sortiert und verglichen wie im Kaufhaus.

    Zitat von Synonym;17752

    [...]CatCat hat das mit der Suche ja auch schon angesprochen. Auch hier die Frage, ob man die braucht oder ob die Trennung der Produkte klar und einfach ist und man als User also gar nicht suchen muss.

    Wer zuerst "Datenschutz" sagt, hat verloren.

  • Ah, ok... Eine interne Suche für ähnliche Artikel. Stimmt, da macht das Sinn. Ich bezog mich hier nun rein auf eine Suchmaske, die man nicht unbedingt braucht. "Nicht unbedingt" eben bedingt durch das Angebot. Wenn ich nur 4 Kategorien habe mit Lego in blau, gelb, rot und schwarz, dann brauch ich keine Suche dafür, da eindeutig. Wenn es in jeder Kategorie auch nur eine überschaubare Menge Artikel gibt, dann ebenso nicht, da ich die 4, 5 oder 6 ja direkt sehe.

    Wie gesagt, eine Suche ist sinnvoll aber nicht überall nötig, kommt immer auf das System, die Anzahl der Artikel und deren Art an. Z.B. wieder Lego. Möchte ich 2x2 Steine haben, Farbe egal und es gibt viele Artikel, dann wäre eine Suchmaske wieder sinnvoll.

    Hm, aber eben auch nur meine Meinung zu einem wirklich kleinen Shop...

    Für die internen ähnlichen Artikel aber auf jeden Fall, keine Frage.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • Wenn man ganz schlau ist, dann bindet man sogar noch seine eigene google-SuMa ein und lässt nur Ergebnisse der teuren Konkurrenz zu. Dann verdient man ungünstigstenfalls nur am Klick, bestenfalls doppelt, wenn der Kunde erschreckt (wegen der hohen Preise der Konkurrenz) wiederkommt :pfeif:

    Wer zuerst "Datenschutz" sagt, hat verloren.

  • Oder Du legst ne google-SuMa OHNE Werbung an und lässt nur Ergebnisse einiger Deiner eigenen (extra dafür angelegten) Shops zu.
    Die sollten natürlich nicht wie Deine eigenen aussehen und die sollten Wahnsinnspreise haben.

    Das ist auch ganz interessant, wenn man da den Clickstream nachverfolgt...

    Wer zuerst "Datenschutz" sagt, hat verloren.

  • Danke für deine Antwort, catcat. Wir sind ganz bewusst den Weg einer Eigenentwicklung gegangen, um flexibler zu sein.
    Danke auch für dein Beispiel. Wir wollen aber bewusst von jeder Hierachiestufe direkt zur Auftragsabgabe linken. Gründe: Reduzierung der für den Besucher erforderlichen Klicks und Branding (wenn jemand auf unsere Website kommt, soll er auf einen Klick die gesamte Produktpalette sehen können). Unabhängig davon gefällt mir dein Shop!

  • Hab vielen lieben Dank für deine ebenso hilfreiche wie umfassende Antwort, Synonym!

    Ja, ich meine eine Eigenentwicklung - die wir aus genau den von dir genannten Gründen aufsetzten.

    Duplicate Content: ja, das ist eines unser zentralen Probleme. Wir würden versuchen, das in den Griff zu kriegen, indem wir die Hierachieebenen soweit möglich individuell halten (URL, Title und andere Tags, Einleitung, etc.).

    Du hast Recht. Es ging uns aber weniger um POST, als vielmehr um weitere sinnvolle Ansätze als der Erzeugung weiterer Produkt(kategorie, etc.)seiten mit GET. An den Vorschlag mit dem Shop haben wir selbstverständlich auch gedacht.

    Interne Suche ist nicht so sinnvoll (haben wir nachrangig auf unserer To Do Liste), da - wie du beschreibst - es sich je Produktkategorie um eine überschaubare Zahl von Produkten handelt. Eine hohe Bedeutung kommt entsprechend der Navigation zu. Hier sind wir auch kräftig am Grübeln, wie wir v.a. auf der Homepage eine einfache und intuitive Navigation zu den Produktkategorien hinkriegen.

    Dazu passt auch dein Beispiel recht gut. Eine Navigation könnte bspw. aus einer Tabelle bestehen, in der in Spalten für a) den Haus- und b) den Gewerblichen Gebrauch und vertikal 1. Kühlschränke, 2. Gefriertruhen und 3. Kombigeräte (Side-by-Side, etc.) gewählt werden können. Eine andere Navigation führt zu je einer Übersichtsseite mit allen Kühlschränken, Gefriertruhen und Kombigeräten. Die Proroduktbeschreibungen würden alle aus der /produkte/produkte.php stammen, womit man wieder beim DC (als wohl einzigem wirklichen Nachteil des Verfahrens) ist. Die Einzelproduktseiten beinhalten ohnehin detailliertere Beschreibungen, weshalb DC hier wohl eher nicht zieht.

  • Kommt v.a. aufs Angebot und dessen Darbietungsform an. Wenn du bspw. deine Tücher i.R. eines farbtypgerechten persönlichen Erscheinungsbildes mit eigener Brand anbieten möchtest und dabei vom individuellen Bedarf / Typ / Stil ausgehst, vermeidest du eben bewusst Suchen, Kategorien und Vergleiche. Dann kann der Besucher zwar noch immer nach günstigeren Produkten suchen, aber bei dir trohnt eben das berühmte catcat-Signet am für jeden sichtbaren Ende des Tuches, wodurch jeder sieht, dass die Trägerin besonderen Wert auf eigenen Stil legt. Ist natürlich nur ein Beispiel, mit dem ich nicht mal sagen will (und auch gar nicht kann), wie erfolgreich dieses wäre.

    Selbstverständlich sind interne Suchen unabdingbar für Angeobte auf einer Katalog-Seite, die man auch von dutzenden anderen Anbietern kaufen kann. Aber interne Suchen müssen auch unbedingt die Suchergebnisse liefern, die der Besucher sucht. Ansonsten sind die schneller weg als sie da waren.

    Kurzum: viele Websites würden mit verschiedenen Kategorisierungsmöglichkeiten den Besuchern das Finden von Produkten leichter machen als mit internen Suchen. Und genau hier stehen wir momentan.

  • Der DC ist nicht das eigentliche Problem: DC auf der eigenen Site ist für SuMas ja egal.

    >>Wir wollen aber bewusst von jeder Hierachiestufe direkt zur Auftragsabgabe linken.<<
    Tja... das ist der feuchte Traum jedes Shopbetreibers :)
    Das geht halt nur, wenn in der jeweiligen Hierarchie/Kategorie alle passenden Artikel mit Link zum Warenkorb enthalten sind. Dann ist es aber keine Landingpage oder gar Übersichtsseite mehr, sondern der Kunde wird mit einem Haufen Angeboten so zugemüllt, daß er sich gar nicht mehr entscheiden kann (ist bei mir ein grosses Problem) und die Geschichte mit dem SEO wird ziemlich kompliziert.

    Du mußt den Kunden ja sowieso zuerst auf die Detailseite des Artikels schicken (Ok, mußt Du nicht unbedingt, aber es macht Sinn), damit Du ihm die gesetzlich vorgeschriebenen Sachen zeigen kannst. Dann gehts zum Warenkorb, wo er nochmals alle vorgeschriebenen Details (Material, Lieferzeit, Grösse, Menge etc.) vorgesetzt kriegt, die AGB und Widerrufsrecht absegnen muß...

    Wer zuerst "Datenschutz" sagt, hat verloren.

  • Zitat

    Wir würden versuchen, das in den Griff zu kriegen, indem wir die Hierachieebenen soweit möglich individuell halten (URL, Title und andere Tags, Einleitung, etc.).


    Was wieder für ein eigenes, statisches System spricht, vor allem wegen den Einleitungen.

    Zitat

    Interne Suche ist nicht so sinnvoll (haben wir nachrangig auf unserer To Do Liste), da - wie du beschreibst - es sich je Produktkategorie um eine überschaubare Zahl von Produkten handelt. Eine hohe Bedeutung kommt entsprechend der Navigation zu. Hier sind wir auch kräftig am Grübeln, wie wir v.a. auf der Homepage eine einfache und intuitive Navigation zu den Produktkategorien hinkriegen.


    Die Navi ist ohne Suche DAS zentrale Element. Daher auch meine Ausführungen mit klein und klar getrennt. Wenn das zu viele Punkte werden, dann ist eine Suche besser. Bei CatCat sind es z.B. zu viele in der Navi, da weiß man nicht unbedingt direkt wo man hin soll oder ob der Artikel nicht doch wo anders drinnen ist.

    Daher, aber wie gesagt meine Meinung. Ich selbst habe keinen Shop, nur eine Unterkunftsdatenbank (mit Suche), CatCat hat den Shop, ich würde auf eine Suche verzichten und eher über die Navigation gehen, wenn es denn funktioniert (Umfang Art). Gerade bei so was wie CatCat meinte mit den Zusatzartikeln ist eine Suche wichtig, aber die gibt es nicht bei allen Dingen. Bei Artikeln die variieren können, die in verschiedenen Bereichen stehen können etc ist es auch wieder wichtig oder bei Kategorien die sich überschneiden. Wenn das alles nicht der Fall ist, dann ist eine kleine und übersichtliche Navi meiner Meinung nach besser. Wichtig da aber, keine die man erst aufklappen und dann quasi doch "virtuell" suchen muss, sondern eine, bei der man gleich alles sieht.

    Hatte ich erst neulich mal irgendwo. Da war ich auf der Suche nach speziellen Putzmitteln. Überall waren Suchen und die Ergebnisse waren immer alles mögliche das irgendwie passte. Fazit war, ich suchte recht lange und fand Zeug, das ich gar nicht wollte. Eine andere Seite aber, die eines Herstellers war ohne Suche. Dafür gab es da eine nette Navi mit 5 Hauptpunkten und je 3 Unterpunkten. Da konnte man direkt dahin wo man wollte: Pflegemittel -> Naturstein -> Marmor.

    Bei den anderen Suchen, obwohl auch Hersteller kam dann Zeug wie "für Marmor nicht geeignet", "Universalreiniger" etc., das wollte ich aber alles nicht.

    Wenn ein Mensch nicht um dich kämpft, hat er nur gewartet, dass du gehst. ;(

  • @ catcat (direkte Antworten auf einzelne Kommentare scheinen bei mir nicht zu funktionieren): dass DC innerhalb einer Website für Google keine Rolle spielt ist mir neu! Hast du eine Quelle dafür?

  • Hab ich mal auf dem blog von google gelesen und aus eigener Erfahrung gelernt.
    Sonst wären kaum noch Shops gelistet, da die alle mehr oder weniger gigantische Mengen an DC produzieren.

    Ausserdem gibts immer noch die Sache mit dem "Canonical"-Tag, die letztendlich jeden DC "legalisiert".

    Wer zuerst "Datenschutz" sagt, hat verloren.