Die (Kompromiss)-Lösung für das Google Font Problem von MBR 0 bis MBR 3

[Dietmar]

Hallo Tommy, Hallo Mitglieder,

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:

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.

Die nachfolgende Lösung ist ein Kompromiss.
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).

[Tommy Herrmann]

Moin,

habe jetzt (noch) nicht alles komplett von Deinem langen Eintrag gelesen, aber anscheinend sprichst Du nur von der Startseite.

Google findet doch jede Seite - auch die Unterseiten, die bei Dir dann nach wie vor "Google Fonts" beinhalten. Ich weiß nicht, wie Du auf die Idee kommst, dass in Deinem Ordner "info" dann irgendwas verschwunden sein könnte.

Ich habe, außer meiner Startseite, ca. 80 Projekte in solchen Unterverzeichnissen liegen. Wo irgendwelche Seiten liegen, ist doch dem Anwalt, der Dich abmahnen will, vollkommen egal und auch Google - Google würde die ebenso 20 Verzeichnisse tiefer sogleich finden.

Zum Beispiel diese Seite von Dir hier:

https://www.salon-in-a-bottle.de/info/h ... -a-41.html

Der Font-Checker, den Du da verwendest findet nichts - keine Ahnung warum - der taugt wohl nichts

Dieser Font-Checker findet jede Menge Einträge (siehe Screenshot):

https://sicher3.de/google-fonts-checker/

Hinzu kommen die Verweise innerhalb der CSS-Dateien vom Thema "Mobirise3", wie zum Beispiel hier:

https://www.salon-in-a-bottle.de/info/a ... tional.css

Mobirise arbeitet aber gerade an einem neuen "Cookie Alert", mit dem man solche Einträge und viel mehr bis zur Zustimmung des Besuchers komplett sperren kann. Diese werden dann auch nicht im Hintergrund bereits geladen. Es gibt dazu schon eine BETA-Version, die noch leicht fehlerhaft ist. Ich denke, dass in Kürze ein Update kommt und dann diese Sperrung auch für "Mobirise3" Themen zur Verfügung stehen wird.

... oder Du beschäftigst Dich mal mit so einem Cookie-Blocker wie z.B. "CookieFirst", das sollte das Problem lösen:

https://cookiefirst.com/de/

[Dietmar]

Hallo Tommy,

du solltest zu Ende lesen.

Natürlich werden Fonts gefunden, wenn man die neue Adresse für die alten Seiten findet. Aber NICHT wenn du die neuen Seiten aufrufst und der Fonts-Checker findet nichts, wenn die NEUEN aufgerufen werden. Und natürlich taugt der angegeben Font-Checker etwas!

Wenn du bis zu Ende gelesen hättest steht dort nämlich auch, wie man die ALTEN Seite aus dem Hirn von Google herausbekommt. Aber das weißt du ja selbst auch.

Für die ersten Wochen und Monate kann Google die NEUEN Seiten im Suchergebnis ebenfalls nicht anzeigen, weil er diese neuen Adressen so schnell nicht kennt bzw. so schnell nicht ausgibt.

Der Font-Checker kann ebenfalls im durchlaufenden AUTOMATISMUS nur das checken, was er kennt. Die NEUEN Adressen sind jedoch vorerst nicht bekannt - weder bei Google Suchergebnisse noch bei den bösen Jungs.

Beispiel zu dem Beispiel, welches du oben genannt hast.

Bekannt ist bei Google jedoch nur diese alte Webadresse. Diese würde Google jetzt noch in der Suche als Ergebnis anzeigen:
https://www.salon-in-a-bottle.de/haarve ... -a-41.html

Das Anzeige-Ergebnis ist jedoch bei der Suche: " Not found". Warum? Weil es eine neuere Adresse für Google (noch) NICHT gibt. Ein böser Junge müsste sich eine aufwändige Mühe machen, um eine neue Adresse für die alten Seiten überhaupt zu finden. Und dazu müsste er auf die Website und danach suchen. Würde er das machen? Wohl kaum, das kostet viel zu viel Zeit!

Etwas anderes als die NEUE Index und die NEUEN Unterseiten kann Google für die nächste Zeit auch nicht finden, denn die ALTEN Seiten sind zudem in einem neuen Ordner mit Beispiel "/info/"versteckt. Die alten Seiten werden zusätzlich durch entsprechende Programmierung fürs Crawlen abgewiesen oder bei der Google Search Console eine Löschung beantragt.

In den Sitemaps sollten die alten Adressen und die neuen Adressen ebenfalls nicht enthalten sein. Aber dies sollte selbstverständlich sein.

Nun zu dem Font-Checker, den du angegeben hast. Den kenne ich selbstverständlich auch :-), diesen hier
https://sicher3.de/google-fonts-checker/

Gebe die Adresse ein, welche Google jetzt noch für längere Zeit findet:
https://www.salon-in-a-bottle.de/haarve ... -a-41.html

Ergebnis auch bei deinem Checker:
Zitat:

Keine nachladenden Schriftarten gefunden! Yeah, wir konnten keine Schriftarten finden, die von Google nachgeladen werden. Es besteht derzeit kein Handlungsbedarf.

Gebe die Adresse ein, welche Google aktuell finden kann (und das wären die neue Index, die neuen rechtlichen Seiten und eventuelle neue Unterseiten):
https://www.salon-in-a-bottle.de/

Ergebnis auch bei deinem Checker:
Zitat:

Keine nachladenden Schriftarten gefunden! Yeah, wir konnten keine Schriftarten finden, die von Google nachgeladen werden. Es besteht derzeit kein Handlungsbedarf.

Wie du siehst, meine Lösung ist zwar ein Kompromiss, bis es EVENTUELL eine andere Lösung gibt. Das gibt einem die Zeit sich was Neues zu überlegen und umzusetzen. Es gibt einem erst einmal die Ruhe, weil kein Font-Checker ohne die neue Adresse auch nix finden kann.

[Tommy Herrmann]

Also bei mir findet Google (ganz von alleine) oft meine neuen Seiten innerhalb von 1 Stunde, auch schon mal nach 20 Minuten

Außerdem brauche ich keinen Font-Checker um Google Fonts zu finden - das sehe ich auf Anhieb am Quelltext.

[Dietmar]

Hallo Tommy,

wir werden sehen. Wenn Google meine neuen Adressen ausgibt, dann muss ich eingestehen, dass meine Idee keine Idee war. Ich bin ja selbst gespannt für die nächsten Tage. Ich sage ja nicht, dass ich den Stein des Weisen gefunden habe.

Ich habe ähnliches schon mal gemacht und Google hatte damals die alten Seiten mit neuer modifizierter Adresse NICHT angezeigt.

Es bleibt spannend.

Ich werde weiterhin berichten, wann und ob sich etwas im Google Seiten Index verändert.

[Dietmar]

Hallo Tommy,
ja, du hast recht, dass Google NEUE Seiten in relativ schneller Zeit in den Suchergebnissen anzeigen kann. Der Tenor liegt auf "NEUE" Seiten.

Aber hier, mit meiner Kompromiss-Idee, werden bekannte alte Seiten, welche im Google Index vorhanden sind, in einen neuen Ordner umgeschichtet.

Natürlich sehe ich auf der Google Search Console (GSC)öfters am Tag nach, ob sich etwas an den indexierten Seiten für meine Muster-Website ändert. So schnell wird sich da auch nix ändern.

Ich kann dir sagen, dass sich hier auf GSC nach einem Tag noch NICHTS geändert hat. Google hat logischerweise immer noch die alten Webadressen in seinem Index und nur die kann er bei einer Suchbegriffs-Suche anzeigen und dann gibts als Ergebnis: "not found". Ganz einfach. Vorerst.

[Dietmar]

Hallo Tommy,

klar benötigt man keinen Font-Checker und natürlich sieht man das gleich im Quelltext.

Aber du müsstest dich in die Situation eines Böswilligen versetzen. Dieser sucht mit einem entsprechenden Scanner das Internet ab. Der kennt doch überhaupt nicht die veränderte Situation auf einer bearbeiten Website. Er kennt doch die neue ALT-Seiten-Adresse doch überhaupt nicht. Der kann doch nur das Crawlen, was Google ausspuckt und das sind jetzt nur die NEUEN Seiten und jetzt nur die "not found"-ALTEN Seiten.

Das Ergebnis ist: "Keine Google Fonts gefunden"

[Tommy Herrmann]

... versuche es halt - rechtssicher ist das aber auf keinen Fall.

Ich würde Dir raten mal diese "CookieFirst" Sache anzusehen. Ich glaube eine Seite ist sogar kostenlos.

[Dietmar]

Hallo Tommy,

es geht auch nicht um Rechtsicherheit. Wie soll die Idee auch. Man muss doch nicht gleich ALLES in Perfektion haben, ALLES gleich optimal haben. Das ist so typisch Deutsch. Aber die Idee verschafft viel Zeit und zwar augenblicklich.

Eine automatisierte Fontscannung hat mit meiner Idee so ziemlich keine Chance. Und wenn kein Font entdeckt wird, gibt es auch kein "Schreiben". Muss man vorerst auch nichts zahlen. Hat man mehr Zeit für eine Runderneuereung seiner Website. Ist dies denn nichts?

[Dietmar]

Hallo Tommy,

zu "CookieFirst". Ich bin bei "Cookiebot", ist so ziemlich das gleiche. Dieser kommt bei allen meinen Websites seit Jahren zum Einsatz.

[Tommy Herrmann]

ja - aber der sammelt Daten in den USA - noch schlimmer als Google und wird evetuell verboten.

https://www.datenschutzexperte.de/blog/ ... ot-wissen/

[Dietmar]

Nein, der ist NICHT unbedingt schlimmer
der sammelt im Moment noch die IP auf USA Servern. Da es ein Dänemark Unternehmen ist, wird das wohl nicht lange so bleiben/können. Das Ganze ist ein ewig langer Gerichtsakt, das kann dauern.

Hier die aktuelle Situation:
https://www.heise.de/news/Daten-in-die- ... 45246.html

Das heißt: 10.000er Unternehmen können Cookiebot problemlos weiter nutzen.

... und wenn du genauer wissen möchtest, welche CCM-Anbieter es betreffen könnte, dann siehe hier, nämlich auch der von dir beschriebene "CookieFirst"!
https://www.ccm19.de/cookie-dienste-die ... erden.html

Ob dies alles letzter Stand ist, kann ich auf die Schnelle gerade nicht herausfinden, aber ich denke schon.

[Klaus]

Vielleicht mal die Frage was eigentlich dagegenspricht erst mal lokal zu Publizieren, mit grepWin o. Ä. die Verweise von google auf den lokalen Server zu tauschen und die Seite dann mit Filezilla o.Ä. hochzuladen.

Ja man muss das nach jedem Publizieren mal schnell (2 Min.) machen und ja man muss vorher 1 malig (außer man tauscht Fonts) so in der "stobi Art" alle Fonts mal auf den Server bringen und 1 angepasste CSS anlegen.
Aber sonst?

... mit der Methode muss man nicht verstecken spielen weil ja wirklich alles lokal ist.

Und sogar das URL tauschen könnte man wenn man grepWin nicht nehmen will in das Witsec Plugin reinschreiben wie ich es hier
viewtopic.php?p=7965#p7965
gemacht habe.

Meine Empfehlung ist ja eh mit grepWin den "Output" von MR vor dem Hochladen erst mal auf google und gstatic durchsuchen zu lassen. (Hat sich ja auch gezeigt dass glaube bei MR3 Vorlagen in einer CSS auch noch Verweise drinnen sind.)

[Dietmar]

Hallo Klaus,

wie Tommy schon in einem anderen Diskussionsbeitrag geschrieben hat, das ist echt ne Nummer zu schwierig.

Ich selbst bin nun keine Größenordnung beim Programmieren, kann ein bisschen Code lesen und oftmals etwas durch Nachdenken umändern. Aber auch für mich. ist das was hier geschrieben hast, ein Buch mit sieben Siegeln. Für einen (fast) Laien-Dummi wie mich nicht verständlich und daher kaum umsetzbar.

Auch ich gebe zu bedenken, ob eine Änderung der Fonts-Adresse (wenn ich das in der kürze der Zeit richtig auf dem Screenshot gesehen habe) aus urheberrechtlichen Gründen nicht letztendlich sogar sehr strafbar ist - das könnte durchaus eine "heiße" Nummer werden die durchaus teuer werden Könnte. Falls das Google oder wer auch immer entdeckt. Ich weiß nicht...? Tommy hat ja auch so seine Bedenken.

[Klaus]

Ich weiß jetzt zwar nicht wo es ein "urheberrechtliches Problem" geben sollte wenn Du in DEINER html den Pfad von google auf DEINEN Server lokal legst und dort die Fonts hinterlegst die Du ja bei google unter https://fonts.google.com downloaden kannst ... aber das muss jeder selber wissen.

Falls das illegal wäre dann wäre ja vermutlich wohl auch das 2te Tut von Tommy nach der "stobi" Methode illegal weil da machst Du das in der project ja auch nur dass es dann gleich beim Generieren durch MR getauscht wird.
Vielleicht ist ja schon das Fummeln in der project.mobirise illegal?

Ich lass jetzt mal gut sein, ich hab auch n paar Tag mit dem Thema verplempert und schalte jetzt wieder bei mir das Blocken von google ein was bei mir eigentlich Default ist weil ... ich bin tatsächlich jemand der sich "unwohl fühlt" wenn google immer und überall mitschüffelt.

Noch die FAQ zu den Fonts: https://developers.google.com/fonts/faq und auf https://github.com/google/fonts die Info wie man "Download All Google Fonts", Lizenzinfos sind auch dabei.

[Tommy Herrmann]

Klaus,

nein - wenn ich die von Google freigegebenen Fonts downloade, dann spreche ich ja meinen Server an. Wenn ich das nicht tue, dann beschäftige ich den Server von Google, obwohl ich die Links zu Google nicht mehr zeige. Das könnte eine Copyright-Verletzung sein.

[Klaus]

So ganz geblickt habe ich es jetzt immer noch nicht was Du meinst aber es ist ja auch schon Freitag! :-)

Ich denke Du sprichst auf meine vorher mal als Idee gebrachte "Font Proxy" Lösung an ... ja das wäre vermutlich nicht so 100pro "sauber" ... aber ich hatte ja auch geschrieben warum ich das eh nicht verwenden würde.

[vloppy]

Eine ziemlich dumme Frage - lassen wir die Sch.... Google Fonts mal aussen vor und kommen dann einfach zu den auf fast jedem PC, Laptop, Tablet, Handy vorhandenen Schriften. Da waren früher so Schriften wie Arial pp. alle vorhanden und wurden ohne Palaver angezeigt. Wie kann ich die denn wieder einfach nehmen um den ganzen Sch..... zu entgehen.
P.S. der Oberabmahner wurde gerade selber abgemahnt, das zu unterbinden!

[Klaus]

Falls ich das richtig sehe ist das von MR nicht per Default vorgesehen, entweder google oder eine die Du von lokal auswählst und bei alten Vorlagen MR0-MR3 sind immer 3 google Schriften (Links) drinnen die Du ohne "Handarbeit" nicht los wirsd.

[Klaus]

... ansonsten falls das der "Cookies Alert" von MR 5.6.15 so rechtlich überhaupt ok sein sollte, das auch für die IP gilt und das dann auch noch sauber funktionieren sollte -> "Consent Required".

Ich hatte das gerade mal mit einer einfachen alten Site in MR 5.6.15 (Basis Vorlage MR3) ausprobiert und da wird teilwise bei den href ein data-href und bei den src ein data-src verwendet und das dann erst nach dem Bestätigen "freigeschaltet" (per JS getausch).
Schön is anders aber wers mag ... wäre ggf. auch ne Lösung für das "Kartenproblem".

Ich finde es gibt jetzt viele mögliche Lösungen, muss jeder selber entscheiden was rechtlich ok ist und was er verwenden will/kann.