robots.txt – wie kann man URLs mit ?tmpl=template oder solche mit ? ausschließen?

  • Joomla Version
    4.3.4
    PHP Version
    PHP 8.1.x
    Hoster
    webgo

    Der Titel beinhaltet bereits die Frage:

    Ich möchte erreichen, dass Google keine URLs crawlt und indexiert, die ein Fragezeichen enthalten. Falls das nicht in der robots.txt darstellbar ist, dann benötige ich ersatzweise die Regel, dass URLs nicht gecrawlt werden, die ?tmpl=template enthalten.


    Die URL-Erweiterung ?tmpl=template kommt bei mir immer dann vor, wenn ich einen Beitrag / Artikel in einer Lightbox anzeigen möchte.


    Ohne diese Regel in der robots.txt bekomme ich "DuplicateContent" Reklamationen.


    Im Web habe ich keine Anleitung gefunden, die diesen Fall beschreibt.


    Ist solch eine Regel überhaupt möglich? Wenn ja, wie muss ich die formulieren?

  • Hmmm, wenn ich im Backend die Option "?tmpl=template" filtere, funktioniert der Link, der die Lightbox öffnet und den Artikel pur ohne Header Footer und Navigation in die Lightbox lädt, doch nicht mehr oder?


    Vermutlich verstehe ich aber aktuell nicht, was du damit meinst: Im Backend "beim Index" filtern....

  • Im Backend bei Komponenten /Suchindex /Index.

    Hier werden alle aufgelistet.

    Du kannst über die Suche alle anzeigen lassen. die den von dir genannten Inhalt haben.

    Diese dann deaktivieren und somit aus dem Index ausschließen.

  • Der Titel beinhaltet bereits die Frage:

    Ich möchte erreichen, dass Google keine URLs crawlt und indexiert, die ein Fragezeichen enthalten. Falls das nicht in der robots.txt darstellbar ist, dann benötige ich ersatzweise die Regel, dass URLs nicht gecrawlt werden, die ?tmpl=template enthalten.


    Vielleicht hilft dir DIES weiter.


    Allerdings gibt es auch DIESES zu beachten:
    Zitat daraus:
    "Warnung: Verwende die robots.txt-Datei nicht, um deine Webseiten (einschließlich PDFs und anderer von Google unterstützter textbasierter Formate) vor der Google Suche zu verbergen.

    Wenn andere Seiten mit beschreibendem Text auf deine Seite verweisen, kann Google die URL auch ohne Seitenaufruf indexieren. Wenn du deine Seite aus den Suchergebnissen ausschließen möchtest, solltest du eine andere Methode wie den Passwortschutz oder noindex verwenden."


    VG Wolfgang

  • Je nachdem, wie die Links generiert werden, kann man auch einfach nur rel="nofollow" oder Ähnliches innerhalb von <a> verwenden.

    Siehe z.B. hier: https://developers.google.com/…lify-outbound-links?hl=de


    Wenn man Links manuell erstellt, kann man das ganz gut verwenden. Wird in deinem Fall wahrscheinlich nicht so einfach möglich sein.


    Früher konnte man die Query_Strings direkt in den Google Webmastertools angeben. Ist glaube ich nicht mehr möglich, Hat man aber auch schnell selber seine URLs komplett aus dem Index geschmissen, wenn man das nicht sehr gewissenhaft gemacht hat. Vielleicht wurde es deshalb entfernt. hmm

  • Vielen Dank für die guten Tipps. Mit dem "Filter-Eintrag in der Joomla-Indexierung" komme ich grad nicht weiter und weiß nicht wo da etwas einzutragen geht. Bisher hatte ich die Indexierung noch nicht aktiviert und nie genutzt. Da müsste ich mich erst mal eingehender mit befassen.


    Die Idee, wenigstens schon mal die Option "?tmpl=template" zu entschärfen, funktioniert durchaus mit rel="nofollow". Muss ich dann manuell in alle betreffenden Webseiten einfügen, wo solche Links enthalten sind. Sinn davon ist es ja nur, "duplicate content" zu vermeiden.


    Leider bin ich mir nicht mal sicher, ob das in diesem Fall nötig ist bzw. ob Google und andere Crawler es als duplicate content werten, wenn ein Artikel über
    https://meine-website/mein-artikel erreichbar ist und innerhalb eines anderen Artikels der gleiche Beitrag unter der URL https://meine-website/mein-artikel?tmpl=template verlinkt wird.

    Gemäß der von wolfstar verlinkten ersten Quelle trifft es zu, dass die Option "?tmpl=template" zu doppeltem content führt. Dann wäre dies natürlich eine viel elegantere Lösung, als wenn ich mühsam von Hand bei jedem Lightbox-Link ein rel="nofollow" einfügen müsste.


    Das dort genannte Beispiel bezieht sich auf die Unterscheidung von URLs, die auf .html enden und solche, die nach dem .html noch durch Fragezeichen angehängte Optionen haben. Ich verwende keine URL-Endung wie ".html – Im oben verlinkten Beispiel werden in der robots.txt folgende Zeilen eingefügt:


    Code
    Allow: /*.html$
    Disallow: /*.html?*

    Ein "Allow" müsste ich wohl nicht setzen, aber ich bin im Zweifel, ob das Disallow so richtig geschrieben ist, wenn ich es analog zum Beispiel einfüge. Dieser Robots.txt-Prüfer reklamiert mir die folgenden Schreibweisen als falsch:

    Code
    Disallow: /*?tmpl=template
    Disallow: /*?tmpl=template*
    Disallow: /?tmpl=template

    Und für URLs, die ebenfalls ein Fragezeichen beinhalten, gefolgt von anderen variablen Zeichen, fehlt mir auch eine Lösung.

  • Bissi Off-Topic: Sehe ich das richtig, dass die Joomla-interne Indexierung eigentlich nur eine schnellere Suchfunktion innerhalb der Website ermöglicht? Ich benutze keine Joomla-Suchfunktion für meine Website. Wozu nützt die mir dann? Und wozu würde ein Eintrag im Index-Filter nützen in Bezug auf den Google-Crawler und dessen Indexierung?

  • Bissi Off-Topic: Sehe ich das richtig, dass die Joomla-interne Indexierung eigentlich nur eine schnellere Suchfunktion innerhalb der Website ermöglicht? Ich benutze keine Joomla-Suchfunktion für meine Website. Wozu nützt die mir dann? Und wozu würde ein Eintrag im Index-Filter nützen in Bezug auf den Google-Crawler und dessen Indexierung?

    Korrekt, der Joomla Suchindex ist ausschließlich für die Suchfunktion auf deiner Website zuständig, und hat absolut nichts mit dem Google index zu tun.

    FMB GmbH - Zuführtechnik und mehr!


    - Industrieautomatisierung aus Braunschweig -

  • Schau dir hier bitte mal #9 an:

  • WM-Loose Danke für den Hinweis. Letztlich führte die Diskussion ja dann zu der Aimy-Extension "Canonical". Ehe ich die nächste Extension verwende (ich möchte mein Joomla so schlank wie möglich halten), werde ich dann doch manuell bei jedem dieser Links das rel="nofollow" einfügen.


    Im Übrigen fällt mir als vielleicht noch universellere Lösungsmöglichkeit der ReReplacer von Regular Labs ein.


    Wenn ich also generell die QeryStrings oder andere Dinge, die nach einem Fragezeichen kommen, wegfiltern wollte, muss ich wohl zu diesen Extensions greifen.

    Ich verwende noch iCagendar und bei den dort erzeugten Links bekomme ich immer "component" mit in die URL. Um dies aus dem Crawler-Index raus zu halten, habe ich in der robots.txt die Zeile drin:

    Code
    Disallow: /component/*

    In diesem Robots.txt-Validator wurde das als korrekt akzeptiert.

  • OffTopic(!!!!!): Zufällig entdeckt. In der robots.txt hast du

    Code
    Disallow: /component/*

    Zugleich aber

    Code
    Sitemap: https://lebenslust-jetzt.de/component/osmap/?view=xml&id=1&format=xml

    was ja unter dein Disallow fällt. Ob nun, Sitemap: zugleich ein Allow: beinhaltet, scheint nicht dokumentiert.


    Aaaaber, ich hatte einen ähnlichen Fall, wo in der robots.txt stand:

    Code
    Disallow: /*.txt$

    wo nun diverse SEO-Tools behaupteten, die robots.txt dürfe deshalb nicht gelesen werden, was ja ein Paradox ist, irgendwie.


    Laut Google Search Console, war das denen aber wohl egal, weil sonst hätten sie nicht eine Liste drinnen, was per robots.txt ausgeschlossen ist ;)


    Hätte ich also so eine Zeile in meiner robots.txt sähe die aus Unsicherheit so aus

    Code
    Sitemap: https://ghsvs.de/alle-beitraege?view=xml&id=1&format=xml

    Ich habe also für meine Osmap einen "sauberen" Menüeintrag und umginge so das /component/-Problem.

    Aabbber: Nichts genaues weiß man nicht ;)


    Warum habe ich sie nicht, die Zeile? Weil meine SItemap auch Links enthält, die bei AUfruf trotzdem ein noindex,nofollow haben könnten (bei Überarbeitungen z.B.), die Besucher ruhig sehen dürfen, Suchmaschinen aber erst mal nicht, weil die sonst den Hinweis, dass überarbeitet wird, gleich indexieren.


    Durch diese ganzen Sonderregelungen, die sich Arroganto-Google für eigene Belange im Laufe der Zeit so erfunden hat, auch für den robots-Tag ist das Ganze nur verwirrender geworden, wenn man parallel an mehreren Stellen angreift.

  • Re:Later Vielen Dank für deine Antwort!

    Ich habe daraufhin die robots.txt über PageSpeedInsights geprüft und sie wurde als fehlerfrei gemeldet. Auch in GSC gibt es keinen Hinweis darauf, dass nun nach Einfügen des

    Code
    Disallow: /component/*

    der OSmap Pfad ignoriert würde oder nicht mehr gefunden wird.


    Ich sehe es wie du: Das Monopol Google nimmt sich immer mehr hochherrschaftliche Definitionsgewalt und Normierungskraft heraus. Und wir können immer nur hinter her dackeln und versuchen, dass unsere Websites dem neuesten Furz entsprechen, da wir anderenfalls unser Ranking verlieren. Echte Erpressung / Nötigung!


    Deinen Hinweis

    Zitat

    Warum habe ich sie nicht, die Zeile? Weil meine SItemap auch Links enthält, die bei Aufruf trotzdem ein noindex,nofollow haben könnten (bei Überarbeitungen z.B.), die Besucher ruhig sehen dürfen, Suchmaschinen aber erst mal nicht, weil die sonst den Hinweis, dass überarbeitet wird, gleich indexieren.

    finde ich hoch interessant. Auch ich überarbeite immer wieder mal bereits bestehende Artikel. Wer oder was setzt denn dann den Hinweis, dass der Artikel überarbeitet wird? Verstehe ich dich richtig, dass du während einer Überarbeitung den entsprechenden Artikel auf noindex,nofollow setzt und dann OSmap diesen Artikel in der sitemap führt und dies zu einem Konflikt bei GSC führt?

    Was ist denn der von dir befürchtete Nachteil, wenn ich bei Überarbeitung eines Beitrags diesen während dessen nicht auf noindex,nofollow setze? – Ich habe bisher noch nie solch eine Markierung vorgenommen, wenn ich überarbeitet habe.

  • Ich habe ein eigenes Plugin, wo ich z.B. eine Einstellung zum Artikelstatus habe, wie "Artikel ist obsolet/antiquiert!". Im Frontend setzt das Plugin bei manchen dieser Einstellungen, die ich da habe, on-the-fly ein robots "noindex,follow" per PHP.


    Oder ich setze einen neuen Beitrag auf (mit Einstellung "Unfertiger Artikel in Arbeit!") und den sollen Suchmaschinen erst mal ignorieren, während ich ihn zwischendrin aber im Frontend auch mal angucken möchte und ganz kurz frei schalte. Das reicht einer Suchmaschine oft schon, ihn zu indexieren, obwohl der Beitrag erst mal wieder länger offline geht und er taucht in Suchergebnissen auf.


    Das tangiert die OsMap allerdings alles nicht. Da taucht der Link nach wie vor auf (oder im 2. Fall für den Moment der Freischaltung), außer ich würde ihn kompliziert entfernen, was mir einfach zu viel Aufwand ist. Da meine Sitemap (HTML) sich eher an Besucher richtet, als an Suchmaschinen, sähe ich das auch gar nicht ein. Besucher dürfen ihn ja gerne noch lesen, sehen aber ein "Artikel ist obsolet/antiquiert!" in der Überschrift.


    Na ja und würde ich die OsMap jetzt explizit als XML-Sitemap einreichen, obwohl unterm Strich der Suchmaschinen-Effekt mit meiner HTML-Sitemap für Besucher der selbe ist (suchmaschine versucht den Link, darf dann aber nicht; SearchConsole-Gemecker), dann, laut heute noch mal gelsener Legende(!!???), ist das doof, weil ja die eingereichte XML-Sitemap exakt den Sinn hat, Links zu enthalten, die gut sind oder besser: nicht übersehen werden sollen (bei "schrägem" Menüaufbau z.B.). Damit wird mindestens Scanzeit vergeudet, weil Suchmaschine die ja trotzdem versucht. Steht ja in der Sitemap.


    Auch Seiten wie Impressum, Datenschutzerklärung, Sucheseite, manchmal auch Blog-Übersichten haben bei mir per se ein noindex. Ich müsste sie aus der Sitemap-XML blöde entfernen; also eine weitere, nur für Suchmaschine anlegen und pflegen. Die HTML-Sitemap für Besucher soll sie aber drinnen haben.


    Generell ist bei vielen Seiten die sitemap.xml einzureichen sowieso zu hinterfragen, weil oft zusätzlicher Pflegeaufwand, der gerne vergessen wird. Suchmaschinen finden die korrekten Links von ganz alleine, wenn die Seite halbwegs logisch aufgebaut ist und nicht ungeprüfte Brotkrümelmenüs dumme Zwischenlinks einfügen, weil der Menüaufbau nicht sauber ist oder veraltete Module die Links nicht richtig auflösen oder die Seite beim AUfsetzen zu früh freigegeben wurde, z.B. Das sind dann die aufrufbaren, schrägen Links mit denen man in der Searchconsole kämpft oder, die dem eigentlich richtigen Link den Rang ablaufen. Das Ranking ist dann erst mal verloren, falls blöder Link in Suchmaschinen schon geklickt wurde.


    Anders: Was in der Sitemap nicht steht, wird trotzdem gescannt, wenn irgendein Weg dahin auf der Seite mal als Link war oder ist. Woimmer auch.


    Nur nebenbei: Ich habe laut SearchConsole derzeit 64 verbotene Links mit steigender Tendenz (bevor sie mich mit einem 500-Fehler heute rausgeschmissen hat ;) ). Gut so! Ich will gar nicht, dass G die liest und verbreitet. Insofern funktioniert das offensichtlich korrekt. Trotzdem sieht das beim Besuch natürlich erst mal bedrohlich aus ;)


  • Oh herzlichen Dank für deine wertvollen Erfahrungen damit. Vielleicht hätte ich da noch eine Idee:


    Ich arbeite ja mit YooThemePagebuilder (andere Pagebuilder sind da sicher ähnlich). Der große Vorteil bei der Gestaltung einer neuen Seite ist, dass ich echtes WYSIWYG in einem Iframe bekomme, während ich vorgefertigte Elemente und Gruppen platziere und mit Text fülle.


    Das Ganze funktioniert nur, wenn ich zuvor einen Beitrag in Joomla angelegt habe und daraufhin zu diesem Beitrag den Pagebuilder starte. Genau dann ist aber der Beitrag "im Entwicklungszustand" bereits in OSmap und der Sitemap zu sehen und auch im Frontend abrufbar.


    Die Entwicklung einer solchen Webseite kann bei mir schon mal 10 Tage dauern, da ich nicht immer dran bleiben kann. Zwar kann ich nach Ende eines Arbeitsschritts das Ganze im Pagebuilder auf "deaktiviert" setzen. Das löst aber das Problem der Sichtbarkeit und Crawlbarkeit während der Entwicklung nicht.


    Im YooThemeForum erhielt ich den Tipp, die neuen Beiträge auf ein verstecktes Menü zu legen. Das ist dann aber dennoch vom Pagebuilder aus erreichbar, aber eben nicht für Crawler und Besucher. Erst wenn die Seite fertig gestellt ist, ordne ich sie der endgültigen Kategorie bzw. dem endgültigen Menüpunkt zu.


    Bisher habe ich noch nicht so gearbeitet, aber das wird bald nötig sein.

  • Re:Later Wie in dem anderen Thread von mir zuletzt geschrieben:

    Zitat

    Ich habe mir gerade meine Umleitungen in Joomla angeschaut. Da war unbeabsichtigt aktiviert "URLs sammeln". Dadurch haben sich in der relativ kurzen Zeit von ca. 3 Wochen über 2.740 URLs gesammelt. Die meisten waren Schrott, weil z.B. Script-Kiddies irgend etwas mit Wordpress usw. versucht haben, einzugeben.

    Aber erschreckend war für mich, dass auch ur-uralte URLs aus dem Jahr 2013 noch darin gestanden sind!

    Und sehr viele von denen, die GSV aufgelistet hatte!


    Entweder hat Google die jetzt gerade gecrawlt oder? – Ich fühle mich schon verführt dazu, die jetzt nach einer großen Säuberungsaktion übrig gebliebenen ca. 170 Uralt-URLs doch auf Umleitung zu legen. Welche negativen Folgen könnte das für mich bzw. GSC und das Ranking konkret haben?

    Der User faro riet mir davon ab, die Umleitungen für uralte Rest-URLs anzulegen, begründete diese Ansicht aber lediglich damit, dass ich damit "das Problem nur nach hinten / später verlegen würde".


    Aber eigentlich möchte ich hier nur darauf aufmerksam machen, dass es zur Aufklärung von solch problematischem Sachverhalt (wo kommen die falschen alten URLs her) durchaus sinnvoll sein kann, nicht nur die Umleitungskomponente in Joomla zu aktivieren, sondern zumindest zeitweise auch die Funktion "URLs sammeln". Ich sah dort URLs und Ziele, die Erinnerungen an die ersten Gehversuche mit meiner Praxis-Website erinnerten. Solche URLs kann eigentlich nur Google aufrufen. Wer hat schon Bookmarks gespeichert, die so lange Zeit zurück reichen?


    Da ca. 50 für mich aktuell wertvolle Seiten von Google zwar gecrawlt aber nicht indexiert worden sind (weil alte ungültige URLs indexiert sind und auf den gleichen Inhalt verwiesen und daher aus Sicht von GSC "DoubleContent" entsteht), habe ich mich doch dazu entschlossen, hierfür Umeleitungen anzulegen.


    Und danach gilt: Ruhe bewahren und abwarten. Es bleibt mir eh nix anderes übrig. (siehe #18 von diesem Thread: meine Website rankt nicht mehr – GoogleSearch mit chaotischer, veralteter Indexierung)

  • Wer hat schon Bookmarks gespeichert, die so lange Zeit zurück reichen?

    Diverse andere Suchmaschinen und sonstige Crawler, z.B. unsägliche Pseudo-SEO-Crawler und Datensauger, die ihren Index nie aktualisieren. Da hilft dann eigentlich nur ein Blick in die Access-Logs des Servers (mühsam, mühsam), um die rauszubekommen. Und das Eliminieren über .htaccess, nicht der URLs, sondern der unseriösen Crawler, ist dann eine weitere Lebensaufgabe, die ich längst aufgegeben habe. Nur ein kleiner Teil lässt sich über Einträge in der robots.txt "aussperren".

  • Nur ein kleiner Nebenbeikommentar.

    Ich bekomme heute folgende Email, aus der klar wird, wie bescheurt die Denke von G aus Sicht von Usern ist: "Indexiert, obwohl durch robots.txt-Datei blockiert". Nebenbei habe ich an dieser robots.txt schon seit > 1 Jahr nichts mehr geändert.


    Die angeblich aktuell betroffene URL

    Code
    https://ghsvs.de/component/content/category?layout=protostarbs3ghsvs:wookghsvs&Itemid=644

    und an der sehe ich, dass die aus frühesten Joomla-3-Zeiten stammt und schon laaaaaange joomlaseitig auf eine 404-Seite führt, laaaange nicht mehr bei mir auftaucht und laaange zusätzlich per robots.txt (Disallow: /component/content/) und einem eigenen Plugin unzugänglich wäre, sogar mit einem 405, wenn es sie denn gäbe ;)

    Und entfernt habe ich sie auch schon desöfteren in der Console. Kommt halt immer wieder.


    Einzige Möglichkeit wäre also Disallow: /component/content/ aus der robots.txt zu entfernen, Aufrufe radikal ins Leere laufen lassen, abzuwarten, bis auch Google das kapiert UND diverse andere Aufrufe, die G im Jahre 1888 mal gesammelt hat über längere Zeit zu kontrollieren, ob die jetzt blöderweise wieder mit irgendwas Inhalt aufrufbar sind; ohne 404 oder 405.


    Das mentale Problem, dass ich damit habe, ist, dass Google die weiterhin, ungewiss ob mit Inhalten oder nicht, beharrlich behält. Und natürlich diese bescheuerten Formulierungen, die auch Kunden immer wieder veranlasst bei mir rückzufragen, was da für eine Katastrophe passiert ist. In meiner Console ist das dann so formuliert, dass diese gesperrte URL meinen Suchergebnissen schaden könnte.