Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenWas genau meinst Du mit "falscher Seite"?
Google wählt die für die Anfrage am besten passende Seite aus, auf der sie das Bild gefunden haben.
Falls Du nicht willst, das bestimmte Seiten als Zielseite in der Bildersuche auftauchen, kannst Du das im HTML-Header der Seite mit einem entsprechenden Meta-Tag "noimageindex" festlegen:
https://support.google.com/webmasters/answer/79812?hl=de
Gruß
Ingo
Ich kann bei Deinem Beispielcode nichts finden, wo ein Cookie gesetzt wird.
Generell sollte es genau so funktionieren, wie hier beschrieben:
http://forum.wpde.org/konfiguration/…html#post596567
Der Teil in der .htaccess ändert ja überhaupt nichts am Cookie oder am Anmelde-Status.
Der define-Teil ändert nur den Cookie-Namen. Möglicherweise kommen die Plugins damit nicht zurecht.
Gruß
Ingo
Google will nicht wirklich Suchergebnisse in den Suchergebnissen habe.
Ich würd das mit Tags (Schlagworten) lösen. Vergib in jedem Artikel mit Vitamin C als Tag "Vitamin C" und dann kannst Du /tag/vitamin-c/ verlinken.
Gruß
Ingo
Wenn man Seiten in der robots.txt mit disallow ausschließt, hält sich der Google-Bot daran und wird die Seite nicht crawlen.
Deshalb ist es dann auch egal, ob da noindex oder nofollow im Header steht, denn der Bot kann diese Information gar nicht lesen.
Angaben in der robots.txt und im Header schließen sich in gewisser Weise aus.
Die robots.txt steuert den Crawler, die Angaben im Header die Aufnahme in den Index.
Gruß
Ingo
...
http://ticktacki.de/?page_id=86?tab=1
...
Zwischen den GET-Parametern muß das &-Zeichen stehen und kein Fragezeichen, also so:
http://ticktacki.de/?page_id=86[B]&[/B]tab=1Gruß
Ingo
Ich würde 404-Fehler auf keinen Fall aus der Analyse ausschließen wollen.
...
Gut, aber dann sollte man die Daten auch richtig interpretieren bzw. filtern und so vom normalen Traffic trennen.
Sonst kommt es schnell zu Fehleinschätzungen wie beim TE.
Gruß
Ingo
... Fake-Traffic und Referrer-Spam.
...
Referrer-Spam ist es wohl nicht, denn die URL liegt ja auf der Seite selbst.
Das Problem dürfte eher sein, daß der Analytics-Code auch auf der Fehlerseite eingebunden ist und deshalb auch die 404-Fehler getrackt werden.
Gruß
Ingo
Wegen der ca. 30 erzeugten, leeren Dokumente würde ich eher auf ein Plugin/das Theme als Problemverursacher tippen.
Unabhängig davon, bei Strato reicht als Berichtigung 755 für Verzeichnisse aus, da PHP als FastCGI im Kontext des FTP-Benutzers läuft.
Du könntest testweise im Strato-Kundenmenu unter "Datenbanken und Webspace"->"PHP-Version einstellen" Version 7 einstellen. Damit erhöht sich schon mal das PHP-Memory-Limit von 128 auf 256 MB. Zudem wird auch die Gesamtperformance ertwas besser.
Gruß
Ingo
Der in der Google-Search-Console (ehemals Webmaster-Tools) sichtbare Rückgang der "Besucher" aus der Google Bildersuche ist wohl nur ein "Meßfehler":
https://goo.gl/g6GpQM
Also alles im grünen Bereich, würde ich sagen. :-)
Gruß
Ingo
...
da müsste schon eine Vserver her
Ein vServer zum selben Preis wie das Hosting-Paket dürfte eher noch langsamer sein.
Webhosting-Paket oder vServer sagt noch nichts über die Leistungsfähigkeit aus.
Gruß
Ingo
Das sollte die geeignete Funktion in WP sein:
https://developer.wordpress.org/reference/func…user_logged_in/
Gruß
Ingo
Also mit der .htaccess allein geht es nicht.
Du müßtest Wordpress per Plugin oder Code in der functions.php des Thems dazu bringen, die interne Weiterleitung für bestimmte Seiten nicht auszuführen.
Man kann sich in diese Redirect-Funktion per Filer-Hook einklinken und die Weiterleitung ggf. verhindern. Dafür sind aber ein paar Kenntnisse in PHP und Wordpress-Programmierung notwendig.
Gruß
Ingo
Wobei besonders die Kombination Strato und SSL eher eine Performance-Bremse ist: https://goo.gl/XClJK3
Andererseits ist das in letzter Zeit etwas besser beworden. Ganz so langsam, wie bei meinem Test ist es nicht mehr.
Gruß
Ingo
Es werden externe Bilder von live-yourlove.de mit http:// eingebunden. Das sind die Verursacher des Problems. War das mal die alte Domain?
Gruß
Ingo
...
Kann ich beides ausschließen. Die Sitemap habe ich kontrolliert und im Quellcode der Seiten kann ich keine der gecrawlten Links finden.
...
Die sind im Quellcode auf Seite 2 vorhanden:
Vielleicht ist ja die Elemente-Id "js-grid-mosaic-more" ein Hinweis auf den Verursacher (Plugin/Theme).
Gruß
Ingo
...
Aber dort werde ich auf http://www.domein.tdl/platzhalter weitergeleitet. Also http://www.domein.tdl/platzhalter erscheint auch in der Adressleiste des Browsers. Aber da soll ja http://www.domein.tdl/wunschurl bleiben.
Diese Weiterleitung erfolgt dann durch Wordpress. Wordpress leitet immer auf die richtige URL um, wenn eine Seite mit einer anderen davon abweichenden URL aufgerufen wird. Das ist so gewollt und soll DC verhindern.
Das gibt es übrigens schon seit WP 2.3:
https://codex.wordpress.org/Function_Refer…irect_canonical
Gruß
Ingo
Wahlweise im Browser abschalten, z.B. in Firefox..
Hilft aber leider nur, wenn man die Seite selbst aufruft.
Durch allen anderen Besuchern der Website wird die Statistik trotzdem verfälscht. :-)
Gruß
Ingo
...
Das wäre zu wenig. Nur, sind es tatsächlich 90 MB? Dieser Wert wäre ungewöhnlich für das Memory Limit.
...
Das ist bei 1&1 eine gängige Größe und deutet auf ein älteres Webhosting-Paket hin.
Gruß
Ingo
Wenn ich das richtig sehe, dürfte der Grund das Link-Prefetching der Browser sein:
- https://en.wikipedia.org/wiki/Link_prefetching
- https://developer.mozilla.org/en-US/docs/Web…prefetching_FAQ
In deinem ersten Beispiel (/2016/12/steinsee-2/) steht die Zielseite als "link relation=next" in der referenzierenden Seite (2016/12/ascheimer-ismaninger-speichersee/) im Header. Deshalb hat der Browser sie schon mal im Hintergrund abgerufen, obwohl sie nicht "angeklickt" wurde.
Gruß
Ingo
Was irgendwelche Zähler zählen, ist nicht unbedingt schlüssig.
Das Server-Logfile hingegen ist weitestgehend unbestechlich. Wenn das etwas drin steht, gab es zumindest einen HTTP-Request für die geloggte Seite.
Ob der nun tatsächlich vom angezeigten Referer kam, sei mal dahingestellt.
Gib es denn im Server-Logfile auch die IP-Adresse des Requests?
Damit könnte man die Quelle möglicherweise eingrenzen.
Gruß
Ingo
