vor einigen Tagen, am 21.10. habe ich hier
viewtopic.php?t=748&hilit=google+fonts&start=60
eine neue Idee zur Diskussion gestellt, mit dem man eventuell das Google Fonts Problem betreffs Fonts Scanner/Klagende lösen kann/könnte. Zumindest so lösen, dass kein Scanner und kein Böswilliger ein Datenschutzproblem erkennen kann.
Zitat:
Die nachfolgende Lösung ist ein Kompromiss.Deshalb stelle ich nachfolgende Idee zur Diskussion und würde mich über eure Meinung, Gedanken und Verbesserungen freuen und ob meine Idee realistisch ist.
Folgendes:
Wenn man für das bisherigen MBR3-Projekt eine neue Index-Seite (im eigenen Ordner) vorschalten würde, diese neue Vorschalt-Index mit MBR4 oder MBR5 und mit lokalen Schriften programmieren würde, dann käme der Websitebesucher beim Erstkontakt der Domain NICHT und niemals mit Google Fonts in Kontakt. Das Problem wäre augenblicklich weg.
Von dieser vorgeschalteten Index-Seite würde man über Links oder Bilder dann auf das bisherige MBR3 Projekt verlinken. Die neue Vorschalt-Index könnte ja so ähnlich aussehen, wie beim bisherigen MBR3 Projekt.
Denn wie wir wissen, sind die MBR 0 bis MBR 3 Projekte mit meistens 3 Google-Fonts auf jeder Seite durchseucht. Das ist ohne Softwareherstellerhilfe nicht veränderbar und nicht lösbar. Das ist Fakt.
Es ist der Kompromiss dahingehend, dass
- ein Font-Scanner keine Google Fonts mehr findet
- dass es keine (kaum) MBR-Cookie-Probleme mehr gibt
- dennoch bleiben alle alten Projekt-Seiten bestehen und können durch den Besucher angesehen werden.
- dass an den alten Projekt Seiten weder etwas gelöscht werden muss, noch .CSS oder .JS Dateien geändert werden müssen.
Das kann man sich alles sparen und sich mit relativer Ruhe der Fonts-Kompromiss-Lösung widmen.
Allerdings gibt es einen kleinen Haken, der sich jedoch mit einer Crawling-Abweisung auf den Seiten oder in der Google Search Console lösen lässt.
Der Grundgedanke zur Lösung
Wenn es schon keine Softwarelösung gibt und auch keine echte .htaccess Lösung, dann muss das Thema anders angedacht werden. Die alten MBR Seiten brauchen quasi eine vorgeschaltete Sperrmauer, die ein Font-Scanner nicht durchdringen kann (mal ganz laienhaft beschrieben). Doch wie macht man so eine Mauer und wie könnte das aussehen?
Dazu habe ich letztendlich eine gute Woche gebraucht, bis mir der richtige Weg eingefallen ist. Ich hoffe, dass mir meine Idee nicht einer hier komplett zerpflückt (Spass).
Diese Sperrmauer zu erstellen ist komplett easy und einfach.
Meine Lösung
Ich habe verschiedene Ideen zu meinem Diskussionsbeitrag ausprobiert und dieser hier ist der, der funktioniert!
Ich habe diese heute ausgetestet.
- Kein Font-Crawler findet etwas.
- Cookies sind ebenfalls perfekt.
- Einen Cookie-Banner habe ich noch nicht integriert. Dieser wird noch folgen.
Was ist zu machen? Arbeitsanleitung:
- erstellt ein neues MBR5 Projekt
- erstellt eine neue Index.html
- lagert nun eure Fonts lokal aus (so wie Tommy dies schon mehrfach beschrieben und verlinkt hat)
- erstellt eine neues Impressum erstellt eine neue Datenschutzerklärung
- erstellt eine neue Seite für Cookie-Einstellungen/Veränderungen, wenn ihr einen Cookie-Manager wie z.B. Cookiebot verwendet
- wenn man möchte erstellt man für das neue Projekt noch mehrere Themenseiten wie z.B. Hausschuhe, Wanderschuhe, Straßenschuhe, Damenschuhe, Herrenschuhe usw..usw.. es reicht für die wichtigsten Themen. Grund: Damit euch das Google-Ranking nicht allzusehr abschmiert. Dazu später mehr.
- Bebildert und betextet die Index und die Themenseiten nach eigenem Wunsch
- Setzt von der Index und den Themenseiten nun die Links zu den gewünschten ALTEN Seiten
Aber Achtung bei der Verlinkung zu den ALTEN Seiten, hier beginnt der Trick und der Lösungsansatz mit der "Sperrmauer".
- Ihr müsst euch einen NEUEN Zusatzordner auf dem Server anlegen. Ich habe diesen Zusatzordner "info" genannt.
- In diesen "info" Ordner schiebt ihr den ALTEN assets-Ordner und alle ALTEN .HTML-Seiten hinein, die ihr mit MBR 0 - MBR 3 erstellt habt, hinein.
- mit diesem Trick sind erstmal alle ALTEN Seiten in einem neuen Ordner verschwunden. Weg sind sie!!!
- alle anderen Ordner, die ihr eventuell auch noch auf dem Server habt, lasst ihr dort liegen, wo sie sind.
Linksanpassungen
Nun müssen noch die Links von den neuen MBR5-Seiten zu den ALTEN Seiten angepasst werden.
Beispiel:
Alter Link: https://www.kleinerschuhladen.de/wanderschuhe.html
Neuer angepasster Link: https://www.kleinerschuhladen.de/info/wanderschuhe.html
Das macht ihr nun mit jedem Link zum alten Projekt.
Neues Projekt auf den Server
Auf der frei gewordenen obersten Server-Ebene wird geladen
- der neue assets-Ordner
- alle neu mit MBR5 erstellten .HTML-Seiten in neuer index.html
Das wars bis hierher.
Denn nun kann der Font-Scanner KEINE Google-Fonts mehr von den alten Seiten erkennen.
Hier mein echtes Beispiel, genau so gemacht, wie oben beschrieben:
https://www.salon-in-a-bottle.de/
Ihr könnt diese Seite hier scannen lassen
https://www.ccm19.de/google-fonts-checker/
Optimierung der Google Suche Problematik
Nun bleibt natürlich noch das Problem, dass Google noch alle ALTEN Seiten im Hirn hat, die er bei einer Suchbegriff-Suche noch ausspucken kann. Ein crawlen der alten Seiten müsste verhindert werden. Vielleicht muss man ja auch nix machen, weil die alten Seiten ja quasi eine neue Webadresse auf Grund des Zusatzordners haben. Wenn jemand hierzu mehr weiß.....
Die Optmierung könnte man per robots.txt mit Noindex oder auf der Google Search Console machen.
Info hier zu robots:
https://www.sistrix.de/frag-sistrix/goo ... verbieten/
Info hier zu NoIndex:
https://developers.google.com/search/do ... xing?hl=de
Auf der Google Search Console kann man Google bitten die gewünschten Seiten aus dem Hirn zu entfernen. Ich habe dies schon öfter gemacht. Das funktioniert ganz gut.
Nach einigen Tagen/Wochen dürften dann die alten Seiten nicht mehr in der Suchmaschine zu finden sein.
Gleichzeitig sollte die neue Index und die eventuellen neuen Themenseiten sehr gut SEO-abgestimmt sein, damit das Google Ranking einigermaßen erhalten bleibt. Ob dies sich so bewahrheitet, das zeigt dann die Zeit auf Google. Vielleicht bleibt auch alles so wie es ist. Kommt auf das SEO an.
Fazit (vorläufiges):
Mit dieser Lösung kommt man für den Moment drum herum, dass man auf die ganz Schnelle ein großes ALT-Projekt und in aller Hektik neu erstellen müsste.
Ich selbst werde weitere Projekte auf meine Kompromiss-Lösng ändern und in den nächsten Tagen robots, NoIndex oder Google Search Console entsprechend einrichten.
Keine Rechtsberatung.... Mit meiner Lösung hat man erst einmal viieeel Zeit gewonnen und kann in aller Ruhe seine eigenen Projekt ändern - ohne gleich einen Anwalts/Abmahnschock zu bekommen.
Bei Kunden-Projekten, wie dies bei mir bei in vier ALT-Projekten der Fall ist - mit jeweils mehr als 100 Seiten!!! - kann man mit den vorgeschobenen Index und Themenseiten erst einmal in Ruhe besprechen, wie das weitere Vorgehen sein könnte. Mit meinem Trick/meiner Lösung/meine Idee könnte man eventuell sogar ziemlich lange um eine Erneuerung der ALTEN Projekte herum kommen (keine Rechtsberatung).
Ich finde, dieser Fonts-Kompromiss lässt sich schnell in wenigen Stunden oder an einem Tag realisieren und wäre ein Stück weit vom drohenden Infarkt entfernt.
Freue mich auf Reaktion.
Ich weiß, es ist viel Text, aber ich denke eine echte Hilfe und die vorerst beste (Kompromiss)-Lösung, die ich nach vielen Monaten der Suche und Foren-Schreiberei kenne.
## Auch würde ich gerne von euch wissen, welche Möglichkeiten ihr von diesen hier (robots, NoIndex oder Google Search Console (vorziehen würdet).