nicht angemeldet Felix Riesterer
JürgenB
JürgenB
JürgenB
Camping_RIDER
Rolf B
Gunnar Bittersmann
Rolf B
Rolf B
Gunnar Bittersmann
JürgenB
Auge
Hallo allerseits,
ich versuche mich weiter daran, die "problematische Seite" (und den Rest der Webseite auch) zu verbessern.
Lighthouse Audit (Chrome) meckert mir an, dass die Anzahl der DOM-Knoten zu hoch sei. Maximal 1500 Knoten wären sinnvoll. Weniger sogar noch besser.
**Frage: ** Wenn ich das richtig verstehe, sind die DOM-Knoten die einzelnen, aneinander aufgehängten Elemente der Seite. Angefangen mit <html>, darunter dann <head> und <body> und im <body> dann die <header>, <main> und <footer> .…
Also je "flacher" die Hierarchie und je "weniger" Elemente, um so einfacher und schneller wird das Rendering?
Wo kann ich ansetzen, die Struktur zu vereinfachen?
Meine derzeitige Strategie:
Wie macht ihr sowas? ebenso oder tabula rasa und Struktur und Design von vorn aufbauen?
Da das Ganze aus einem recht "betagten" System erzeugt wird, ist es nicht so einfach, mal eben auf ein neues leichtes GRID zu setzen oder ein neues Theme/Template einzuspielen, da viel vom HTML-Code in einzelnen Funktionen versteckt ist und mühsam umgebaut werden muss.
Für ein paar Tipps wäre ich dankbar.
P.S. Wäre ein Verzicht auf die parallele Auszeichnung als JSON-LD UND microdata sinnvoll? Also microdata weg und nur JSON-LD? Der Fokus liegt auf einer validen Auszeichnung für die Suchmaschinen.
gruß bornstecker
Rolf B
Rolf B
Gunnar Bittersmann
Liebe(r) bornstecker,
Lighthouse Audit (Chrome) meckert mir an, dass die Anzahl der DOM-Knoten zu hoch sei. Maximal 1500 Knoten wären sinnvoll. Weniger sogar noch besser.
das kommt ganz darauf an. Diese Aussage ist eine generische und kann im Einzelfall kein guter Ratschlag sein.
**Frage: ** Wenn ich das richtig verstehe, sind die DOM-Knoten die einzelnen, aneinander aufgehängten Elemente der Seite. Angefangen mit <html>, darunter dann <head> und <body> und im <body> dann die <header>, <main> und <footer> .…
Also je "flacher" die Hierarchie und je "weniger" Elemente, um so einfacher und schneller wird das Rendering?
So die Theorie hinter dem Ratschlag. Ja.
Wo kann ich ansetzen, die Struktur zu vereinfachen?
Keine Ahnung.
Meine derzeitige Strategie:
- CSS-Dateien zusammenfassen und unnötige Anweisungen entfernen
Ausmisten? Das ist immer gut!
- Semantischen Aufbau verbessern (<div style="a"><div class="b"><span class="..">..</span></div></div>-Konstrukte auflösen und durch "leichtere" ersetzen)
Ohweh, das ist eine ermüdende und sehr zeitintensive Arbeit.
- Inhalte reduzieren / entfernen
Wenn Inhalte nicht mehr aktuell sind und auch keinen archivarischen Wert haben, kann man sich schon dazu entschließen, sie zu depublizieren. Auch keine schlechte Idee, auch hier auszumisten.
Wie macht ihr sowas? ebenso oder tabula rasa und Struktur und Design von vorn aufbauen?
Tabula rasa. Hülle bauen, Format für die Inhalte finden, zusammensetzen, fertig.
aus einem recht "betagten" System erzeugt [...] da viel vom HTML-Code in einzelnen Funktionen versteckt ist und mühsam umgebaut werden muss.
Verstehe ich nicht. Kannst Du die Inhalte z.B. in einer Textdatei ablegen? Gut, Textauszeichnungen wird schwierig, vor allem Tabellen, aber hast Du Zugriff auf die "reinen" Inhalte?
P.S. Wäre ein Verzicht auf die parallele Auszeichnung als JSON-LD UND microdata sinnvoll? Also microdata weg und nur JSON-LD?
Welchen Zweck verfolgst Du mit solchen Auszeichnungen? Um welche Art Inhalte geht es denn, wenn die mit Mikroformaten ausgezeichnet werden sollen?
Der Fokus liegt auf einer validen Auszeichnung für die Suchmaschinen.
Du willst, dass der Validator nicht meckert? Dann sorge für valides Markup. Die Komplexitätsstufe hat damit zunächst nichts zu tun.
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
Dann sorge für valides Markup.
Ich habe die Seite mal dem W3C vorgestellt...
Rolf
Hallo Rolf,
Danke für die Vorstellung beim w3c. Hätte schlimmeres erwartet.
Ich weiß nur gerade nicht, was ich für die sections als "h2-6" nehmen sollte
Den Fehler mit den <div> in der Liste fixe ich gerade. Gruß Bornstecker
Hallo bornstecker,
Ich weiß nur gerade nicht, was ich für die sections als "h2-6" nehmen sollte
Das, was da ist. Du musst den header in die Section hineinnehmen, und der Validator sollte zufrieden sein.
Rolf
Hallo Rolf,
ich habe dann mal, aus dem
<article> <header></header> <section></section> </article>
ein
<section> <header></header> </section>
gemacht. Und siehe da... Den Validator freuts.
GRuß Bornstecker
Hallo Felix,
es geht auf der Seite um Termine. Ich dachte der Link "problematische Seite" ist da hilfreich.
aus einem recht "betagten" System erzeugt [...] da viel vom HTML-Code in einzelnen Funktionen versteckt ist und mühsam umgebaut werden muss.
Verstehe ich nicht. Kannst Du die Inhalte z.B. in einer Textdatei ablegen? Gut, Textauszeichnungen wird schwierig, vor allem Tabellen, aber hast Du Zugriff auf die "reinen" Inhalte?
Es ist ein altes CMS, welches aus einzelnen, aktivierbaren Modulen besteht. So ala Plugins bei Wordpress. Die Inhalte (des Termin-Moduls) sind strukturiert in der Datenbank abgelegt. Ich kann also damit machen, was ich will. Das Auslesen und die Ausgabe steuert halt das Modul. Es packt für die Listen mit Terminen jeden Einzeltermin in ein Templateschnipsel und fasst die dann alle zu einer Liste von Terminschnipseln zusammen. Diese Liste wird dann an die vorgesehene Stelle im Designtemplate gepackt und das ganze wird ausgegeben. Das Prinzip ist sicherlich nicht neu.
P.S. Wäre ein Verzicht auf die parallele Auszeichnung als JSON-LD UND microdata sinnvoll? Also microdata weg und nur JSON-LD?
Welchen Zweck verfolgst Du mit solchen Auszeichnungen? Um welche Art Inhalte geht es denn, wenn die mit Mikroformaten ausgezeichnet werden sollen?
JSON-LD ist maschinenlesbar, taugt aber IMHO nicht zur Ausgabe im Frontend. Dient für mich eigentlich dazu, dass die Suchmaschinen mundgerecht aufbereitet Inhalt bekommen.
Die Auszeichnung mit microdata erfolgt ja in den HTML-Elementen und die sind das, was der User zu sehen bekommt.
Du willst, dass der Validator nicht meckert? Dann sorge für valides Markup. Die Komplexitätsstufe hat damit zunächst nichts zu tun.
Ok. Daran arbeite ich schon.
Gruß Bornstecker
Hallo,
warum stecken die Termine im HTML und im Script-Bereich?
Gruß
Jürgen
Hallo Jürgen,
Script-Bereich als Futter für den Crawler, Microdata weil ich dem User ja auch was zeigen muss und die Auszeichnung dort "einfach" war.
Gruß Bornstecker
Script-Bereich als Futter für den Crawler,
Nennt sich Cloaking. Ist Pfui.
.-.-.
Sorry pl...
Script-Bereich als Futter für den Crawler,
Nennt sich Cloaking. Ist Pfui.
Da liegst Du meiner Meinung nach voll daneben. Das was ich da mache ist saubere Bereitstellung strukturierter Daten und kein Cloaking.
Warum mache ich das so? Nachlesen unter Strukturierte Daten erstellen, testen und veröffentlichen
Ergebnis siehe Testtool für strukturierte Daten
Solch eine pauschale Unterstellung weise ich von mir!!!
Bornstecker
Hallo,
irgendwie tun mir die Leute Leid, die jeden Vorschlag von Google aufnehmen, nur um im Ranking etwas nach oben zu rutschen, statt einfach nur gute Inhalte gut lesbar für Menschen aufzubereiten und anzubieten.
Gruß
Jürgen
Hallo Jürgen,
Du bist also der Meinung, die Art und Weise der Aufbereitung der Inhalte auf meiner Seite ist nicht gut für Menschen lesbar?
Was stört dich denn genau?
Gruß bornstecker
Hallo,
Was stört dich denn genau?
hast du mal einen Blick in den Quelltext geworfen? Etwa die Hälfte ist der <script type="application/ld+json">-Block, der für Menschen unsichtbar ist, wenn sie sich nicht gerade für den Quelltext interessieren, und der – wenn ich das richtig sehe – den Seiteninhalt nur maschinenlesbar liefert.
Gruß
Jürgen
Edit: Gerade noch mal nachgezählt: der json-Block ist 1116 Zeilen bzw. 43814 Bytes lang!
Hallo,
irgendwie tun mir die Leute Leid, die jeden Vorschlag von Google aufnehmen,
wobei ja GG selbst die Empfehlung gibt, daß MD oder RDF nur dann als Anreicherung betrachtet werden wenn sie 1:1 auch für den normalen Betrachter lesbar sind. Mit anderen Worten ausgedrückt: Daten/Texte die im Dokument versteckt (verhüllt: cloaking) aber nach außen nicht sichtbar sind, sind sowohl für den Betrachter als auch für die Suchmaschine wertlos.
Diesen Prinzipien folgte GG schon vor 20 Jahren, also lange vor HTML5 und damit auch vor RDF. Natürlich lassen sich daraus bestimmte Schlüsse ziehen, insbesondere hinsichtlich Reduzierung der Inhalte einer Einzelseite auf das Wesentlich und zwar so daß es benutzerfreundlich und überschaubar ist.
Das sind aber auch Dinge auf die man mit ein bischen Überlegung selber kommen kann.
.-.-.
Hallo pl, hallo Jürgen,
vielen Dank für die Hinweise. Ich versuche mal zu sortieren und für mich zusammenzufassen.
Verzicht auf JSON-LD, aufgrund der "Unsichtbarkeit" (Cloaking) für normale Benutzer und der vorhandenen redundanten Auszeichnung via Microdata
Reduzierung des Quellcodes aufgrund von Entfernung JSON-LD
Umstellung von Microdata auf RDFa wegen Einsparung von Code (siehe Überhaupt halte ich microdata für blöd und RDFa das bessere Mittel zum Zweck.)
Habe ich etwas vergessen?
Gruß Bornstecker
@@bornstecker
- Umstellung von Microdata auf RDFa wegen Einsparung von Code (siehe Überhaupt halte ich microdata für blöd und RDFa das bessere Mittel zum Zweck.)
Einsparung von Code ist nicht der Grund. Nochmal Chaals (ab 44:27):
“I suspect we will continue de-emphasizing Microdata until we stop saying it at all. […] Microdata is the only format we use which is not 1-to-1 mappable with RDF. You can do it, but it’s painfull.”
LLAP 🖖
Aloha ;)
Daten/Texte die im Dokument versteckt (verhüllt: cloaking) aber nach außen nicht sichtbar sind, sind sowohl für den Betrachter als auch für die Suchmaschine wertlos.
Nicht alles, was an unsichtbaren Daten im Dokument ist, führt direkt zum Schluss, dass da "Cloaking" betrieben wird. Cloaking bezeichnet da ein sehr spezifisches Verhalten.
Ich wiederhole gerne, was andere bereits in anderen Kontexten zu dir gesagt haben: Du kannst nicht einfach Worte umdefinieren oder ihre allgemein anerkannte Bedeutung ignorieren.
Du kannst das natürlich tun, aber das führt dann dazu, dass Andere nicht mehr verstehen was du ihnen sagen willst. Wie der OP, der sich hier (verständlicherweise) angegriffen gefühlt hat, als du ihm Cloaking vorwarfst, obwohl du nur sagen wolltest, dass da nicht menschenlesbare Daten auf der Seite sind.
Ja, eine exorbitante Menge nicht-menschenlesbarer Daten ist definitiv kein sinnvoller Stil (zumindest für mich nicht - ich gehe da mit JürgenB), und ja, Cloaking ist schlimm, aber nein, das ist kein Cloaking!
Das ist ja manchmal das Gefährliche an deinen Aussagen, dass man sich die unpassenden Behauptungen mit der Pinzette raussuchen muss um die Spreu vom (definitiv vorhandenen) Weizen zu trennen...
Grüße,
RIDER
Hallo Camping_RIDER,
du hast insofern recht, dass Cloaking[1] anders belegt ist.
Wenn sich eine Suchmaschine aber ausschließlich auf die JSON-LD Daten verlässt, ist der Effekt der gleiche: es werden nicht die Daten indexiert, die der User zu sehen bekommt, sondern solche, die speziell für die Suchmaschine bereitgestellt werden. Es ist in der Verantwortung des Seitenbetreibers, beides gleich zu halten, und es ist ein Ansatzpunkt für Manipulation, wenn man gezielt Unterschiede einbaut. D.h. ein SE-Betreiber muss eigentlich zusätzlich zu den JSON-LD Daten auch den Textteil der Seite scannen, um sicher zu sein, vom JSON-LD nicht beschummelt zu werden.
Im Gegensatz zum unerwünschten Cloaking kann man bei JSON-LD aber immerhin noch im ausgelieferten Dokument erkennen, ob die JSON-LD Daten konsistent zum sichtbaren Teil der Seite sind.
Und LD ist ja auch eigentlich nicht für Suchmaschinen gebaut worden, sondern als eine allgemeine Idee des Semantic Web, gelle?
Rolf
Für diejenigen unter uns, die keine SEO Experten sind und - wie ich - den Begriff erstmal raussuchen mussten. ↩︎
Aloha ;)
Und LD ist ja auch eigentlich nicht für Suchmaschinen gebaut worden, sondern als eine allgemeine Idee des Semantic Web, gelle?
Richtig - deshalb schrieb ich ja was von „das ist für mich kein sinnvoller Stil“. Deine Argumente sind auf jeden Fall zutreffend - ich wollte auch in keiner Form die versteckten JSON-Daten verteidigen, ich wollte nur klarstellen was von der Unterstellung zum Thema "Cloaking"[1] zu halten ist.
Grüße,
RIDER
Ich musste auch googlen 😉 ↩︎
Ich habe hier niemanden angegriffen. Sondern nur den Begriff erklärt. Cloaking frei übersetzt heißt Verhüllen und genau das trifft ja für den Sachverhalt zu.
Und genau deswegen gibt ja GG selbst die Empfehlung, Metadaten sichtbar zu machen. Andernfalls wäre es Cloaking. MFG
Aloha ;)
Ich habe hier niemanden angegriffen. Sondern nur den Begriff erklärt.
Da fehlt ein V. Du hast ihn verklärt.
Cloaking frei übersetzt heißt Verhüllen und genau das trifft ja für den Sachverhalt zu.
Du faselst.
Wozu erst ein englisches Wort übersetzen, um es dann in einen deutschen Sachzusammenhang zu verpacken?
Wenn du sagen wolltest, er solle keine Inhalte verhüllt anbieten, oder er solle keine Inhalte in versteckter Form anbieten, warum sagst du dann nicht genau das?
Wozu das Wort Cloaking an der Stelle? Richtig - um zu sagen, dass Cloaking pfui ist. Ist es aber nur, wenn man auch wirklich Cloaking (als Fachwort!) betreibt.
Du benutzt also zunächst ein Fachwort, verweist dann auf eine freie Übersetzung, und dann darauf, dass die Übersetzung auf den Sachverhalt zutrifft. Dann lass doch einfach das anderssprachige Fachwort gleich sein, wenn du es nicht in seiner Bedeutung als Fachwort meinst.
Darum gehts dir aber gar nicht - und mir soll es auch egal sein. Ich wollte dem TO, der dich nicht kennt, nur zu verstehen geben, wie er deinen Kommentar einzuordnen hat, und das habe ich mit deiner Hilfe ja nun geschafft.
Grüße,
RIDER
Sie verstehen ja immer noch nicht. Aber wahrscheinlich sind Sie einfach nur arrogant!
@@pl
wobei ja GG selbst die Empfehlung gibt, daß MD oder RDF nur dann als Anreicherung betrachtet werden wenn sie 1:1 auch für den normalen Betrachter lesbar sind. Mit anderen Worten ausgedrückt: Daten/Texte die im Dokument versteckt (verhüllt: cloaking) aber nach außen nicht sichtbar sind, sind sowohl für den Betrachter als auch für die Suchmaschine wertlos.
Au weia! Da hab ich doch tatsächlich in 101 cloaking betrieben.
Die Information, dass Warschau in Polen liegt, ist für RDFa-Leser verfügbar; für Textleser aber nicht. Wie böse ist das denn bitte?
LLAP 🖖
Abstrakt gesehen ja, hast Du. Der Begriff Cloaking ist zwar viel älter als HTML5 (was RDF erst ermöglichte) aber in dem Moment wo JSON-LD oder RDF-Daten nur im Quellcode versteckt werden ist das Cloaking.
Und ja, keine Ursache, aber nochmal erkläre ich das nicht!
Hallo bornstecker,
das Problem ist, dass die Seite sehr viele Informationen enthält. In der Mobilversion schaffst Du mit etlichen Aufklappfunktionen Übersicht, aber sowas kann ein generisches Tool nicht beurteilen.
Wirklich deutlich reduzieren kannst du nur, wenn Du weniger Termine pro Seite anzeigst.
Rolf
Hallo Rolf,
Wirklich deutlich reduzieren kannst du nur, wenn Du weniger Termine pro Seite anzeigst.
DAS ist genau das, was ich ja vermeiden will. Das wird ja ein elendes Geblätter, wenn ich da zB. nur 10 Termine anzeige 😀
Eventuell würde ja ein automatisches Nachladen helfen, den Start zu beschleunigen. Also erstmal die ersten 10 Termine und beim runterscrollen dann immer weitere 10er-Pakete. Leider scheitere ich da noch an der technischen Umsetzung.
Und die vorhandenen Informationen "flacher zusammenzupacken" würde für mich im Umkehrschluss bedeuten, bei den einzelnen Terminen die microdata-Elemente zu entfernen und damit die Anzahl der Elemente zu reduzieren.
Gruß Bornstecker
Hallo bornstecker,
infinite scroll ist eine hässliche Sache, weil man dann nämlich keine Links in den Footer setzen sollte (so böse Dinger wie Kontakt und Impressum; wenn man da nicht rankommt winkt der Abmahnteufel). Ich habe selbst noch keins gebaut und kann darum auch keine Tipps geben, wie es geht. Aber das Web ist sicher voll davon.
Was für die Verfügbarkeit der Footer-Links hilft, ist ein 100vw/100vh Seitenrahmen, aus Header, Hauptbereich und Footer. Nur der Hauptbereich ist scrollbar, und der Footer immer vorhanden, trotz Infinite Scroll. Nachteil: Ständig verringerter Bildschirmplatz, d.h. der Footer muss sehr klein bleiben. Und ob Dein CMS das hergibt ist natürlich erst noch die Frage.
Was Dir nicht hilft, ist das Abspecken von CSS. Weil - das misst dein QA-Tool gar nicht. Du hast allerdings 6 CSS Dateien, die alle geladen werden müssen. Sind sie im Cache, ist's nicht so schlimm, beim ersten Laden sind das aber 6 Webrequests die abzusetzen sind. Eine Minifizierung ist nicht unbedingt nötig, weil Du eh gzip schickst, aber Bundling zu einer CSS Datei kann helfen. Dafür gibt's Tools, meistens auf node.js basierend, die man einmal laufen lässt und dann die Dateien zu einer zusammenfügen (z.B. SASS oder LESS). Diese Tools können noch viel mehr, aber Bundling ist eins ihrer Features. Wobei man beim Bundling aufpassen muss, bündelt man zu stark, stehen die ersten Styles erst zur Verfügung wenn der letzte ausgepackt ist und die Seite zuckt beim Laden 'rum. Die wichtigsten Styles, die "above the fold" Styles, muss man ggf. separat laden. Aber 2 CSS Dateien sind auf jeden Fall besser als 6.
Sodann lädst Du jede Menge Bilder (PNG und SVG). Ein paar PNGs hast Du schon zu einem Spritesheet zusammengefasst, sehr gut. Vielleicht geht da noch mehr. Auch SVGs kann man zu Sprites zusammenfassen. Das kann die Ladezeit beschleunigen.
Die ganzen Google-Sachen sind vom Laden her recht teuer. Das Download-Volumen der Seite wächst von gut 200K auf über 700K, es finden 70 Webrequests statt 30 statt und es vergehen 2,2s statt 0,7s, bis die Seite komplett geladen ist. Die längere Zeit ist aber nicht so schlimm, weil ein großer Teil davon passiert nachdem die Seite sichtbar und benutzbar ist. Ich glaube, das kannst Du nicht ändern (weil Du die Werbung ja drin lassen willst).
Das JSON LD ist schon ein Batzen. Den Nutzen kann ich nicht beurteilen, ich schreibe Intranet-Webseiten, die Google nicht zu sehen bekommt. Du könntest es ggf. ans Ende der Seite stellen, damit die Seite schon mal sichtbar ist, während der Browser noch daran ruminterpretiert.
Dieses AddToCalendar Gedöne ist allerdings ein Klops. Jeder Datenblock doppelt und einiges an HTML pro Termin. Kennt das Tool keine elegantere Möglichkeit, das zu steuern?
Rolf
Hallo Rolf,
das mit dem AddToCalendar ist mal als nettes Feature gedacht gewesen, damit sich der geneigte User "einfach" den Termin in seinen Kalender eintragen kann. Alles in allem werde ich das wohl mal rauswerfen und warten, dass jemand es vermisst.
Danke schon mal für die Tipps.
Gruß Bornstecker
Was Dir nicht hilft, ist das Abspecken von CSS. Weil - das misst dein QA-Tool gar nicht.
Doch tut es, aber das Optimierungspotenzial hierfür ist so gering (so sieht es jedenfalls Lighthouse), dass der Aufwand nicht lohnt - oder noch nicht lohnt, weil es größere Baustellen gibt.
@@bornstecker
P.S. Wäre ein Verzicht auf die parallele Auszeichnung als JSON-LD UND microdata sinnvoll? Also microdata weg und nur JSON-LD?
Es ist sicher nicht sinnvoll, dieselben Metadaten doppelt in einem Dokument zu haben. Also ja, weg mit einem davon.
Überhaupt halte ich microdata für blöd und RDFa für das bessere Mittel zum Zweck.
Der Fokus liegt auf einer validen Auszeichnung für die Suchmaschinen.
Suchmaschinen sollten RDFa und microdata genauso lesen wie JSON. Ob sie das auch wirklich tun, kann ich dir leider nicht sagen.
LLAP 🖖
@@Gunnar Bittersmann
Es ist sicher nicht sinnvoll, dieselben Metadaten doppelt in einem Dokument zu haben.
„Doppelte Pflege ist so gut wie niemals bessere Pflege.“ —yours truly
LLAP 🖖
Hallo Gunnar,
ob die Wartbarkeit der Daten im vorliegenden Fall ein valides Kriterium ist, wäre zu prüfen. Bornstecker nutzt ein CMS.
Die Frage ist: ist dieses HTML Source- oder Objectcode?
Die Frage ist auch: Wieviele und welche Semantiksoßen muss man über den Datenbrei gießen, damit er allen (wichtigen) Konsumenten schmeckt? Wenn es genau eine gibt - nehmen. Wenn es mehrere gibt, aber eine davon hinreichend ist - die verwenden, die den geringsten Overhead produziert. Ich bin im Thema nicht drin und weiß nicht, ob hier der Schokopuddingstreit aus meiner Kindheit fortgesetzt wird ("mit Sahne!" - "mit Vanillesauce!"). Mama hat sich immer geweigert, beides zu machen...
Rolf
ob die Wartbarkeit der Daten im vorliegenden Fall ein valides Kriterium ist, wäre zu prüfen. Bornstecker nutzt ein CMS.
Rolf hat Recht. Ich habe zwar 2 verschiedene Strukturen, die gepflegt werden, aber die Daten kommen aus der gleichen Basis. Ich korrigiere also nicht an zwei Stellen die Daten. Eher an 2 Stellen die Struktur (JSON-LD und RDFa (ehem. Microdata)) 😀
Soll heißen. Ich habe einen falschen Betthofen in der Datenbank - ergo - 2 falsche in JSON-LD und RDFa Ich korrigiere den Beethofen in der Datenbank und in JSON-LD und RDFa steht der richtige.
Gruß Bornstecker
Hallo
Ich habe einen falschen Betthofen in der Datenbank - ergo - 2 falsche in JSON-LD und RDFa
Ich korrigiere den Beethofen in der Datenbank und in JSON-LD und RDFa steht der richtige.
Wenn du, vorausgesetzt, du meintest den Beethoven, dann noch den Beethofen korrigierst, scheint morgen vielleicht die Sonne [1]. 😉
Tschö, Auge
So, als ob man sein Essen aufgegessen und den Teller ratzekahl geplündert hat. 😀 ↩︎
Danke an alle Kommentatoren für die Hinweise, Anregungen und Tipps. Ich habe das ganze jetzt mal umgebaut.
Ergebnisse:
optisch sieht es also für den Benutzer "genau wie vorher" aus. Mal sehen, was die Suchmaschinen daraus machen.
Vielen Dank Bornstecker
Hallo,
noch eine Anmerkung: Dein Link zum Impressum ist erst erreichbar, wenn man die Cookies akzeptiert hat. Ich weiß nicht, ob das OK ist.
Gruß
Jürgen
Hallo Jürgen,
danke für den Hinweis. Ziehe ich glatt. 😉
Gruß Bornstecker
Schon eine Lösung gefunden?
Hallo
Schon eine Lösung gefunden?
Unwillig, den Thread zu lesen?
Tschö, Auge
Hallo Helmut,
Jo. Steht in der Antwort von mir vom 7.3.19.
Danke an alle Kommentatoren für die Hinweise, Anregungen und Tipps. Ich habe das ganze jetzt mal umgebaut.
- JSON-LD wurde entfernt
- Microdata wurden in RDFa umgewandelt
- Codekosmetik wegen w3c
- AddEvent-Buttons entfernt
