Beiträge von Putzlowitsch

    ...
    Wenn ich den bots den Zugriff erlaube, dann würde es ja mit dem Eintrag des Pfads in der Sitemap (auch die ist in der robots.txt korrekt angegeben !) nicht mehr kollidieren, oder ?
    ...

    Na genau das willst Du doch erreichen, daß der Widerspruch "robots.txt verbietet" und "Verweis in der Sitemap" aufgelöst wird (damit sich Google nicht beschwert).

    Ein Weg zur Auflösung des Widerspruchs ist halt, daß Du den Bots den Zugriff auf /wp-includes erlaubst. Das muß man nicht explizit mit Allow machen, es reicht, wenn das Verbot entfernt wird. Implizit ist alles erlaubt, was nicht verboten ist.

    Der andere Weg wäre halt, den Grund zu finden, warum diese GIF-Datei überhaupt in der Sitemap erscheint. Normal ist das jedenfalls nicht. Wenn Du den Grund gefunden hast, kannst Du das dann hoffentlich abstellen. Dann kannst Du die Sperre in der robots.txt auch drin lassen.

    Ich würde Weg zwei vorziehen, weil er die eigentliche Ursache des Problems anpackt.

    Gruß
    Ingo

    ...
    Damit sollte das Verzeichnis wp-includes eigentlich ausgeschlossen sein. ...

    Das ist ja genau das Problem. Du verbietest allen Bots den Zugriff auf /wp-includes, hast aber in der Sitemap einen Eintrag, der genau dort hin zeigt (dieses GIF vom TinyMCE). Und das meckert Google halt an.

    Wenn Du eine Datei genau mit dem Inhalt erstellst, wird eben diese von den Bots gelesen. Das ändert aber nichts an den Anweisungen für die Bots.

    Um den Bots den Zugriff auf /wp-includes zu erlauben, könnte die Datei so aussehen:

    Code
    User-agent: *
    Disallow: /wp-includes/
    Sitemap: http://example.com/sitemap.xml


    Damit verbietest Du nur den Zugriff auf /wp-admin und hast den Verweis auf die Sitemap drin.

    Das große Rätsel ist aber immer noch, wie die GIF-Datei in die Sitemap gelangt. Da müßtest Du eigentlich ansetzen.

    Gruß
    Ingo

    zu 1.:
    Die robots.txt-Datei wird ggf. virtuell von Wordpress erzeugt, sofern es keine entsprechende Datei im Dateisystem gibt. Du kannst aber selbst eine robots.txt anlegen und in das Wurzelverzeichnis der Domain kopieren. Damit wird die von Wordpress außer Kraft gesetzt.

    Im einfachsten Fall sieht die so aus:

    Code
    User-agent: *
    Disallow:


    Damit erlaubst Du jedem Bot alles.

    zu 2.:
    Das Plugin kenne ich nicht. Ich habe nur vermutet, daß es da eine passende Option gibt. Anders gesagt, wenn ich so ein Plugin schreiben würde, tät ich wohl so eine Option vorsehen.

    Gruß
    Ingo

    Ich sehe im Wesentlichen zwei Optionen.

    1. Die Sperre für /wp-includes aus der robots.txt entfernen
    2. Im Sitemap-Plugin alle Dateien aus /wp-includes ausschließen, so daß sie nicht mehr in die Sitemap aufgenommen werden. Es sollte eine Option dafür geben.

    Gruß
    Ingo

    Es gibt Plugins, die den TinyMCE als Editor für Kommentare auf die Seite holen. Dann sind die Sachen (z.B. Symbole) natürlich auch für Google "sichtbar". Allwerdings gehört sowas tatsächlich nicht in die Sitemap, da wird wohl das Sitemap-Plugin über das Ziel hinausschießen (oder so).

    Gruß
    Ingo

    ...formateins merkte vorhin an: "[COLOR=#333333]Richtig ist es aber (für die Suchmaschinen), eine permanente Weiterleitung zu definieren (301)." Siehst du das anders? Ansonsten z.B. einfach das Plug-In [/COLOR]http://wordpress.org/plugins/redirection installieren?

    Das sehe ich genauso, wie formateins. Eine 301er Weiterleitung ist notwendig.

    Allerdings macht das Wordpress wie gesagt schon selbst. Ein Aufruf wie ?p=123 wird von WP immer automatisch per 301 auf die richtige, mit den Permalinkeinstellungen konfigurierte URL weitergeleitet. Dafür braucht man kein Plugin.
    Deshalb ist das Problem bei Dir, wie Du oben schriebst, auch nicht aufgetreten.

    Die erstmalige Umstellung von "Standard" auf Permalinks ist kein Problem. Komplizierter wird es allerdings, wenn man später dann die Permalinkstruktur ändert. Deshalb sollte man vorher gut überlegen, welche Permalinkstruktur die richtige ist.

    Gruß
    Ingo

    Mit der WP-Galerie ist es nicht möglich. Diese ist ja nichts weiter als die zusammengefaßte Darstellung der Bilder eines Artikels. Der Link müßte also bei jedem einzelnen Bild hinterlegt werden und dafür ist erstmal kein Datenfeld vorgesehen.

    Ohne Plugin wird das also nichts, obwohl es nicht unbedingt NextGen sein muß. Auf die Schnelle habe ich z.B. das hier gefunden:
    https://github.com/brewern/gallery-custom-link

    Gruß
    Ingo

    Wirklich vernünftig zu lösen ist das Problem nur, wenn der Webhoster, wo der Webspace mit dem installierten Wordpress liegt, das aufschalten externen Domains ermöglicht. Zudem muß der Webhoster, wo die gewünschte Domain liegt, das Bearbeiten der DNS-Konfiguration zulassen.

    Alles andere mit Frames oder versteckten Weiterleitungen ist nur eine Krücke.

    Gruß
    Ingo

    Also ich kann bei einer "nackten" WP-Installation problemlos gleichnamige Kategorien und Tags erstellen, die beide den selben Slug bekommen. Es ist sogar so, daß sich der Slug beim Ändern an einer Stelle (z.B. Kategorie) auch an der anderen Stelle (z.B. Tag) ändert. Es gibt eben nur einen Term, der mehreren Taxonomies zugeordnet ist. So ist zumidest das normale Verhalten von Wordpress.

    Vielleicht greift da irgendein Plugin ein und führt zu dem oben beschriebenen Effekt.

    Nachtrag: Das funktioniert so allerdings nur, wenn die Termnamen exakt gleich geschrieben sind. Also ist Kategorie "Test" etwas anderes als Tag "test". Nur wenn beide "Test" heißen, entsteht kein neuer Slug (kein neuer Term).

    Gruß
    Ingo

    Ich bin mir nicht ganz sicher, es könnte aber sein, daß Du erstmal noch kurz zu den Permalinkeinstellungen gehen mußt und diese einfach speichern, damit die Rules intern neu generiert werden.

    Mit den Plugins kenne ich mich nicht aus, aber die scheinen auch in die Rewrite-Rules einzugreifen. Könnte sein, daß die stören, kann ich aber nicht wirklich sagen.

    Gruß
    Ingo