Beiträge von Synonym

    Naja, die Verweildauer gehört auch zu SEO. Genau genommen müsste man erst mal definieren, was SEO überhaupt ist, denn letztendlich ist das auch was wie, welche Schriftfarbe nutzt man.

    Ich bezweifle aber, dass die Verweildauer einen sonderlich großen Einfluss hat, auch wenn das immer wieder behauptet wird. Das ist halt typisch SEO. Es wird immer gesagt, wiederholt, von anderen gesagt etc, aber keiner kann einen Beweis oder Beleg vorlegen.

    Ich bezweifle es aus schlicht technischen Gründen, denn wie soll Google die berechnen? Du hast den Tagmanager drauf, ok, der kann Zugriff und Absprung erkennen. Google behauptet aber, dass die Daten nicht fürs Raning benutzt werden. Andere haben Adsense drauf, auch da könnte man das erkennen, aber auch hier angeblich nicht benutzt,

    Was unumstritten ist ist, die Zugriffe über die Suche und die Rückkehr zu ihr. Nur das ist ja alles andere als zuverlässig. Was ist denn, wenn man aus den Suchergebnissen 3 Seiten öffnet, zeitgleich, im neuen Tab? Wie lange war man nun auf einer Seite? Für Google nicht messbar. Oder wenn man eine Seite öffnet, die grottenschlecht ist, aber man erst mal einen Kaffee tringt, bevor man auf den "zurück-Button" klickt?

    Oder, nimm als Beispiel eine Seite, die schlicht, einfach und sehr übersichtlich ist. Nach 20 Sekunden hast Du gefunden, was Du wissen willst. Dann nimm eine andere, bei der suchst Du 2 Minuten in den Untiefen, bist frustriert und hast dennoch nicht das gefunden, was Du wolltest. Welche ist nun besser? Die mit den 20 Sekunden oder die mit den 2 Minuten Verweildauer? Die Länge kann also nicht wirklich viel aussagen.

    Das Einzige, wie Google es recht zuverlässig messen kann ist Lighthouse, also über alle User, die Chrome benutzen, denn das sendet ja Daten an Google. Das sind eben dort in der Auswertung die "Feld-Daten". Das sind Daten, die nicht rein statistisch ausgewertet wurden, sondern individuell für jeden Besucher auf der Seite. Feld-Daten haben aber nur Seiten, die auch recht viele Besucher haben. Je weniger, desto ungenauer.

    Ich habe hier z.B. eine Domain, die hat eine durchschnittliche Verweildauer von 13 Sekunden. Das ist eine der besten Seiten, die ich habe, in Sinne vom Ranking. Eine andere hat eine Dauer von durchschnittlich 2 Minuten und ist im Ranking eher auf den Plätzen 50 bis 100.

    Meiner Meinung nach kann man die ganzen SEO-Tools in die Tonne kloppen. Die sind vielleicht brauchbar, wenn man seine eigene Domain vergleichen will, aber für fremde wird das kompliziert. Zahlen und Grafiken, schön, bunt, übersichtlich, aber was genau sagt das aus?

    Schönes Beispiel ja Deine beiden Bilder. Wenn man nach der Länge der Balken geht, müsste zweite Domain ja viel schlechter sein. Also stellt sich berechtigterweise die Frage, was da genau ausgewertet wird und ob das überhaupt eine Relevanz hat. Und wenn es eine hat, wie viel dann aus Sicht von Google. Ich meine, diese 100% bei den Tools kann auch nur ein Faktor mit 1% von den vielen bei Google sein.

    Wennste Dich mal in meinem Bereich (Unterkünfte / Reise) umschaust, dann wirst Du bemerken, dass die Big-Player ganz vorne, TFW, Booking, AirbnB und Co alle Seiten haben, die eigentlich gegen alles verstoßen, was Google so vorschreibt. In den Tools können die froh sein, wenn die auf 10 Punkte oder 10% kommen. Ladezeiten von teils über 10 Sekunden etc. Ist das wichtig? Wohl nicht wirklich, denn sie stehen ja allesamt in den Top10. Also wichtig wohl schon, aber nicht mit dem Gewicht, was diese Tools da suggerieren.

    Und Dein Mitbewerber.... Das steht ja nicht in der Grafik. Wie viele Links hat der denn? Von welchen Seiten? Wie viele Links haben die jeweiligen Seiten? Wie alt ist die Seite und die Linkseite? Was hat die für Content? Diese Tools zählen, wenn überhaupt, nur Wörter auf der Seite, aber ob das sinnvoll ist oder "Lorem ipsum" wissen die nicht.

    "Metaangaben" steht da in der Grafik. 100 und 80%, Was sollen das denn für Metaangaben sein, die da ausgewertet werden? Wichtig ist NUR ein unique Title pro Seite. Bei der Länge geht es schon los. Da gibt es Richtwerte, aber die sind bei Desktop und Mobil unterschiedlich und kommen nicht auf die Anzahl der Zeichen, sondern der Laufweite der Buchstaben an und welche Schrift verwendet wird, also auch die Laufweite beeinflusst, entscheidet Google. Also kann man die so gar nicht beziffern. Alle anderen Angaben in den Meta sind nutzlos. Ok, robots könnte noch was sein, wenn man da falsche Daten setzt.

    Server 0%. Wie schlecht muss ein Server denn sein, dass man 0% erreichen kann? Das bedeutet ja eigentlich "nicht erreichbar", offline, Stecker gezogen.

    Seitenqualität. Was genau ist das? Wer oder was entscheidet, ob eine Seite oder ein Buch gut oder schlecht ist? Kommt das nicht auf den Betrachter an, der drauf ist oder sich das Buch kauft?

    Als Tools, so einfach nutzbar, mit wenigsten ein paar handfesten Hinweisen, auf was sich deren Berechnung der Rangpunkte beziehen ist Lighthouse. Entweder hier https://pagespeed.web.dev/ oder eben im Chrome in der DEV-Console. Wobei es bei denen aber eher um Ladezeit, Usability, Technik geht. Aber auch hier wirst Du merken, dass meine oben erwähnten Reise-Mitbewerber auch grottenschlecht abschneiden, aber dennoch auf Platz 1 stehen.

    Ich kann dir dann ja mal den Bog ( oder was auch immer) mit teilen. Dann kann ich mich immer noch entscheiden. Danke.

    Wäre schön :) Das Problem bei "Seedingup" ist ja, dass man leider vorher nicht sieht, was da an Linkplatz angeboten wird. Das ist genau der Grund, warum ich da bisher nie was kaufte. Kaufe doch keine Katze im Sack. Und wenn die schreiben, Linkthema XY, dann bedeutet das ja nicht, dass die Domain sich mit dem Thema beschäftigt, das kann ja auch nur eine einzige Unterseite sein und alles andere ist eben was völlig anderes.

    Ansonsten ist Link kaufen oder verkaufen immer so ein Thema. Die Frage ist da erst mal, was möchte man erreichen. So was wie "die Leute springen nach Sekunden wieder ab" bemerkt Google gar nicht. Der Link bringt dann vielleicht was für SEO, aber nicht für Verkäufe. Man kann aber eben auch anders kaufen und verkaufen, eben für Besucher und nicht für SEO und schon ist das auch alles völlig legal.

    Du kannst deine Texte mit Copyscape testen, also das die wirklich unique sind. Dann gibt es auch keinen Ärger mit Abmahnungen und Anwalt.

    Mit solchen Aussagen wäre ich vorsichtig.

    Man kann einen Text durchaus so umschreiben lassen, dass den Copyscape nicht mehr erkennt. Da reicht es schon aus, ein paar Wörter immer wieder zu ersetzen, die Tönalität zu ändern, die Anrede und eben von z.B. aktiv auf passiv zu wechseln, oder umgedreht. Der Text ist dann aber immer noch inhaltlich identisch, nur anders geschrieben. Ob das dann "keine Probleme mit einem Anwalt gibt", darf bezweifelt werden. Wäre ansonsten ja einfach, ein Buch umschreiben zu lassen, das exakt die gleiche Handlung hat, aber anders geschrieben ist.

    Ich für meinen Fall lasse auch Text umschreiben, ganze Texte, aber nur meine eigenen. Mit fremden mache ich das anders. Da lasse ich mir erst eine Art "groben Inhalt der wichtigsten Daten" erstellen, das von mehreren Texten. Die werden dann kombiniert. Dann kommen noch eigene Daten dazu, was bisher nicht drinnen war oder eben Zeug, das ich nicht brauche, raus. Dann habe ich eine Art grobe Gliederung für einen Text, die im Grunde auf fremden Texten beruht und eigenen Änderungen. Aus der lasse ich dann einen neuen Text machen. Ich erstelle also nicht einen Text aus einem Text, sondern einen Text aus Stichpunkten. In dem Fall schreibt die KI dann viel freier im eigenen Stil oder eben mit "eigenem Wissen" und nicht auf Basis des Originals.

    Bedeutet also, das ist vorab "viel" Handarbeit zur Erstellung der groben Struktur und der Stichpunkte, auch wenn mit KI-Unterstützung. Der Schreibvorgang ist dann rein KI, dann letztendlich noch mal mehrfach lesen und manuell hier und da neu schreiben. Es soll aber auch Leute geben, die das einfach mit der API machen und fertig, was dann aber natürlich alles andere als "unique" wird. Unique im Sinne von Wort- und Buchstabenreihen sind anders, inhaltlich aber nicht.

    Naja, das kann täuschen oder kommt auf die Sichtweise an. Aber ja, fern ab von meinen eigenen Seiten und SEO finde ich auch, dass da, wenn man was spezielles sucht, nur noch Mist kommt. Und die Funktion "andere fragten auch", führt noch zu mehr Schwachsinn.

    Alleine so was wie "auf glasvlies tapezieren" oder eben "glasvlies übertapezieren". Sollte ja nicht so schwer sein. Was bringt Google??? Wie man Glasvlies tapeziert, also das Vlies selbst. Schon mal völliger Schwachsinn, denn das klebt man und tapeziert es nicht. Oder eben, wie man Vliestapete tapeziert. Auch super. Ich will aber, wie man AUF Glasvlies tapeziert.

    Und in anderen Bereichen genauso. Es kommt hier irgendwie nur noch Schmarrn oder eben Shopping.

    Ach ja, das Update ist seit dem 19.4. fertig. Hat alle Domänen von mir erwischt, bis auf eine. Die war die ganze Zeit stabil. Die hat es dafür danach erwischt, also zwischen dem 22. und 26.4.

    Hi, Danke Dir, auch wegen den Warnungen. Aber ich kann Dich beruhigen, SQL-Injections sind nicht möglich. Wie gesagt, das ist nur ein kleiner, relevanter Auszug. Die Daten sind alle mehrfach geprüft, werden vom Script selbst erzeugt und wenige Zeilen vor der jeweiligen Query überhaupt erst gesetzt. Mit dem Now und dem Cache hast Du recht. Mache ich normalerweise auch nicht so, sondern so wie Du. Ist hier aber egal, denn der Durchlauf ist eh nur einmal minütlich und da wäre es dann auch per PHP und direktem Date ohne Cache, da jede Minute eine neue Uhrzeit ;) Der Vorteil so, es lässt sich leichter Debuggen, wenn man sich die Querys ausgeben lässt, dann steht da nämlich schlicht das Mysql-NOW und nicht irgendein Zeitstempel.

    Datenbank, PHP, Webserver, alles, ist auf der gleichen Maschine. Da ist auch nur die eine Domain drauf.

    Deine Mysql-Query scheint nicht ganz zu stimmen bzw. ist zu "neu". %Z kennt mein MariaDB nicht. Er gibt daher keinen Zeitzonennamen aus, sondern einfach "Z". %Z gibt es erst ab Version 11.3, ich habe hier 10.11, vorher 10.8

    Aber ja, MariaDB ist korrekt, kennt den Offset von aktuell 2 Stunden.

    Na, das mit den Zeitzonen ist kein Problem, echt nicht. Das 13 und 14 Uhr war auch nur ein fiktiver Wert, der eigentlich so von allen genommen wird. Andere nehmen auch 10 und 14 Uhr oder so. Es geht da um An- und Abreisen. Im Grunde geht es hier nur um ein Datum, also z.B. "2024-04-04" und "2024-04-04"- Das hat halt eine Zeit dabei, damit klar wird, was davon die Abreise und was die Anreise ist. Abreise ist früher, Anreise später. Klar, es kann in ganz entfernten Ländern Probleme geben, das ist technisch möglich. Aber mit den Werten ist es so, dass 99,999999% aller Nutzer kein Problem haben, denn es wird sich durch die verschiedenen Zeitzonen kein Tag an sich ändern. Zielgruppe ist ja primär Europa bzw. eben was in den Zeitzonen -0500 bis +0500.

    Wegen den anderen Dingen, da wo Zeiten benutzt werden, die sind nur in DE bzw. eben alle an einem Ort.

    Code ist nun stark minimiert, aber nichts Besonderes.

    $update_interval = 3600-10;

    // -10 Sek, weil der Scriptdurchlauf ein paar Sekunden braucht und der Cron nur im Minutentakt läuft. Der Abstand ist also eine Stunde oder ein paar Sekunden weniger, aber niemals mehr. Würde sich sonst aufschaukeln und jede Stunde mehr werden. Scriptsurchlauf ist ca. 2-5 Sekunden.

    $sql = 'SELECT x FROM y AS blki WHERE blki.aktiv = 1 AND blki.next_import < now() LIMIT 25';

    // Next_import ist schon ein Wert in der DB, der als +1 Stunde gespeichert wird. Daher einfach der Vergleich, ob der gespeicherte Wert kleiner als der aktuelle Wert ist. Wenn ja, dann ist der Eintrag älter als eine Stunde.

    Dann erfolgt die Verarbeitung der Daten, die von extern kamen. Haben aber mit den eigentlichen Zeiten nichts zu tun. Da kommt nur das mit An- und Abreise zu tragen bzw. werden die Daten aufbereitet.

    $next_import = date('Y-m-d H:i:s', time()+$update_interval);

    $sql = 'UPDATE y SET last_import = \''.$date_last_import.'\', error_count = 0';
    if($date_last_modified !== false) $sql .= ', last_modified = \''.$date_last_modified.'\'';
    $sql .= ', next_import = \''.$next_import.'\' WHERE uk_id = '.$import['uk_id'];

    So, und da ist dann eigentlich auch das Problem. Nicht immer, aber manchmal. Genau suchen konnte ich noch nicht.

    Wenn ich also einen Datensatz manuell in der DB eintrage, dann ist "next_import" z.B. aktuell "08:14:22", eben "jetzt" + eine Stunde Intervall. Das sollte dann ja die erste Query erfassen und abfragen. In einer Stunde ab jetzt würde der dann fällig und müsste selektiert werden. Ist aber eben nicht der Fall. Selektiert wird er quasi erst in 3 Stunden. Also die reguläre +1 Stunde und eben die +2 Stunden Sommerzeit.

    Beim Update dann wird es wieder seltsam, denn dann geht das GMT / UTC-Spiel wohl umgedreht. Sprich. Wenn der dann endlich mal selectiert hat und dann am Ende das "next_import als neuen Wert in die DB schreibt (updatet), dann ist das keine GMT-Zeit mehr, sondern UTC. Der schreibt dann also kein "10:14:22" rein, was eben dann rechnerisch sein müsste, sondern dann UTC "08:14:22". Also jede Zeit dann entsprechend abzüglich Winter- oder Sommerzeit, rein UTC eben. Und beim nächsten Durchlauf wird dann sofort selectiert, weil "next_update" nicht mehr eine Stunde in der Zukunft ist. Steht dann ja "08:14" in der DB, obwohl in echt schon "10:14" ist.

    Also völlig wirr. Erst wird der Zeit +2 Stunden Sommerzeit hinzugerechnet, beim ersten Durchlauf und dann bei jedem weiteren wird jeweils +2 Stunden abgezogen und in die DB geschrieben. Was dazu führt, dass eben der erste Import viel zu spät kommt und dann bei den folgenden keine Pause von einer Stunde. Sondern die gleichen immer wieder jede Minute kommen. Was sinnlos ist, denn es sind ja immer die selben, limitiert mit dem "Limit 25" in der Query. Eigentlich ist die Zeitsperre ja da, damit der an die 900 Importe pro Stunde fährt und dann eben, eine Stunde später, wieder alle durcharbeitet. Jeder Import soll einmal pro Stunde laufen.

    Das funktioniert auch alles seit 15 Jahren. Nur eben nicht mehr richtig, seit dem Notumstieg auf einen neuen Server mit PHP 8.2

    Das habe ich nun in der Ini gesetzt. Also PHP weiß das eigentlich schon.

    Wenn ich mir die phpinfo nun ansehe, dann schaut die quasi so aus wie die von php 7.4, nur eben, dass ich nun bei Timezone einen Wert habe. Vorher und default ist ja "leer", also vorher "OS".

    Ein "date_default_timezone_get()" liefert auch den korrekten Wert.

    Das mit den Nutzern weltweit habe ich auch, aber ich mache es dennoch ohne Zeitzonen, denn es gibt in den wichtigen Bereichen nur zwei Zeiten. 13 und 14 Uhr. Da ist das quasi egal, wer in welcher Zeitzone ist. In den Berechnungen geht das in dem Fall auch nicht ein. Dieses 13 und 14 Uhr markiert quasi nur Ende und Start an einem Tag.

    Bei PHP heißt es nur sinngemäß, dass man date / time als Funktion nicht mehr nutzen sollte oder die gm-Funktionen, sondern stattdessen die Date-Klasse nehmen soll und dort dann mit "DateTimeImmutable".

    Der Rest, also Cache und so oder eben Interval-Abruf, der braucht nur einen bestimmten zeitlichen Abstand. Zeitzonen sind da auch egal. Also z.B. +1 Stunde eben, egal welche Zone. Das Problem ist ja da irgendwie, dass das Datum in der DB, also das, wie es in Deutsch sein sollte, nicht wirklich das ist, was ich errechne mit time() oder mktime() + 3600 oder date +1 Day. Wie gesagt, ich raffe es noch nicht ganz, es geht an vielen Stellen, aber an einigen nicht.

    Lass mich ausholen.

    Mein Server nutzt GMT, das ist korrekt. Er nutzt aber auch die Sommerzeit, also automatische Zeitumstellung.

    Der Server ist also genauso wie jeder andere Server mit PHP 7.4 auch.

    Nun mit PHP8 ist es aber so, dass der Wert "default timezone" eben leer ist. Gut, war er vorher auch, aber da hatte PHP dann ja automatisch den Wert vom OS genommen. Also entweder globale ini, oder user.ini oder eben OS. Letzteres ist nun nicht mehr der Fall. PHP nimmt als default, denn leer ist auch default, immer UTC.

    In den meisten Fällen speichere ich die Daten einfach als Uhrzeit oder eben als Datetime in der DB, also als "07:47:56" oder eben als "2024-04-03 07:47:56". Also auch so wie immer. Zeitzonen werden nicht gespeichert, da für das Vorhaben nicht relevant.

    Speichere ich hier z.B. bei PHPMyadmin einen neuen Datensatz, der now() als default hat auf einer Zelle oder eben "on Update", dann ist das die aktuelle Zeit, also "07:47:56". Steht so auch in der DB. Rufe ich das ab und gebe es mit PHP aus (date()-Funktionen), das steht das auch korrekt auf der Seite.

    An manchen Stellen passiert es aber, da wurde ich noch nicht ganz schlau draus, dass PHP dann mit dem Datum rechnen muss und der Meinung ist, dieses 07:47:56 wäre UTC. In der Berechnung meint PHP dann also, das wäre 09:47:56.

    Und da gibt es dann eben ganz simple Funktionen wie "wenn kleiner als "now()", dann mache X, ansonsten überspringe". Nachdem das aber eben in der Berechnung dann "09:47" ist, läuft er ins "überspringe".

    Selbiges Verhalten auch mit File-Opreationen. Habe da einen normalen Cache, der auf Create-Time beruht. Älter als 90 Minuten, soll neu erstellt, ansonsten eben das Temp-File genommen werden. Auch da hackt es, denn irgendwie sind die Files alle "outdated", obwohl gerade erst neu angelegt.

    Und, PHP8 war auch nicht ganz richtig. Wenn ich das richtig gelesen habe, gibt ja noch andere mit dem Problem, dann ist das wohl seit PHP 8.2 so.

    Stelle ich den Server auf UTC um, dann arbeitet alles ganz normal. Das ist aber doof. Ich hätte gerne deutsche Zeiten in den Logs stehen etc und vor allem importiere ich auch viele Daten, die Zeiten enthalten und da steht auch keine Zeitzone dabei. Default ist da aber überall "Berlin".

    Sei still! Das sag nicht nur ich, sondern auch die Nationale Stillkommission in Karlsruhe.

    Mir gefällt das, denn ich habe seit der Serverumstellung und PHP 8 ein gewaltiges Zeitenproblem. Irgendwie macht die Datenbank Zulu, PHP eine Mischung aus Zulu und Zeitzone und PHPMA besteht auf "Sommerzeit". Super. Alles, was irgendwie regelmäßig stündlich stattfinden soll, geht nun nicht mehr, da die Zeiten nun 2 Stunden auseinander liegen.

    Ich trage also einen neuen Datensatz in die DB ein, der erhält dann automatisch durch datetime() z.B. 08:03 als Zeitstempel. Das ist aber 08:03 Sommerzeit. PHP ruft dann ab und prüft, ob älter als eine Stunde. Jo, für PHP ist das 08:03 aber Zulu, also intern ist es da dann 10:03. Und nein, jetzt in Bezug auf die Zeit ist dann eben nicht eine Stunde. Sprich, das Script, das eigentlich um 09:03 wieder laufen müsste, läuft nicht, weil intern ist es ja 10:03. Verflucht noch mal. Hab da nun schon einiges geändert und angepasst, aber es will einfach nicht richtig.

    Und ich frage mich wirklich, warum so eine Änderung an PHP 8 nicht im Changelog als Breaking-Changes hinterlegt ist.

    Die "Default timezone" war in PHP immer die vom OS. Nun ist das nicht mehr so und default "UTC". Sämtliche date()- und time()-Funktionen liefern falsche Werte. Dann hab ich das schon manuell geändert auf "Default timezone = Europe/Berlin", was aber irgendwie auch nicht wirklich funktioniert, wie ich heute merken musste :(

    Seltsam finde ich, dass es zwei Personen betrifft. Ansonsten hätte ich es auf Deinen Rechner oder die Webseite geschoben.

    Selbst hatte ich so was aber auch schon, sogar mehrfach. Da ist der Firefox auch direkt eingefroren. Also erst die Meldung "Tab reagiert nicht... warten oder abbrechen" und dann komplett eingefroren, alle Tabs.

    Da lag es an der Webseite.

    Und bei einigen anderen, wo auch plötzlich einfrieren, aber alle Browser, lag es an Adsense.

    Ich kann Dir da uneingeschränkt zustimmen. Bei Wix stört mich vor allem der Name, aber das ist wohl so ein "deutsches" Ding. Ich habe viele Nutzer, die bei Wix oder Jimdo sind. Einige Seiten sehen aus wie aus den 90er Jahren, die anderen sind top-modern, wo selbst Wordpress und Co neidisch werden dürfte. Ich weiß bei den Leuten allerdings nicht, wie die an so ein Layout kommen, denn so altbackenes Zeug bieten die beiden Baukästen gar nicht an. Das muss man schon selbst so umbauen, dass es so wird.

    Da ich eben auch viele Nutzer habe, die eine Webseite wollen oder eine haben, dann aber eher bei Beepworld und Co, empfehle ich denen immer Jimdo oder Wix. Bei Wix weiß ich es nicht, aber Jimdo war früher immer sehr sehr billig und hatte mit Abstand die beste Ausstattung. Da konnte keiner mithalten, kein T-Online, kein 1und1, kein Strato, kein anderer eben. Jimdo lag bei 60 Eur inkl. eigener Domain für 2 Jahre, also 30 Eur pro Jahr. IN den letzten Jahren haben die aber deutlich aufgeschlagen und liegen nun bei so 12 Eur im Monat. Oder eben, ohne eigene Domain und nicht "Pro", die Free-Version. Das Wichtigste hatte die auch alles drinnen.

    Und ja, für kleine Seiten oder wirklich Anfänger sind beide wesentlich einfacher als z.B. ein Wordpress.

    Hab vor drei Tagen erst eine Jimdo-Seite von einem Kunden in die Kündigung gebracht, wegen Aufgabe. Wenn man nicht wüsste, dass das eine Jimdo-Seite ist, würde man das nicht merken. Viel mehr könnte man mit WP da auch nicht machen, ohne alles manuell im Code zu machen.

    Es laufen mehrere Updates gleichzeitig. Das in Deinem Link ist das Spam-Update. Es läuft aber auch das Core-Update und noch weitere. Die sind nun zwar alle "integriert" im "Core", aber dennoch einzeln für sich. Laut Google soll es das größte Update ever sein und in den Suchergebnissen sollen ca. 40% der Spamseiten oder Seiten mit nicht hilfreichen Inhalten oder nicht einmaligen Inhalten entfernt werden.

    Mich erschreckt da mal wieder das "nicht einmalig", wenn ich daran denke, wie oft andere Inhalte kopieren und daraus was "eigenes" machen.

    Das Core-Update dauert ca. 4-5 Wochen, das reine Spam-Update ca. 2 Wochen.

    • Name: Google März 2024 Broad Core Update
    • Gestartet: 5. März 2024 um etwa 12 Uhr ET
    • Rollout: Es wird ca. einen Monat dauern, bis das Update vollständig ausgerollt ist - während des Rollouts werden zahlreiche Änderungen an zahlreichen Core-Systemen vorgenommen
    • Ziele: Es betrifft alle Arten von Inhalten
    • Strafe: Es handelt sich nicht um eine Bestrafung, sondern um die Förderung und Belohnung guter Webseiten
    • Global: Es handelt sich um ein globales Update, das alle Regionen in allen Sprachen betrifft.
    • Auswirkung: Laut Google wird es zu einer 40-prozentigen Reduzierung von minderwertigen, unoriginellen und wenig hilfreichen Inhalten in den Suchergebnissen führen.
    • Entdecken: Die Core-Updates wirken sich auf Google Discover und andere Funktionen aus, außerdem auf Feature Snippets und mehr.
    • Wiederherstellen: Wenn Sie davon betroffen sind, müssen Sie Ihre Inhalte überprüfen und sehen, ob Sie mit den Empfehlungen von Google zum Core-Update besser werden können.
    • Auffrischungen: Google wird diesen Algorithmus in regelmäßigen Abständen auffrischen, aber diese Aktualisierungen in Zukunft nicht mehr kommunizieren.


    https://developers.google.com/search/blog/20…e-spam-policies

    https://status.search.google.com/incidents/1jW2F89qC2NxJBWGiKxE

    Externer Inhalt twitter.com
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Ja keine Ahnung. Hier ging Fb. War da an die 3 Stunden alle 5 Minuten drinnen. Ging Problemlos. Vpn hingegen nicht, die hälfte der Server nicht erreichbar mit Warnung, dass protokolle getestet werden und das 1 bis 2 minuten dauern würde. Ging aber auch nach 10 min nicht und dann trennung. Hatte da an die 400 Server durch, brauchte immer eine neue Ip.

    Also ging, zwei drei wechsel gingen, dann 10 nicht, dann wieder ein paar, etliche wieder nicht etc.