Beiträge von Synonym

  • Google und URLs als Klartext

    So, wieder zurück zu dem eigentlichen Thema, Links in Klartext im Content.

    Für mich habe ich nun den Beweis, dass Google normale URLs als Text im Content erkennt und auch verfolgt, was auch für die ganzen Meldungen in den WMT spricht (nicht die robots.txt-Geschichte).

    Habe vor zwei Tagen auf meiner Startseite einfach mitten in den Text folgendes geschrieben:
    https://beispiel.rocks/beispiel.rocks…de/urlauben.php
    Ebenso Datei angelegt und eine Benachrichtigung integriert, wenn einer (egal wer) darauf zugreift.

    Und, heute um 8:57 Uhr kam die SMS:

    Zitat

    UA: Mozilla/5.0 (compatible; Googlebot/2.1; +https://beispiel.rocks/beispiel.rocks…le.com/bot.html) IP: 66.249.66.231 END

  • Google und der 301

    Meine URL habe ich Dir ja geschickt, kannste gerne vergleichen - da ist nämlich nix zum Vergleichen ;) Habe bei mir nur noch bemerkt, dass zwei Tage danach die Seite von um die P12-P16 auf P30 gefallen ist.

    Und nein, generell ist das nicht so, das stimmt. Habe auch noch viele, bei denen alles "normal" ist - auf der gleichen Domain.

  • Jemand Erfahrung mit Strato? Hab Problem - Technisch

    War gerade essen :) Hast auch PM, ansonsten hier noch mal grob, damit auch was da steht :)

    Wenn das ein Paket mit mehreren Domänen ist, dann liegt die jetzige im Root / . Im Kundenbereich angegeben als "Umleitung: (Intern) /". Wird zu diesem Paket eine weitere Domain hinzugefügt, dann liegt die als Standard auch erst mal in /. Also beide greifen auf die gleichen Daten zu. Hier musst Du quasi per FTP erst einmal einen neuen Unterordner anlegen z.b. "domainname". Dann im Kundenbereich das interne Weiterleitungsziel auf diesen Ordner ändern.

    Allerdings sollten dann schon Inhalte beim FTP vorhanden sein, wenn es eine zusätzliche Domain ist, denn die vorherige ist ja schon da. Wenn der FTP komplett leer ist, dann wurden bei der alten Domain entweder noch keine Daten hochgeladen oder es ist ein ganz neues Paket. Das siehst Du aber im Kundenbereich bei "Domains" ob Du nur eine oder mehrere sind. Wenn mehrere, dann auch, ob das Ziel schon geändert wurde. Eventuell liegt ja auch bereits die vorhandene in einem Unterordner und ist "seltsam" benannt worden. Angaben sind da ja frei zu wählen, sinnvoll wäre aber schon der Domänenname.

    Selbiges auch mit Subdomänen. Auch hier erst den Ordner anlegen, dann im Kundenbereich das Ziel ändern.

  • Feiern Spammer keine Weihnachten??

    Der von vmge, daher fragte ich ja, ob die dazu gehören.

    Rausbekommen... Na ich habe einfach mal bei Google nach balt .net und phpmyadmin gesucht. Da kommt gleich am Anfang die vmge mit. Draufgeklickt, Virescanner meldet sich. Virustotal drüber laufen lassen, Virescanner melden sich fast alle. Kopie aus dem archive.org genommen, Virenscanner meldet sich auch :) Letzteres finde ich vor allen den Hammer.... So kann man die Viren natürlich auch "sichern".

    Sind aber alte Dinger, die per JS kommen und die Scanner kennen die schon...

  • Google und URLs als Klartext

    catcat
    Ist ja auch richtig, ich beachte den Bereich auch nicht sonderlich, aber ab und zu schon. Eben diese "Backlink" die keine echten sind, Google aber dennoch abruft, die stehen nur da. Auch hab ich da nun schon einige echte und gute Backlinks gefunden auf Seiten, die es bei mir gar nicht gibt (vielleicht mal 2005 oder so). Die zeigte mir kein Backlinkchecker an, die WMT schon, eben im Bereich 404-Fehler.

  • Google und URLs als Klartext

    Chris
    Ja, Post und Get selbst füllen... Aber über Seiten, auf die gar nicht zugegriffen werden darf?

    Wenn Google mir sagt, dass er die .js nicht aufrufen kann, da per robots.txt gesperrt, dann ist das logisch und verständlich, die steht ja auch im Quelltext. Wenn der mir aber dann sagt, dass die .php nicht darf, dann nicht mehr, denn die ist nur in der .js als AjaxRequest enthalten. Selbiges die "weiterführenden" Links der Monate, diese sind nur in der .php, die ja ihrerseits in der .js ist.

    Es muss auf der eigentlichen Seite also ein "onclick" durchgeführt werden, das dann eine JS-Funktion startet. Diese JS-Funktion lädt dann die Daten der .php (ajax) und bindet sie in die Seite ein.

    Deep-Crawling ist ja schön und gut, aber man muss dem doch sagen können: "Eh lass die Finger von der Seite und von den dort enthaltenen verlinkten Seiten und deren Links."

    Zumal das ja alles keine vollwertigen Seiten sind, sondern eben nur Rohdaten, die per JS in die Seite dann integriert werden (ein Div mit 2 Monatskalendern). Der Aufruf der .php direkt führt zudem zu Fehlern, da das benötigte Javascript ja gar nicht geladen wurde und die Funktionen für den Kalender und die Navigation gar nicht verfügbar sind.

    Der Output von der kalender.php (auf die er nicht zugreifen darf!) schaut so aus:


    Nur hier, im oberen Bereich, gibt es die Navi der Monate als onclick="kalender('dv','2012','2','ddmmyyyy');return false;" . Um weiter zu kommen muss man also dieses onclick auch ausführen. Was dann aber auch nichts bringt, da die Funktion kalender() gar nicht geladen ist.

    Wenn der Wertenereich von 24 Monaten überschritten ist, dann ist die Navi gar nicht mehr da. Also ein onclick="kalender('dv','2016','2','ddmmyyyy');return false;" gibt es nicht, schon gar kein 4200!

  • Google und URLs als Klartext

    Zitat von guppy;11198

    Und die Seiten sind verlinkt von? Also die WMT zeigen an, dass die Seiten von der eigenen Domain verlinkt sind und nicht von so einer Pseudosuchmaschine, die sich nicht an die robots.txt halten?


    Gute Frage.... "Verlinkt von": "Nicht verfügbar"

  • Google und URLs als Klartext

    Ja, das ist es wirklich. Wenn ich meine eigenen Beiträge da mal so lese, dann würde ich auch fast denken "der spinnt", "unglaubwürdig" oder sonst was... Leider ist dem aber nicht so.... Ich habe die Sperrung in der robots.txt nun mal entfernt und die Datei umbenannt. Nun gibts bei jedem Zugriff einen 404... Freue mich dann ja schon drauf, wenn das andere "Log" in den WMT voll läuft :(

    Das ist der entscheidente Teil vom kalender.js. Ausgelöst wird das "kalender_open" durch einen "onclick" auf der eigentlichen Webseite.

    So, bin dann mal gespannt, ob Google die neue URL nun wieder aufruft. So war es vorher auch, ist identisch, nur der Dateiname ist nun ein anderer.

    So, WMT-Test bringt auch das gleiche wie zuvor:

    Zitat

    URL
    /js/kalender-div-neu.js

    Googlebot
    Blockiert für Zeile 5: Disallow: /js/

    Googlebot-Mobile
    Blockiert für Zeile 5: Disallow: /js/

  • Google und URLs als Klartext

    mano_negra
    An sich sind mir diese "Robots.txt-Fehler" ja egal, denn verhindern lassen die sich nicht wirklich bzw. sind eben normal. Doch jetzt nimmt das wirklich überhand und es macht keinen Sinn. Vorwort: Es ist bei mir kein Formular. Es ist eine Seite mit einem Kalender. Darüber ist eine Mini-Navigation mit "Monat vor" und "Monat zurück". Das geht immer nur 24 Monate in beide Richtungen ab dem aktuellen Monat. Ab dann verschwindet die Navi und mögliche URL-Eingaben werden auch verweigert.

    So, nun habe ich in den WMT über 50.000 dieser Meldungen!

    Wie gesagt, das sind reine URLs, kein Formular um was einzutippen. Auch werden scheinbar gültige Werte verwendet. Jahr (y) von 1000 bis aktuell 4200. Monat (m) immer von 1-12. Id wird gar nicht verändert. Scheint also so, als ob die Navi unendlich weiterlaufen würde, tut sie aber nicht.

    Aber selbst wenn sie das täte, dann dürfte Google darauf gar nicht zugreifen, denn....

    Hauptfile, das auch im Quelltext steht:
    kalender.js -> das ist per robots.txt gesperrt.
    Die kalender.js für einen Request durch und holt die Daten von kalender.php. Auch diese ist in der robots.txt gesperrt.

    Also so:
    Webseite
    -> kalender.js
    --> kalender.php
    ---> Mini-Navi zu kalender.php?parameter

    Somit muss Google also erst einmal die "Sperranweisung" der .js missachten, um überhaupt an die .php zu kommen. Dort muss er die Sperranweisung dann auch missachten, um die ganzen .php?mit_parameter abzurufen... Das ist doch nicht normal und hat mit "beliebig Befüllen von Formularen" doch auch nichts mehr zu tun. Oder liege ich hier nun falsch?

    Missachten in dem Sinne, dass er es zwar in den WMT meldet, die URLs aber dennoch aufruft und diese zuvor auch selbst so erstellt, denn im System gibt es die nicht und gab es die nie.

    Den Kalender gibt es auch schon seit 5 Jahren, gab nie Probleme damit. Erst seit Weihnachten ist das so.

    Wie gesagt, ist mir eigentlich egal, ich wollte die anderen Fehlermeldungen durchsehen und prüfen (URLs als Klartext, wie es im Titel steht), doch so habe ich keine Chance da in den WMT überhaupt etwas zu sehen, nicht bei über 50.000 Meldungen.

  • Seiten gehakt

    Ja, schaut so aus, wenn das ein FTP-Log ist. Dennoch das Problem, dass da über FTP auch noch ganz andere Dinge gelaufen sind. Wenn man Files hochladen kann, dann kann man die auch ändern und herunterladen. z.B. Config-Files mit DB-Zugangsdaten. Dann, wurden die Daten direkt geändert oder heruntergeladen, bearbeitet und hochgeladen. Direkt geändert deutet ebenso auf ein zusätzliches Script hin. Und die letzte Problemfrage... Wie kamen die an die FTP-Daten?

  • Google und URLs als Klartext

    Zitat

    aber dass mit den links die keine links sind und 404 produzieren hab ich auch schon von anderen gehört.


    Ja, aber um das zu tun muss man die ja aufrufen. Also URLs in Klartext erfassen und ausführen. Ich würde noch nicht mal was sagen, wenn die Fehlerseite einer aufruft und Google dann wegen dem Adsense gleich hinterher kommt, aber auf einigen ist gar kein Adsense drauf, da der Aufruf der URL zu einem Server-Fehler (Bad Request) führt... Sind dann URLs wie die hier: *** Link veraltet ***

    Und das andere, das mit den robots.txt ist so was da:

    Code
    AjaxRequest('/js/kalender-div.php?id='+field_id+'&y='+year+'&m='+month+'&f='+format, function(data)


    Das wird innerhalb einer JS ausgeführt, die ist per robots.txt gesperrt. Die kalender-div.php ist auch gesperrt und Google schmeißt mir da nun über 28.000 Meldungen in die WMT von "year" 1 bis 3500 ... Das kann aber auch nicht sein, denn selbst wenn er die Seite aufrufen wurde, der Kalender geht nur 2 Jahre vor und zurück, ab dann geht nichts mehr.

  • Google und URLs als Klartext

    Also die Seiten sind garantiert nicht in den Google News, weder die Seiten, auf denen die "Links" stehen, noch die Zielseiten. Das sind normale Webseiten, bei den mal in den "Surftipps" eine URL steht. So Whois-Teile, mit Listen von Webadressen, Webkataloge etc... Sind aber auch ganz normale und saubere Seiten, die URLs zu Reiseinformationen angeben. Dort eine von mir, die es aber noch nie gab.. Weiß der Geier wo er die her hat... Google versucht die jedenfalls auch aufzurufen.

    P.S. Alle diese Meldungen sind extrem seit dem 24.12.

    Ich habe da aktuell ein ganz seltsames Gefühl, da passt derzeit zu vieles nicht. Einfach mal so an die 301-Geschichte gedacht, dann jetzt diese 404-Dinger und bei den "robots.txt-Fehlern" gehen mir auch die Alarmglocken an (über 28.000 Meldungen. Sonst waren das immer so um die 200). In den WMT sind heute auch wieder 2 Domänen als unbestätigt aufgetaucht, die vorher nicht da waren - gehören mir, sind aber nur Dummies und brauche ich in den WMT nicht.

  • Google und URLs als Klartext

    So, mir kommt so langsam die Vermutung, dass Google URLs in Textform (Klartext, kein a-href) auch ließt, auswertet und folgt...

    Warum ich das denke? Weil ich nun schon seit Tagen die Fehlerseiten in den WMT durchgehe und immer wieder über das gleiche Phänomen stoße.

    Google meldet Seiten als "404-Fehler" und dabei URLs, die so nie verlinkt waren. z.B steht bei einer Seite eine Liste von Webadressen, aber dort ist nichts verlinkt, sondern nur die URL als Text angegeben. Leider ist die gekürzt worden, da wohl zu lang. Google meldet genau diese URL.

    Solche Seiten gibt es viele...

    Ich habe in Javascript eine Var mit dem Inhalt "/addons/piwik/". Genau diese "URL" versucht Google ständig aufzurufen und meldet entsprechen einen 404.

    Kann das sein oder ist das Zufall?