Suchmaschinen-Management
fietur
Suchmaschinen-Management
fietur
MudGuard
Rolf B
Gunnar BittersmannHallo, ich habe ein praktische Frage, die zwar nicht unmittelbar etwas mit HTML zu tun hat, aber große Auswirkungen haben kann.
Ich kenne drei Möglichkeiten der Zugangs-/Scan-Begrenzung:
- die robots.txt
Dort verbiete ich den Zugriff auf Dateitypen wie PDFs oder einzelne Ordner; wer sich nicht daran hält, landet auf meiner schwarzen Liste; funktioniert ganz gut, nachdem die ohnehin robots-ignoranten Crawler aussortiert wurden.
- die .htaccess
Hier steht das Gleiche in grün wirksam:
<FilesMatch "\.(png|jpe?g|webp|gif|mp4|mp3)$">
Header set X-Robots-Tag "noindex"
</FilesMatch>
<FilesMatch "\.pdf$">
Header set X-Robots-Tag "noindex, nofollow"
</FilesMatch>
- Direkt auf der Seite im <head>
Ich habe derzeit noch ein <meta name="robots" content="noindex,nofollow"> eingebunden. Das funktioniert zu meiner Überraschung sehr gut - bisher wird die Seite noch von keiner Suchmaschine gelistet. Zwar kamen die ersten Besucher aus Fernost (und -west) bereits wenige Stunden nach Registrierung der Domain, aber die Zahl der (unnötig bis unerwünschten) Zugriffe liegt noch erfreulich niedrig.
Dass die Seite nicht auffindbar ist, soll jedoch kein Dauerzustand bleiben. Zwar verfolgt die Seite keinerlei kommerzielle Interessen, aber eine Auffindbarkeit auch ohne genaue Kenntnis des Domainnamens sollte dennoch gegeben sein. Dazu brauche ich nur noindex wieder zu entfernen, das ist schon klar.
Aber es gibt Fallstricke. Ich habe beispielsweise für manche Beiträge eine Bewertungsfunktion in Form zweier als Buttons getarnter Links. Sollte ein Robot einen dieser Links anwählen (und sich für das voten des anderen disqualifizieren), verfälscht das die Bewertung und Beteiligung. Hier wäre ein rel="nofollow" im <a href=...> das Mittel der Wahl, oder?
Ein anderes Problem ist, dass ich neben nicht zu indizierenden Dokumenten (PDF's) auf der Startseite unterschiedliche Beiträge aufführe. Einige davon dürfen oder sollen indiziert werden, während andere eher nur für menschliche und bereits auf der Seite befindliche Besucher gedacht sind.
Und hier lautet meine Frage: Wie kann ich für solche <article> ein Finetuning vornehmen, so dass Google und Co einzelne davon indizieren, andere aber links liegen lassen?
-
Moin fietur,
Ich kenne drei Möglichkeiten der Zugangs-/Scan-Begrenzung:
- die robots.txt
Damit kannst keinen Zugang begrenzen, sondern Clients, die sich als Bots (im soziologischen Sinn) identifizieren, bitten bestimmte Bereiche (nicht) zu indizieren.
Dort verbiete ich den Zugriff auf Dateitypen wie PDFs oder einzelne Ordner; wer sich nicht daran hält, landet auf meiner schwarzen Liste; funktioniert ganz gut, nachdem die ohnehin robots-ignoranten Crawler aussortiert wurden.
Das funktioniert aber auch nur solange, wie sich ein Bot nicht als handelsüblicher Browser ausgibt und so verhält.
- die .htaccess
Hier steht das Gleiche in
grünwirksam:<FilesMatch "\.(png|jpe?g|webp|gif|mp4|mp3)$"> Header set X-Robots-Tag "noindex" </FilesMatch> <FilesMatch "\.pdf$"> Header set X-Robots-Tag "noindex, nofollow" </FilesMatch>Wirksam? Der Client muss diesen Header kennen und als Bitte verstehen. Ich lese davon gerade zum ersten Mal …
- Direkt auf der Seite im <head>
Ich habe derzeit noch ein
<meta name="robots" content="noindex,nofollow">eingebunden. Das funktioniert zu meiner Überraschung sehr gut […]Weil es (neben der
robots.txt) seit Jahrzehnten spezifiziert so spezifiziert und implementiert ist.[…]bisher wird die Seite noch von keiner Suchmaschine gelistet. Zwar kamen die ersten Besucher aus Fernost (und -west) bereits wenige Stunden nach Registrierung der Domain, aber die Zahl der (unnötig bis unerwünschten) Zugriffe liegt noch erfreulich niedrig.
Woran machst du denn „unnötige“ Zugriffe fest?
„Unerwünschte Zugriffe“ wirst du nur mit einer geschlossenen Seite unterbinden können, sprich hinter einem Login (HTTP Authentication oder Login-Formular mit Cookies o.ä.).
Aber es gibt Fallstricke. Ich habe beispielsweise für manche Beiträge eine Bewertungsfunktion in Form zweier als Buttons getarnter Links.
Buttons sollten auch Buttons sein und Aktionen, die etwas auf dem Server ändern, sollten niemals per GET ausgeführt werden können. Mit anderen Worten: Mach aus den „Links“ echte Buttons in einem Formular, das einen POST-Request absendet und verhindere auf dem Server CSRF.
Sollte ein Robot einen dieser Links anwählen (und sich für das voten des anderen disqualifizieren), verfälscht das die Bewertung und Beteiligung. Hier wäre ein
rel="nofollow"im<a href=...>das Mittel der Wahl, oder?Nein, denn es ist immer noch nur eine Bitte an einen Client.
Ein anderes Problem ist, dass ich neben nicht zu indizierenden Dokumenten (PDF's) auf der Startseite unterschiedliche Beiträge aufführe. Einige davon dürfen oder sollen indiziert werden, während andere eher nur für menschliche und bereits auf der Seite befindliche Besucher gedacht sind. Und hier lautet meine Frage: Wie kann ich für solche
<article>ein Finetuning vornehmen, so dass Google und Co einzelne davon indizieren, andere aber links liegen lassen?Hast du einmal eine Suchmaschine deiner Wahl danach befragt?
Viele Grüße
Robert-
Hi,
Ich kenne drei Möglichkeiten der Zugangs-/Scan-Begrenzung:
- die robots.txt
Damit kannst keinen Zugang begrenzen, sondern Clients, die sich als Bots (im soziologischen Sinn) identifizieren, bitten bestimmte Bereiche (nicht) zu indizieren.
und für die bösen Bots ist das die Anleitung zum Finden der interessanten Stellen …
cu,
Andreas a/k/a MudGuard-
und für die bösen Bots ist das die Anleitung zum Finden der interessanten Stellen …
Klar. Aber auch eine Gelegenheit ein Honigtöpfchen aufzustellen, wenn es als notwendig erachtet wird. Als ich angefangen habe, meinen ersten Zugriffsfilter zu basteln, habe ich so hilfreiche Kriterien dafür erhalten...
-
Woran machst du denn „unnötige“ Zugriffe fest?
Ok, schlechte Wortwahl. Das scharenweise Scannen nach Merkmalen, die offenbar nicht auf irgendwelchen Inhalt gerichtet sind. Und ja, einige scheinen es nötig zu haben.
„Unerwünschte Zugriffe“ wirst du nur mit einer geschlossenen Seite unterbinden können, sprich hinter einem Login (HTTP Authentication oder Login-Formular mit Cookies o.ä.).
Schon klar (und auch so realisiert). Reduzieren, nicht gänzlich unterbinden sollte das Ziel eher lauten. So wie z.B. eine temporäre IP-Sperre nach "unerwünschtem Zugriff" die Zahl der Folgezugriffe aus gleicher Quelle stark reduziert.
Aber es gibt Fallstricke. Ich habe beispielsweise für manche Beiträge eine Bewertungsfunktion in Form zweier als Buttons getarnter Links.
Buttons sollten auch Buttons sein und Aktionen, die etwas auf dem Server ändern, sollten niemals per GET ausgeführt werden können. Mit anderen Worten: Mach aus den „Links“ echte Buttons in einem Formular, das einen POST-Request absendet und verhindere auf dem Server CSRF.
Nicht immer ist das was soll auch das Sinnvollste. Ein Formular kann nicht überall eingebunden werden (zB. nicht in einer Tabelle. Aber darum geht es auch nicht). Die benötigten Parameter aus meinen Links werden nicht mittels GET-Schema übermittelt, sondern werden aus dem URL extrahiert.
Sollte ein Robot einen dieser Links anwählen (und sich für das voten des anderen disqualifizieren), verfälscht das die Bewertung und Beteiligung. Hier wäre ein
rel="nofollow"im<a href=...>das Mittel der Wahl, oder?Nein, denn es ist immer noch nur eine Bitte an einen Client.
An die sich die zahlenmäßig meisten Suchmaschinen halten. Aber danke, wieder ein Brett vorm Kopf entfernt; die Buttons werden also in ein Formular gepackt. Damit sollte das Voten durc Crawler der Vergangenheit angehören.
Und hier lautet meine Frage: Wie kann ich für solche
<article>ein Finetuning vornehmen, so dass Google und Co einzelne davon indizieren, andere aber links liegen lassen?Hast du einmal eine Suchmaschine deiner Wahl danach befragt?
Mein Verhältnis zu "intelligenten" Suchmaschinen ist eher gespalten. Meine Prompt-Fähigkeiten sind grottig. Ich finde immer nur Antworten, die sich auf die Indexierung ganzer Seiten beziehen. Ich suche allerdings eine Lösung dafür, von einer Seite nur bestimmte Bereiche auszunehmen. Das muss nicht vollständig wasserdicht sein.
Von allein kommen mir zwar ein paar kreative Ideen, aber die haben andere Nachteile. Eine Lösung wäre z.B. die entsprechenden Beiträge als SVG einzubinden und die Indexierung von SVG-Content als unerwünscht zu kennzeichnen.
Irgendwelche Ideen?
-
Moin fietur,
Aber es gibt Fallstricke. Ich habe beispielsweise für manche Beiträge eine Bewertungsfunktion in Form zweier als Buttons getarnter Links.
Buttons sollten auch Buttons sein und Aktionen, die etwas auf dem Server ändern, sollten niemals per GET ausgeführt werden können. Mit anderen Worten: Mach aus den „Links“ echte Buttons in einem Formular, das einen POST-Request absendet und verhindere auf dem Server CSRF.
Nicht immer ist das was soll auch das Sinnvollste. Ein Formular kann nicht überall eingebunden werden (zB. nicht in einer Tabelle.
Es darf aber auch in einer Tabelle enthalten.
Die benötigten Parameter aus meinen Links werden nicht mittels GET-Schema übermittelt, sondern werden aus dem URL extrahiert.
Und wie sieht der Request an den Server aus? Richtig, HTTP GET. GET ist die HTTP-Methode und da spielt die komplette URL eine Rolle und ich kann diese URL einfach aufrufen, sogar aus der Adresszeile des Browsers.
GET sind nicht ausschließlich die URL-Parameter!
Sollte ein Robot einen dieser Links anwählen (und sich für das voten des anderen disqualifizieren), verfälscht das die Bewertung und Beteiligung. Hier wäre ein
rel="nofollow"im<a href=...>das Mittel der Wahl, oder?Nein, denn es ist immer noch nur eine Bitte an einen Client.
An die sich die zahlenmäßig meisten Suchmaschinen halten. Aber danke, wieder ein Brett vorm Kopf entfernt; die Buttons werden also in ein Formular gepackt. Damit sollte das Voten durc Crawler der Vergangenheit angehören.
Und die Formulare werden per HTTP POST übertragen. Damit zählt nicht jeder Besuch der Seite als Stimme.
Und hier lautet meine Frage: Wie kann ich für solche
<article>ein Finetuning vornehmen, so dass Google und Co einzelne davon indizieren, andere aber links liegen lassen?Hast du einmal eine Suchmaschine deiner Wahl danach befragt?
Mein Verhältnis zu "intelligenten" Suchmaschinen ist eher gespalten. Meine Prompt-Fähigkeiten sind grottig.
Ein guter Anfang ist schon einmal, sein Anliegen passend zu formulieren, optimal ist Englisch, also z.B. nach
robot index only part of pageoderexclude part of page from robots. Und damit finde ich z.B. bei Duckduckgo vieles, aber nichts was darauf hindeutet, dass dein Anliegen funktioniert (außer mit Iframes). Bei Startpage sieht es ähnlich aus.Ich finde immer nur Antworten, die sich auf die Indexierung ganzer Seiten beziehen. Ich suche allerdings eine Lösung dafür, von einer Seite nur bestimmte Bereiche auszunehmen. Das muss nicht vollständig wasserdicht sein.
Hm, wenn es keine Dokumente für dein Anliegen gibt, dann könnte das daran liegen, dass es nicht vorgesehen ist. „Geht nicht“ ist zwar keine zufriedenstellende, aber valide Antwort.
Von allein kommen mir zwar ein paar kreative Ideen, aber die haben andere Nachteile. Eine Lösung wäre z.B. die entsprechenden Beiträge als SVG einzubinden und die Indexierung von SVG-Content als unerwünscht zu kennzeichnen.
Und Screenreader gehen dann auch leer aus.
Irgendwelche Ideen?
Inhalte, die nicht indiziert werden sollen, auf eigene Seiten auslagern. Wenn du mehrere
articleauf einer Seite hast, ist eh die Frage, wie viel Inhalt da auf einer Seite angeboten werden soll.Viele Grüße
Robert-
Es darf aber auch in einer Tabelle enthalten.
Eine Tabelle in ein Formular zu setzten, geht. Ja, mache ich auch, obwohl das bisweilen nervige Auswirkunghen hat (beispielsweise, wenn man eigentlich lieber viele <form> in einer Tabelle möchte, um nicht alles an den Server übertragen zu müssen.)
In meinem Fall - Links durch <form> ersetzt - führt erstmal zu dem Problem, dass das Formular Zeilenumbrüche verursacht, die mit Links nicht auftreten.
Die benötigten Parameter aus meinen Links werden nicht mittels GET-Schema übermittelt, sondern werden aus dem URL extrahiert.
Und wie sieht der Request an den Server aus? Richtig, HTTP GET. GET ist die HTTP-Methode und da spielt die komplette URL eine Rolle und ich kann diese URL einfach aufrufen, sogar aus der Adresszeile des Browsers.
GET sind nicht ausschließlich die URL-Parameter!
Das stimmt natürlich. Bei meinen Links waren aber keine URL-Parameter sichtbar enthalten. Gegen wiederholten Aufruf hilft mir zwar ein Session-Cookie-Eintrag, aber gegen den Suchmaschinenaufruf eben nur die Bitte, dem Link nicht zu folgen.
Daher hatte ich nach einer Alternative gefragt - und mit dem Formular-Hinweis erhalten. Jetzt muss ich nur noch das Formular als inline-Block einbauen (können).
Hm, wenn es keine Dokumente für dein Anliegen gibt, dann könnte das daran liegen, dass es nicht vorgesehen ist. „Geht nicht“ ist zwar keine zufriedenstellende, aber valide Antwort.
Wobei auch gilt: Nur weil etwas nicht vorgesehen ist, muss es nicht unmöglich sein. Oder unerwünscht. Exotisch vielleicht, das schon.
Von allein kommen mir zwar ein paar kreative Ideen, aber die haben andere Nachteile. Eine Lösung wäre z.B. die entsprechenden Beiträge als SVG einzubinden und die Indexierung von SVG-Content als unerwünscht zu kennzeichnen.
Und Screenreader gehen dann auch leer aus.
Das ist einer der Nachteile, der sich wiederum mit einigen Klimmzügen beheben lassen sollte, wenn man es darauf anlegt.
Irgendwelche Ideen?
Inhalte, die nicht indiziert werden sollen, auf eigene Seiten auslagern. Wenn du mehrere
articleauf einer Seite hast, ist eh die Frage, wie viel Inhalt da auf einer Seite angeboten werden soll.Das ist eine Grundsatzfrage, die ich für mich beantwortet habe: Sehr viel. Jeder einzelne Artikel hat einen Teaser (mit Bild) und kurzer Zusammenfassung, während der eigentliche Text zunächst ausgeblendet bleibt (
<details>). Vom Umfang her ist der Abruf nicht ganz klein, aber immer noch recht flott und übersichtlich. Bei meiner Seite passt es ganz gut. Die Inhalte sind eher kurzlebig, der Umfang ist also begrenzt.Ich nehme für mich mit, dass es wohl noch keine Möglichkeit gibt, bestimmte Teile einer Seite auszunehmen. Auslagern ist sicher eine Alternative. Und dann wieder miteinbinden? Als iframe vielleicht? Lassen sich derart eingebunden Inhalte vielleicht von der Indexierung ausnehmen?
Machen wollen würde ich es aber nicht so.
-
Moin fietur,
In meinem Fall - Links durch <form> ersetzt - führt erstmal zu dem Problem, dass das Formular Zeilenumbrüche verursacht, die mit Links nicht auftreten.
Die
display-Eigenschaft von CSS und deren Werte sind dir bekannt?Die benötigten Parameter aus meinen Links werden nicht mittels GET-Schema übermittelt, sondern werden aus dem URL extrahiert.
Und wie sieht der Request an den Server aus? Richtig, HTTP GET. GET ist die HTTP-Methode und da spielt die komplette URL eine Rolle und ich kann diese URL einfach aufrufen, sogar aus der Adresszeile des Browsers.
GET sind nicht ausschließlich die URL-Parameter!
Das stimmt natürlich. Bei meinen Links waren aber keine URL-Parameter sichtbar enthalten.
Das ist vollkommen egal. Man kann Abstimmen indem man einfach die URL im Browser aufruft oder einem Link folgt. Das ist das Problem hier.
Gegen wiederholten Aufruf hilft mir zwar ein Session-Cookie-Eintrag, aber gegen den Suchmaschinenaufruf eben nur die Bitte, dem Link nicht zu folgen.
Oder eben ein Formular mit einem POST-Request.
Daher hatte ich nach einer Alternative gefragt - und mit dem Formular-Hinweis erhalten. Jetzt muss ich nur noch das Formular als inline-Block einbauen (können).
Siehe oben – „zufälliger Weise“ ist SELFHTML nicht nur ein Forum, sondern vor allem eine Dokumentation (als Wiki). „Die Energie des Verstehens.“
Von allein kommen mir zwar ein paar kreative Ideen, aber die haben andere Nachteile. Eine Lösung wäre z.B. die entsprechenden Beiträge als SVG einzubinden und die Indexierung von SVG-Content als unerwünscht zu kennzeichnen.
Und Screenreader gehen dann auch leer aus.
Das ist einer der Nachteile, der sich wiederum mit einigen Klimmzügen beheben lassen sollte, wenn man es darauf anlegt.
Alternativer Textinhalt wird auch von (Suchmaschinen-) Bots gefunden 😉
Noch einmal: Wenn Inhalte nur von Menschen gelesen werden können sollen, sorge dafür, dass nur Menschen den Zugang haben, z.B. über einen Account.Inhalte, die nicht indiziert werden sollen, auf eigene Seiten auslagern. Wenn du mehrere
articleauf einer Seite hast, ist eh die Frage, wie viel Inhalt da auf einer Seite angeboten werden soll.Das ist eine Grundsatzfrage, die ich für mich beantwortet habe: Sehr viel. Jeder einzelne Artikel hat einen Teaser (mit Bild) und kurzer Zusammenfassung, während der eigentliche Text zunächst ausgeblendet bleibt (
<details>). Vom Umfang her ist der Abruf nicht ganz klein, aber immer noch recht flott und übersichtlich.Ohne die Seite zu kennen, kann ich dazu nicht mehr sagen, stelle aber die Frage, ob das eine sinnvolle Usability ist. „Typisch“ wäre ja eher eine Übersicht á la
Titel [mit Artikellink] ======================= (ggf. Meta-Daten wie Datum, Autor, Kategorien, … Teaser/Zusammenfassung ggf. mit kleinem Vorschau-/Teaser-Bild … (ggf. noch ein Link zum „Weiterlesen“)Damit sind dann alle Zusammenfassungen auf einen Blick zu lesen, das Markup ist semantisch und Leser*innen können Artikel komplett lesen, falls sie möchten. Zusätzlich hat jeder Artikel einen eindeutigen URL.
Bei meiner Seite passt es ganz gut. Die Inhalte sind eher kurzlebig, der Umfang ist also begrenzt.
Wenn es für das Publikum in Ordnung ist, nur die
summaryzu haben und dann ggf. alledetailsaufzuklappen, dann wird das wohl so sein.Ich nehme für mich mit, dass es wohl noch keine Möglichkeit gibt, bestimmte Teile einer Seite auszunehmen. Auslagern ist sicher eine Alternative. Und dann wieder miteinbinden? Als iframe vielleicht? Lassen sich derart eingebunden Inhalte vielleicht von der Indexierung ausnehmen?
Mit den von mir angeführten Beispiel-Suchbegriffen findest du mit jeder relevanten Suchmaschine (Beispiele habe ich ebenfalls aufgeführt) die Antworten auf beide Fragen – bzw. die Antwort auf die zweite Frage taucht ja schon in deinem Ausgangspost.
Viele Grüße
Robert-
Alternativer Textinhalt wird auch von (Suchmaschinen-) Bots gefunden 😉
Noch einmal: Wenn Inhalte nur von Menschen gelesen werden können sollen, sorge dafür, dass nur Menschen den Zugang haben, z.B. über einen Account.Mache ich auch so. Aber interessant sind auch die Grauzonen, und da kann es Alternativen geben. Nicht immer muss es eine Totalsperre sein. Beispiel Email oder Telefonnummern; hier machen schon von Menschen einfach zu überwindende Hürden, die aber von Bots nicht zu bewältigen sind, einen großen Unterschied. Und da gibt es auch viele Lösungen: Daten ohne Text als Grafik, CSS/Javascript-Tricks, Captchas... Nichts absolutes (außer vlt. "absolut bescheuerte Lösung" 😅), aber eben hilfreich.
Ohne die Seite zu kennen, kann ich dazu nicht mehr sagen, stelle aber die Frage, ob das eine sinnvolle Usability ist. „Typisch“ wäre ja eher eine Übersicht á la
Titel [mit Artikellink] ======================= (ggf. Meta-Daten wie Datum, Autor, Kategorien, … Teaser/Zusammenfassung ggf. mit kleinem Vorschau-/Teaser-Bild … (ggf. noch ein Link zum „Weiterlesen“)Und genau das - mit Ausnahme eines festen Links - ist auch bei mir der Fall. Da das Bild im Teaser jeweils das Interesse einfängt (die Wahrnehmungspsychologie und Lese-bereitschaft/-fähigkeit hat sich stark geändert) und den Löwenanteil an Bandbreite ausmacht, bringt es wenig, den Text-Inhalt nicht auch gleich mitzuliefern. Und da viele Beiträge nur wenige Wochen aktuell sind, werden auch keine eigenen URL's benötigt. Indirekt existieren diese allerdings schon (zugangsbeschränkt) als archivierte PDF's.
Wenn es für das Publikum in Ordnung ist, nur die
summaryzu haben und dann ggf. alledetailsaufzuklappen, dann wird das wohl so sein.Ja, komischerweise werden diese Klicks nicht als solche wahrgenommen, während schon die Auswahl in einem Untermenu das Interesse deutlich verringert.
Mit den von mir angeführten Beispiel-Suchbegriffen findest du mit jeder relevanten Suchmaschine (Beispiele habe ich ebenfalls aufgeführt) die Antworten auf beide Fragen – bzw. die Antwort auf die zweite Frage taucht ja schon in deinem Ausgangspost.
Und dort bin ich jetzt auch fündig geworden. Ein Lösungsvorschlag ist die Nutzung von (robots.txt-"gesperrten") iframes, ein weiterer spielt mit dem nachträglichen Javascript-gesteuertem, Einblenden des mit
display:noneausgeblendeten Inhalts (was nicht mehr funktioniert, da Google z.B. jetzt auch JS ausführen soll).Und dann die reine CSS-Lösung, bei der die Bereiche ebenfalls mit
display:noneherausgenommen werden. In einem externen CSS, das via robots.txt gegen die Einsicht durch Crawler geschützt ist, wird derdisplay-Wert wieder überschrieben. Für mein Ziel (bestimmte Inhalte nicht bei Google oder Bing wiederzufinden) könnte das ausreichend sein, ich werde es mal so versuchen.Auf jeden Fall danke ich dir für den Schubs in die richtige Richtung.
-
Moin fietur,
Alternativer Textinhalt wird auch von (Suchmaschinen-) Bots gefunden 😉
Noch einmal: Wenn Inhalte nur von Menschen gelesen werden können sollen, sorge dafür, dass nur Menschen den Zugang haben, z.B. über einen Account.Mache ich auch so. Aber interessant sind auch die Grauzonen, und da kann es Alternativen geben. Nicht immer muss es eine Totalsperre sein. Beispiel Email oder Telefonnummern; hier machen schon von Menschen einfach zu überwindende Hürden, die aber von Bots nicht zu bewältigen sind, einen großen Unterschied. Und da gibt es auch viele Lösungen: Daten ohne Text als Grafik, CSS/Javascript-Tricks, Captchas... Nichts absolutes (außer vlt. "absolut bescheuerte Lösung" 😅), aber eben hilfreich.
Hürden sind Hürden und es gibt auch Menschen mit Beeinträchtigungen, für die diese Hürden zu hoch sind. Bots kann man nicht „110%ig“ aussperren, aber Menschen; Zugänglichkeit sollte trotz allem immer an erster Stelle stehen.
(Bots können z.B. Captchas mittlerweile besser und zuverlässiger lösen als Menschen.)
Da das Bild im Teaser jeweils das Interesse einfängt (die Wahrnehmungspsychologie und Lese-bereitschaft/-fähigkeit hat sich stark geändert) und den Löwenanteil an Bandbreite ausmacht, bringt es wenig, den Text-Inhalt nicht auch gleich mitzuliefern.
Das kommt auf die Bedeutung der Grafik an: Eine Vorschaugrafik kommt mit wenigen 10 Kilobyte aus, während eine große Artikelgrafik (z.B. ein Foto) auch deutlich größer sein kann. Wenn es SVG sind, wären die gleich groß.
Und da viele Beiträge nur wenige Wochen aktuell sind, werden auch keine eigenen URL's benötigt. Indirekt existieren diese allerdings schon (zugangsbeschränkt) als archivierte PDF's.
Kann es sein, dass du eigentlich so etwas wie „Fernsehen“ haben möchtest (im Idealfall noch ohne Videorecorder, aber zugangsbeschränkter Mediathek)? Dafür ist das Web konzeptionell nicht gedacht und gemacht.
Wenn es für das Publikum in Ordnung ist, nur die
summaryzu haben und dann ggf. alledetailsaufzuklappen, dann wird das wohl so sein.Ja, komischerweise werden diese Klicks nicht als solche wahrgenommen, während schon die Auswahl in einem Untermenu das Interesse deutlich verringert.
Wenn ich Äpfel mag, interessieren mich Birnen vielleicht auch weniger 😉
Mit den von mir angeführten Beispiel-Suchbegriffen findest du mit jeder relevanten Suchmaschine (Beispiele habe ich ebenfalls aufgeführt) die Antworten auf beide Fragen – bzw. die Antwort auf die zweite Frage taucht ja schon in deinem Ausgangspost.
Und dort bin ich jetzt auch fündig geworden. Ein Lösungsvorschlag ist die Nutzung von (robots.txt-"gesperrten") iframes, ein weiterer spielt mit dem nachträglichen Javascript-gesteuertem, Einblenden des mit
display:noneausgeblendeten Inhalts (was nicht mehr funktioniert, da Google z.B. jetzt auch JS ausführen soll).Joah, Google führt JavaScript aus, hält sich aber an die
robots.txt– das sollte ja nun keine schwierige Entscheidung sein. Und wer sich nicht an dierobots.txthält, ignoriert auchdisplay: none, ja sogar HTML-Kommentare (Beweis: in einem HTML-Kommentar eine URL notieren und dann beobachten, wer diese abfragt).Und dann die reine CSS-Lösung, bei der die Bereiche ebenfalls mit
display:noneherausgenommen werden. In einem externen CSS, das via robots.txt gegen die Einsicht durch Crawler geschützt ist, wird derdisplay-Wert wieder überschrieben. Für mein Ziel (bestimmte Inhalte nicht bei Google oder Bing wiederzufinden) könnte das ausreichend sein, ich werde es mal so versuchen.Ich wage zu bezweifeln, dass das von Erfolg gekrönt ist. CSS-Dateien werden ja nicht wegen textueller Information abgefragt, sondern zur Darstellung. Wenn da jetzt aber „sehr viel“ versteckter Inhalt ist, könnten das Suchmaschinen als Täuschungsversuch auffassen und sehr zuverlässig deine Seite ignorieren: durch Ausschluss wegen Täuschung. Aber das könntest du auch billiger haben:
User-Agent: * Disallow: /Viele Grüße
Robert-
Hallo Robert,
... so etwas wie „Fernsehen“ ... zugangsbeschränkt ... dafür ist das Web konzeptionell nicht gedacht und gemacht.
Also das kann ich so nicht unterschreiben. Frag mal all die Paywalls da draußen. Bzw. die "Kekse oder Kohle" Anbieter.
Das Problem sind tatsächlich Kurzfristangebote. Ich hab schon oft Suchtreffer zu Seiten bekommen, auf denen der gesuchte Inhalt längst nicht mehr stand. Das gilt auch für Portalseiten von Blogs, oder auch Zeitungen. Diese sollten idealerweise nicht indexiert werden, sondern nur die eigentlichen Artikel. Keine Ahnung, ob man das hinkriegen kann: "Indexiere mich nicht, aber die Seiten, auf die ich verlinke, schon".
Wenn ich Kurzfristangebote gar nicht in einem Index sehen möchte, weil ich nicht vorhabe, sie dauerhaft anzubieten, dann könnte es vielleicht helfen, nach diesem Sachverhalt im Netz zu suchen. Und man findet (trommelwirbel): den googleoff-Kommentar (tah-dah!):
https://perishablepress.com/tell-google-to-not-index-certain-parts-of-your-page/
Ob der tatsächlich wirkt und wie die Konkurrenzindexe das halten, müsste man separat evaluieren. Vielleicht weiß der Alberne Idiot was darüber?
Der gibt mir, wenn ich nach Möglichkeiten für Bing frage, dieses Beispiel:
<div> <!-- Dieser Abschnitt wird nicht indexiert --> <meta name="robots" content="noindex"> <!-- Inhalt dieses Abschnitts --> <p>Text, der nicht indexiert werden soll.</p> </div>Äh, echt jetzt? Oder halluziniert er mal wieder?! Laut Inhaltsmodell ist <meta name...> in jedem Element zulässig, das Metadaten-Content erlaubt. Die Inhaltstypen-Übersicht zeigt, dass Meta-Content zum größten Teil auch Flow-Content ist, d.h. alle Elemente, die Flow-Content erlauben, erlauben teilweise auch Meta-Content. Aber der W3C Validator sagt: Nö, falsch.
Nach einer kurzen "Nein - Doch - Nein - Doch - OH" Phase mit ChatGPT hat er dann zugegeben, dass Bing sowas nicht kennt. Ob DAS nun stimmt? Keine Ahnung.
Und wieder zeigt sich: ChatGPT ist ein Idiot.
Rolf
--
sumpsi - posui - obstruxi-
Hallo Robert,
... so etwas wie „Fernsehen“ ... zugangsbeschränkt ... dafür ist das Web konzeptionell nicht gedacht und gemacht.
Also das kann ich so nicht unterschreiben. Frag mal all die Paywalls da draußen. Bzw. die "Kekse oder Kohle" Anbieter.
Da sprichst du mir aus der Seele. Zwar stimmt es, dass meine Inhalte tatsächlich hohen Regionalbezug haben und daher auch - wenn es praktikabel wäre - auf diesen Nutzerkreis beschränkt sein könnten, aber das gilt doch im Grunde für jeden Seitenanbieter, der ein gewisses Missbrauchspotenzial sieht. Das unterscheidet sich dann schon von ökonomischen Interessen, aber die Mittel - Beschränkung - sind dieselben. Im Übrigen war das Netz leider nie so weit von seinem Konzept entfernt wie heute.
Wenn ich Kurzfristangebote gar nicht in einem Index sehen möchte, weil ich nicht vorhabe, sie dauerhaft anzubieten, dann könnte es vielleicht helfen, nach diesem Sachverhalt im Netz zu suchen. Und man findet (trommelwirbel): den googleoff-Kommentar (tah-dah!):
https://perishablepress.com/tell-google-to-not-index-certain-parts-of-your-page/
Interessant. Die Browserweiche winkt jetzt auch hinsichtlich Crawlern...
Ob der tatsächlich wirkt und wie die Konkurrenzindexe das halten, müsste man separat evaluieren. Vielleicht weiß der Alberne Idiot was darüber?
Nach einer kurzen "Nein - Doch - Nein - Doch - OH" Phase mit ChatGPT hat er dann zugegeben, dass Bing sowas nicht kennt. Ob DAS nun stimmt? Keine Ahnung.
Und wieder zeigt sich: ChatGPT ist ein Idiot.
👍
-
Wenn ich Kurzfristangebote gar nicht in einem Index sehen möchte, weil ich nicht vorhabe, sie dauerhaft anzubieten, dann könnte es vielleicht helfen, nach diesem Sachverhalt im Netz zu suchen. Und man findet (trommelwirbel): den googleoff-Kommentar (tah-dah!):
https://perishablepress.com/tell-google-to-not-index-certain-parts-of-your-page/
Ob der tatsächlich wirkt ...
Der Vollständigkeit halber: dieses Ausblenden aus dem Index hat Google nur für seine (laut Wikipedia 2019 eingestellte) "Google Search Appliance" angeboten. Das war eine an Unternehmen auslizensierte Suchmaschinentechnologie für deren Intranet.
Ist schon interessant - scheinbar bestand durchaus ein Interesse daran, den Unternehmens-Datenschatz vor Verwässerung mit Irrelevantem zu schützen. Und verständlich ist auch, dass diese Möglichkeit der Allgemeinheit auf keinen Fall an die Hand gegeben werden sollte.
-
Hallo fietur,
ah, schade. Damit kann man der Datenkrake also keine deklarativen Scheuklappen aufsetzen.
Dann müsste man also die Inhalte erstmal weglassen oder vielleicht auch nur base64-codieren. Und dann den Moment finden, in dem man sie safe decodieren kann - irgendwelche Events, die ein User auslöst, aber kein Bot. Ohne dabei die Zugänglichkeit aus dem Auge zu verlieren.
Was auf Dauer natürlich nur zu einer weiteren Runde im Wettrennen gegen zu schlaue Bots führt. Ich nehme an, Events wie scroll, mousemove oder keydown schickt so ein JS-ausführender Bot ohnehin einfach mal so ins System, um sich als Mensch zu tarnen und damit zu verhindern, dass die Seite dem Bot andere Inhalte zeigt als einem Menschen. Details-Elemente wird er ebenfalls erstmal alle aufklappen (was toggle-Events auslöst).
Vermutlich ist ein Link mit rel="nofollow" zu der Seite mit Inhalten, die nicht indexiert werden sollen, die sinnvollste Lösung.
Wie Du die Bewertungsfunktion vor Bots schützt (POST Requests), hast Du ja schon erfahren. Wenn es Dich stört, viele Miniforms zu haben: das geht auch mit einem einzigen Bewertungsform und vielen Buttons überall auf der Seite, die ein form-Attribut bekommen. Wenn dieses Bewertungsform selbst leer ist und sich nur die Bewertungsbuttons sich per form-Attribut dort einhängen, hast Du auch keinen unnötigen Datentransfer.
Rolf
--
sumpsi - posui - obstruxi-
Dann müsste man also die Inhalte erstmal weglassen oder vielleicht auch nur base64-codieren. Und dann den Moment finden, in dem man sie safe decodieren kann - irgendwelche Events, die ein User auslöst, aber kein Bot. Ohne dabei die Zugänglichkeit aus dem Auge zu verlieren.
Das ist vielleicht das größte Problem. Was ein Screenreader präsentieren kann, wird ein Bot bestimmt nicht ignorieren.
Ohne diese prinzipielle Offenheit gibt es schon Möglichkeiten: Beispielsweise ein Font mit alternativer, einem Ceasar-Code entsprechender Zeichenbelegung, die im Quellcode nur Unsinn anzeigt, auf dem Bildschirm aber ganz normal lesbar ist. Nicht barrierefrei und auch nicht per copy&paste nutzbar - aber für bestimmte Zwecke (ich denke da an Email-Adressen) überlegenswert.
Oder wie wäre es hiermit: Eine Grafik, die alle verwendeten Buchstaben (oder besser noch: Silben) enthält und aus der dann die jeweiligen Ausschnitte hintereinander angezeigt werden... - im Quelltext ziemlich unverständlich.
Was auf Dauer natürlich nur zu einer weiteren Runde im Wettrennen gegen zu schlaue Bots führt. Ich nehme an, Events wie scroll, mousemove oder keydown schickt so ein JS-ausführender Bot ohnehin einfach mal so ins System, um sich als Mensch zu tarnen und damit zu verhindern, dass die Seite dem Bot andere Inhalte zeigt als einem Menschen. Details-Elemente wird er ebenfalls erstmal alle aufklappen (was toggle-Events auslöst).
Was das Wettrüsten angeht, wird am Ende der Bot nicht mehr den Quelltext auslesen, sondern sich das fertige Resultat am Bildschirm über OCR aus dem Pixelmuster ziehen... Die KI-Hardware wird das problemlos ermöglichen.
Vermutlich ist ein Link mit rel="nofollow" zu der Seite mit Inhalten, die nicht indexiert werden sollen, die sinnvollste Lösung.
Auf die Weise hatte ich die Fehlabrufe der Bewertungs-Links tatsächlich drastisch reduziert. Aber eben nur für robots-kooperative Bots. Und ja, POST ist besser geeignet.
Wie verlässlich die Bewertungsfunktion letzlich ist (auch hinsichtlich der menschlichen Nutzer), muss sich noch zeigen. Kann sein, dass klassische Umfragen (mit vorgeschaltetem Individual-Captcha) doch die bessere Lösung sein werden.
-
Moin fietur,
Das ist vielleicht das größte Problem. Was ein Screenreader präsentieren kann, wird ein Bot bestimmt nicht ignorieren.
Und die Umkehrung davon gilt auch, insbesondere dann, wenn ein Bot einen Browser verwendet: Inhalte, die ein Bot nicht ignoriert, können für einen Screenreader unzugänglich sein.
Wenn man Bots „110%ig“ ausschließen möchte, führt kein Weg an einem effektiven Zugriffsschutz vorbei. Punkt.
Ohne diese prinzipielle Offenheit gibt es schon Möglichkeiten: Beispielsweise ein Font mit alternativer, einem Ceasar-Code entsprechender Zeichenbelegung, die im Quellcode nur Unsinn anzeigt, auf dem Bildschirm aber ganz normal lesbar ist. Nicht barrierefrei und auch nicht per copy&paste nutzbar - aber für bestimmte Zwecke (ich denke da an Email-Adressen) überlegenswert.
Und dann schlägt das Laden der Schriftdatei aus irgendeinem Grund fehl …
Oder wie wäre es hiermit: Eine Grafik, die alle verwendeten Buchstaben (oder besser noch: Silben) enthält und aus der dann die jeweiligen Ausschnitte hintereinander angezeigt werden... - im Quelltext ziemlich unverständlich.
Und dann schlägt das Laden der Grafikdatei oder des CSS aus irgendeinem Grund fehl …
Was das Wettrüsten angeht, wird am Ende der Bot nicht mehr den Quelltext auslesen, sondern sich das fertige Resultat am Bildschirm über OCR aus dem Pixelmuster ziehen... Die KI-Hardware wird das problemlos ermöglichen.
Das muss ein Bot nur tun, wenn er die fertige Seite nur als Bild/Screenshot hat. Verwendet er einen Browser, hat er das fertige DOM.
Wie verlässlich die Bewertungsfunktion letzlich ist (auch hinsichtlich der menschlichen Nutzer), muss sich noch zeigen. Kann sein, dass klassische Umfragen (mit vorgeschaltetem Individual-Captcha) doch die bessere Lösung sein werden.
Eine Umfrage mit einem Captcha vorher, welche Nutzer sind da nicht motiviert tatsächlich doch noch eine Stimme abzugeben?
</sarkasmus>Viele Grüße
Robert
-
-
Moin Rolf,
ah, schade. Damit kann man der Datenkrake also keine deklarativen Scheuklappen aufsetzen.
sofern man kein anderes Design seiner Seite verwendet …
Dann müsste man also die Inhalte erstmal weglassen oder vielleicht auch nur base64-codieren. Und dann den Moment finden, in dem man sie safe decodieren kann - irgendwelche Events, die ein User auslöst, aber kein Bot. Ohne dabei die Zugänglichkeit aus dem Auge zu verlieren.
In dem Moment ist die Zugänglichkeit schon nicht mehr gegeben, denn es gibt ausreichend Nutzer, die JavaScript-Ausführung in ihrem Browser zum Teil kontrollieren – es werden ja passende Addons dafür immer mal wieder beworben.
Bots hingegen, die einen Browser (headless) verwenden (z.B. via Selenium WebDriver), kommen trotzdem ziemlich einfach an die Inhalte.
Was auf Dauer natürlich nur zu einer weiteren Runde im Wettrennen gegen zu schlaue Bots führt. Ich nehme an, Events wie scroll, mousemove oder keydown schickt so ein JS-ausführender Bot ohnehin einfach mal so ins System, um sich als Mensch zu tarnen und damit zu verhindern, dass die Seite dem Bot andere Inhalte zeigt als einem Menschen. Details-Elemente wird er ebenfalls erstmal alle aufklappen (was toggle-Events auslöst).
Wie gesagt, unter Verwendung eines Browsers im Bot ist das alles kein großes Problem.
Vermutlich ist ein Link mit rel="nofollow" zu der Seite mit Inhalten, die nicht indexiert werden sollen, die sinnvollste Lösung.
Oder eben die entsprechenden Einträge in der
robots.txtoder in einem<meta name="robots" content="…">…Wie Du die Bewertungsfunktion vor Bots schützt (POST Requests), hast Du ja schon erfahren. Wenn es Dich stört, viele Miniforms zu haben: das geht auch mit einem einzigen Bewertungsform und vielen Buttons überall auf der Seite, die ein form-Attribut bekommen. Wenn dieses Bewertungsform selbst leer ist und sich nur die Bewertungsbuttons sich per form-Attribut dort einhängen, hast Du auch keinen unnötigen Datentransfer.
✅
Viele Grüße
Robert
-
-
Moin fietur,
https://perishablepress.com/tell-google-to-not-index-certain-parts-of-your-page/
Ob der tatsächlich wirkt ...
Der Vollständigkeit halber: dieses Ausblenden aus dem Index hat Google nur für seine (laut Wikipedia 2019 eingestellte) "Google Search Appliance" angeboten. Das war eine an Unternehmen auslizensierte Suchmaschinentechnologie für deren Intranet.
und es wäre auch nur von einem Google-Bot verstanden worden.
Ist schon interessant - scheinbar bestand durchaus ein Interesse daran, den Unternehmens-Datenschatz vor Verwässerung mit Irrelevantem zu schützen. Und verständlich ist auch, dass diese Möglichkeit der Allgemeinheit auf keinen Fall an die Hand gegeben werden sollte.
Das ist doch jetzt hart an der Grenze zum „Verschwörungsmythos“. Mit welchem Interesse hätte man so ein Feature „vor der Allgemeinheit verbergen“ sollen?
Viele Grüße
Robert-
Hallo Robert B.,
Mit welchem Interesse hätte man so ein Feature „vor der Allgemeinheit verbergen“ sollen?
Dass Google höchstes Interesse an allen Webseiteninhalten hat, dürfte unbestritten sein. Je mehr sie wissen, desto besser können sie ihre Werbung ausrichten. Ich bin sicher, dass sie die robots.txt und rel="nofollow" nur zähneknirschend beachten.
In der Search-Appliance sieht die Sache anders aus, da ist die Krake der Appliancebetreiber und nicht Google. Und hausintern macht man auch eigentlich weniger Werbung.
Rolf
--
sumpsi - posui - obstruxi
-
-
-
-
(Bots können z.B. Captchas mittlerweile besser und zuverlässiger lösen als Menschen.)
Einspruch. Manche Captchas. Manche Bots. An verzerrte-Schrift-Captchas scheitere ich regelmäßig. An individuellen Captchas dürften sich hingegen die meisten Bots die Zähne ausbeißen, mangels Trainingsmaterial. Oder dem falschen Trainingsmaterial. Captchas sind aber dennoch Hürden, an denen immer jemand (menschliches) hängen bleibt.
Wenn ich Äpfel mag, interessieren mich Birnen vielleicht auch weniger 😉
Ja, aber wenn ich nur Äpfel angeboten bekomme, weiß ich auch nichts von Orangen. 😀 Und in verschlossene Kisten schaut kaum jemand.
Joah, Google führt JavaScript aus, hält sich aber an die
robots.txt– das sollte ja nun keine schwierige Entscheidung sein. Und wer sich nicht an dierobots.txthält, ignoriert auchdisplay: none, ja sogar HTML-Kommentare (Beweis: in einem HTML-Kommentar eine URL notieren und dann beobachten, wer diese abfragt).Ja, das macht Spaß (solange es eben keine wirklich sensiblen Daten sind). Email-Adressen sind auch so ein Feld, das man prima zum Testen verwenden kann. Es macht aber auch einen Unterschied, ob Inhalt von den "Großen" indexiert und so der ganzen Welt zur Verfügung steht oder eben nicht.
Ich wage zu bezweifeln, dass das von Erfolg gekrönt ist. CSS-Dateien werden ja nicht wegen textueller Information abgefragt, sondern zur Darstellung. Wenn da jetzt aber „sehr viel“ versteckter Inhalt ist, könnten das Suchmaschinen als Täuschungsversuch auffassen und sehr zuverlässig deine Seite ignorieren: durch Ausschluss wegen Täuschung.
Für kommerzielle Seiten, bei denen das Ranking eine sehr große Rolle spielt, kann ich das Argument gut nachvollziehen. Das wäre eine modernere Variante des Keyword Spamming, das ja mit verantwortlich dafür war, sich die keywords lieber selbst zu erstellen. Aber weil ich nicht auf die Suchmaschinen angewiesen bin, kann ich mir erlauben zu sagen, dass das deren Problem ist und nicht meins, wenn ihre hochgelobte KI nicht erkennt, dass oder warum die Seite so und nicht anders aufgebaut ist. Trotzdem ist das natürlich ein berechtigter Einwand.
Im Übrigen wird es ohnehin eher selten und wenig Inhalt sein, der nicht ganz so öffentlich sein soll. Also eigentlich ideal zum Experimentieren.
-
Hallo fietur,
Inhalt, der nicht ganz so öffentlich sein soll
Hast Du schon einen Passwort-Schutz in Erwägung gezogen? Oder Client-Zertifikate - falls dein Benutzerkreis handhabbar und bekannt ist. Mit Zertifikaten sollte es möglich sein, dass nur derjenige die Seite abrufen kann, der das entsprechende Zertifikat auf seinem Gerät hat.
Nachteil: Die Dinger haben ein Verfallsdatum und müssen deshalb regelmäßig erneuert werden.
Rolf
--
sumpsi - posui - obstruxi-
Inhalt, der nicht ganz so öffentlich sein soll
Hast Du schon einen Passwort-Schutz in Erwägung gezogen? Oder Client-Zertifikate - falls dein Benutzerkreis handhabbar und bekannt ist. Mit Zertifikaten sollte es möglich sein, dass nur derjenige die Seite abrufen kann, der das entsprechende Zertifikat auf seinem Gerät hat.
Passwortschutz habe ich natürlich, hauptsächlich für administrative Zwecke (und mit Abstufung der Berechtigungen), nicht für die normalen Besucher.
Zertifikate sind eine interessante Idee, aber ungeeignet, wenn prinzipiell von mehreren verschiedenen Geräten auf die Seiten zugegriffen wird. Abgesehen davon dürften einige Nutzer technisch überfordert sein. Selbst wenn die Installation "aus der Ferne" erfolgt, wäre das teils problematisch weil ungewohnt (wenn auch nicht gänzlich unbekannt, siehe Steuererklärung). Aber die Möglichkeit merke ich mir, das ist sehr interessant, um den Login einzusparen.
Danke für eure Beiträge.
-
-
-
-
-
-
-
-
@@fietur
Ein Formular kann nicht überall eingebunden werden (zB. nicht in einer Tabelle).
Doch, selbstverständlich kann ein Formular (sogar mehrere) in eine Tabelle eingebunden werden. Dank
form-Attribut können sich die Formularfelder über mehrere Tabellenzellen verteilen.☞ Artikel The Form Attribute - Enhancing Form Layout Flexibility (HTMHell-Adventskalender 2023)
Kwakoni Yiquan
--
Ad astra per aspera-
@@fietur
Ein Formular kann nicht überall eingebunden werden (zB. nicht in einer Tabelle).
Doch, selbstverständlich kann ein Formular (sogar mehrere) in eine Tabelle eingebunden werden. Dank
form-Attribut können sich die Formularfelder über mehrere Tabellenzellen verteilen.Vielen Dank, das war mir komplett unbekannt, dass man
<input>aus dem<form>herausnehmen und in eine andere Zelle setzen kann.(Was das für Möglichkeiten eröffnet...)
-
Hi,
Vielen Dank, das war mir komplett unbekannt, dass man
<input>aus dem<form>herausnehmen und in eine andere Zelle setzen kann.(Was das für Möglichkeiten eröffnet...)
Man muß aber aufpassen, daß das Formular noch bedienbar bleibt …
cu,
Andreas a/k/a MudGuard
-
-
-
-
Update und erste Erfahrungen:
Ich habe meine Seite jetzt indexierbar gemacht (also
noindexaus dem Meta-Tag entfernt). Unmittelbar vor "Freigabe" hatte ich einen Artikel überdisplay:noneaus dem DOM entfernt, um ihn der Indexierung zu entziehen. Um ihn menschlichen Besuchern dennoch sichtbar werden zu lassen, wird in einem CSS-File diese Herausnahme mitdisplay:blockwiderrufen und das entsprechende CSS-File in der robots.txt mitdisallowgekennzeichnet. Wenn also z.B. der Googlebot die Seite besucht und lädt, sollte er - sofern er nur das DOM ausliest - den ausgeblendeten Text ignorieren. Ein normaler Besucher hingegen lädt das CSS und lässt den Artikel wieder im DOM erscheinen.Die Seite stand seit Anfang des Jahres im Netz, wurde aber - ganz Meta-tag-konform - nicht in der Google-Suche aufgeführt (auch wenn der Googlebot die Seite natürlich gefunden hatte, weil auf sie vom Vorläufer verwiesen wird).
Kurz nach der Freigabe besuchte der Googlebot die Seite, und wenige Stunden später erschien sie dann auch in der Google-Suche.
Was interessant ist: Der eigentlich aus dem Index auszunehmende Artikel erscheint ebenfalls in der Suche. Als Datum des Abrufs ist aber - wie bei den anderen Artikeln auch - der Jahresanfang angegeben.
noindexbedeutet also lediglich, dass die Seite nicht im Index per Suche öffentlich auftaucht.noindexbedeutet NICHT: "nicht indexieren" - wovon viele ausgehen - sondern "aus dem Index halten". Es ist keine Anweisung, sondern ein Schalter. Gleiches gilt auch fürnofollow, das den Crawler eben nicht anweist, seiner Bestimmung nicht zu folgen, sondern nur, die Beute nicht offen zu zeigen, sie also aus dem Ranking herauszuhalten. Ein himmelweiter Unterschied.Ob die Methode der selektiven Ausnahme von Inhalten durch Entfernung aus dem DOM funktioniert, lässt sich somit noch nicht sagen. Klar ist nur, dass Inhalte, sollten sie jemals nicht durch ein
noindex(und Herausnahme aus dem DOM) "geschützt" sein, bei Google und Co landen. Ob das auch für Inhalte gilt, die immer aus dem DOM herausgehalten wurden, muss sich noch zeigen. Und um es noch einmal klar zu sagen: Es geht nicht darum Inhalte zu verbergen, sondern sie aus den Suchergebnissen herauszuhalten.-
Hi,
Unmittelbar vor "Freigabe" hatte ich einen Artikel über
display:noneaus dem DOM entfernt,nein, damit entfernst Du ihn nicht aus dem Dom, nur aus der Anzeige.
Wenn also z.B. der Googlebot die Seite besucht und lädt, sollte er - sofern er nur das DOM ausliest - den ausgeblendeten Text
wahrnehmen, denn er ist nach wie vor im DOM.
Ob die Methode der selektiven Ausnahme von Inhalten durch Entfernung aus dem DOM funktioniert,
würde voraussetzen, daß die Inhalte wirklich nicht im DOM sind.
cu,
Andreas a/k/a MudGuard
-