Beiträge von Clemens-XS

    Hi!
    Habe den Fehler gefunden: Ich hatte noch das Routing-Plugin von Joomlager aktiviert gehabt. (Bitte nicht hauen!) - Nach Deaktivierung und Deinstallation läuft das Joomla-Routing nun BEINAHE einwandfrei.


    BEINAHE: Denn ich habe immer noch Ärger mit den URLs zu einigen wenigen Beiträgen, nämlich:
    diese URL:
    http://lebenslust-jetzt.de/?vi…ktiker-von-verbot-bedroht
    die eigentlich heißen sollte:
    http://lebenslust-jetzt.de/hei…ktiker-von-verbot-bedroht
    Einen Menüpunkt gibt es zur Kategorie "Heiße Themen", den hab ich aber unsichtbar gesetzt.


    Weil dieser Beitrag in kurzer Zeit extrem besucht worden ist, muss die URL dazu bestehen bleiben. Gewiss wurde ich bereits weiter verlinkt. Daher sah ich mich gezwungen, die gute bisherige URL per redirect 302 in der htaccess auf die jetzt von Joomla generierte URL umzuleiten, die ja beim Navigieren auf der Website so erscheint.
    Den Fehler möchte ich schnell beheben, damit nicht nun neue Besucher die falsch erzeugte URL bookmarken.


    Nicht per redirect behoben habe ich dagegen den URL-Fehler zu diesem weniger wichtigen Beitrag:
    http://lebenslust-jetzt.de/?vi…redeformen-dieser-website
    die richtige URL wäre:
    http://lebenslust-jetzt.de/anredeformen-dieser-website

    Gleiches gilt auch für diese URL:
    http://lebenslust-jetzt.de/com…:uncategorised&Itemid=162
    die richtige URL wäre:
    http://lebenslust-jetzt.de/psy…gische-beratung-qualitaet



    Wenn ich wüsste, wie ich Joomla dazu bringen kann, diese URL neu und richtig zu routen, könnte ich diesen Vorgang auch auf die zuvor beschriebene URL zur Korrektur anwenden.


    Was kann ich tun?

    Meine wichtigste Website habe ich gerade endlich auf 3.8.5 upgedatet. Grund für die Verzögerung war, dass ich bisher noch die URLs mittels ACE-SEF erzeugt hatte und vor dem Joomla-Update alle Metatags aus ACE-SEF in die passenden Joomla-Felder kopieren musste, um sie nicht zu verlieren.
    Nach dieser Aktion habe ich ACE-SEF deinstalliert und die Datenbank von den Resten von ACE-SEF befreit. Erst danach habe ich Joomla korrekt über den Onlie-Updater upgedatet.
    Ja und natürlich habe ich auf das "moderne" Routing geschaltet und die ID-Unterdrückung aktiviert. Hat aber nix genützt:


    Was bei drei anderen Websites auf Anhieb funktioniert hatte, nämlich dass die URLs noch stimmen, das führt hier zum Chaos. Und wenn dieses URL-Chaos noch einige Zeit so bestehen bleibt, werde ich Ranking-Verluste bei Google & Co bekommen und viele Besucher, die meine Seiten gebookmarkt hatten, werden verärgert sein!


    Natürlich habe ich bereits den Joomla Cache mehrfach geleert, den Server-Cache deaktiviert usw., was aber alles nichts gebracht hat!


    Daher brauche ich jetzt dringend hilfreiche Tipps, wie ich z.B. in Joomla den URL-Generierungs-Mechanismus neu anstoßen kann, in der Hoffnung, dass dann die URLs wieder suchmaschinen-freundlich gestaltet sind. Evtl. gibt es ja auch noch andere Möglichkeiten.
    Eine Möglichkeit, alle „schlechten URLs” in der htaccess durch Redirects von den bisherigen guten URLs verfügbar zu machen, dürfte bei rund 150 Seiten ausgeschlossen sein, zumal in der htaccess aus einer sehr frühen Version meiner Website bereits an die 80 Redirects enthalten sind.


    Was kann ich tun?
    Hier die betroffene Website: http://lebenslust-jetzt.de

    Hi!
    Zwei meiner Websites liefen bisher noch mit ACE-SEF, weil ich damit optimale URLs erstellen und zudem zentral alle Metatags (Descriptions) verwalten konnte. Seit Joomla 3.7 kann ACE-SEF die URLs neuer beiträge nicht mehr verwalten. Alle zur Bedienung von ACE-SEF nötigen Icons haben keine Beschriftung und keine Funktion mehr. Aber die Site und die bisher angelegten URLs funktionieren noch.
    Nach Anlegen eines neuen Beitrags war das Menü ohne Funktion und somit 99% der Website nicht mehr nutzbar!


    Nach intensiver Webrecherche fand ich von Hannes Papenberg unter www.joomlager.de ein Plugin, mit dem in einem Joomla 3.7 die neue Routing-Funktionalität von Joomla 3.8 installiert werden kann. Nachdem ich das PlugIn installiert und aktiviert hatte, waren alle Menüpunkte und die Links zu den beiträgen wieder voll funktionsfähig.


    Auf einer der beiden Websites habe ich dann versuchsweise ACE-SEF deinstalliert. Dabei stellte ich fest, dass die zu ACE-SEF zugehörigen Datenbankeinträge nicht gelöscht worden sind. Das holte ich dann manuell nach. Einige URLs änderten sich durch die Deinstallation von ACE-SEF, sodass ich Korrekturen durchführen musste.


    Als ich einen Beitrag öffnete, um die durch die Deinstallation von ACE-SEF verloren gegangenen Metadescription wieder einzufügen, stellte ich fest, dass nun gar keine Felder mehr für Metatags angezeigt wurden! Ich kann also keine Metatags mehr anlegen, was natürlich betr. SEO fatale Wirkung hat!


    Fragen also:
    Hat evtl. ACE-SEF eine PHP-Datei zur Anzeige der Metatag-Felder verändert oder unwirksam gemacht? Wenn ja, welche?
    Wie bekomme ich meine Metatag-Felder bei den Beiträgen zurück?

    Nachdem ich erneut einen Arbeitstag lang mich mit Schema.org beschäftigt hatte, habe ich mich dazu entschlossen, auf derartigen Code in meinen Websites zu verzichten. Dies, obwohl von Google und im neuesten Heft "Webdesign c't" das Einfügen solchen Codes als SEO-Maßnahme dringend empfohlen wird. Man kann mit solchem Code dazu beitragen, dass Google die Angaben in diesem Code als "Rich Snippet" in die Suchergebnisse einfügt.
    Dies ist natürlich verlockend. Aber wenn es mit so viel Aufwand / Einarbeitung verbunden ist, lasse ich einfach die Finger davon, weil es unwirtschaftlich wird!

    Das ist richtig: Aktuelle Browserversionen von Chrome, Firefox usw. beachten die HTTP-Header und verweigern z.B. das Nachladen von Code fremder Websites / Server. Sofern also der Browser des Users aktuell und sein System nicht gehackt ist, erhält der Besucher meiner Website eine zusätzliche Sicherheit.
    Im Rahmen von Sicherheitsinitiativen Dritter könnte meine Website Auszeichnungen betr. Sicherheit erhalten.


    Ich finde die Maßnahme mit den HTTP-Headern sinnvoll, da meine drei aktuellen Websites immer wieder massiven Hackerangriffen ausgesetzt sind. Im Sommer 2016 haben polnische Hacker zwei Sites hacken und mich als Admin aussperren können. Mir blieb nur die vollständige Löschung des kompletten Webspace und der neu-Aufbau meiner Sites. Dabei waren meine Sites stets aktuell gehalten!


    Dass die dritte Site nicht ebenfalls gehackt wurde, hat damit zu tun, dass ich jede Site vom Webspace der anderen durch Quotas trenne, das Admin-Backend nur per https zugänglich ist und Admin-Username sowie Passwort aus 20-stelligen Zeichenketten bestehen.


    Auch zurzeit finden in ca. monatlichen Abständen durchschnittlich vier Angriffe je Woche statt. Bisher haben mich BruteForceStop und _Marcos-SQLI-LFI-Protector geschützt.
    Angesichts dieses Szenarios ist der Einsatz der HTTP-Header gewiss eine gute Idee (zu Gunsten meiner Site-Besucher).


    PS: Haben andere Joomla-Sitebetreiber eigentlich ähnlich intensive Erfahrungen mit Hackern machen müssen?

    Hallo!
    Ich verwende in meiner HTACCESS vier HTTP-Header-Security Settings. Solange diese aktiv sind, kann ich manche Extensions nicht über das Backend updaten wie z.B. die Extensions von RegularLabs (früher NoNumber).
    Auch die Joomla-Update-Prüfung funktioniert nicht, weil offensichtlich keine Verbindung zum Update-Channel aufgebaut werden kann. Erst wenn ich im Backend den Menüpunkt "Joomla-Update prüfen anklicke, gelingt die Verbindung und Update-Prüfung. Das Update selbst kann aber nicht durchgeführt werden, weil nach der erfolgten Datensicherung mit Akeeba kein Download des neuen Joomla erfolgt.


    Ich muss also vor jedem Update-Vorgang per FTP in meine htaccess und die oberen drei Security-Settings deaktivieren (auskommentieren), dann die Updates durchführen und prüfen und anschließend die htaccess wieder zurück ändern.


    Hier die vier Settings:

    Code
    Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' http://meine.piwik-domain.de https://www.initiative-s.de"
    Header set X-Frame-Options "SAMEORIGIN"
    Header set X-XSS-Protection "1; mode=block"
    Header set X-Content-Type-Options "nosniff"


    Frage:
    Was muss ich ändern, damit die Updates ohne den oben beschriebenen Änderungsaufwand erfolgen können, die Security-Settings aber weiterhin wirksam bleiben?

    Hallo!
    Gemäß den Empfehlungen im neuen Heft c't Webdesign möchte ich die Metainformationen gemäß Schema.org im ld+json-Format einfügen.
    Aber wo in Joomla kann ich diese Infos einfügen?


    Die einzige Stelle, die mir dazu einfällt, ist die default.php des von mir verwendeten Templates.
    Ist das sinnvoll, dort diese Meta-Infos einzufügen oder gibt es noch eine bessere Möglichkeit?


    (uuuups, das sollte in eine andere Forenrubrik)

    Hallo Christiane!
    Habe gerade dies hier gefunden:
    https://www.joomlashack.com/blog/tutorials/new-urls/
    Mit dieser SEO-URL-Erzeugung bin ich voll einverstanden! Hätte es das schon früher gegeben, hätte ich nie eine SEO-Komponente eingesetzt.


    Ich werde also (bis September / Oktober 2017) auf Joomla 3.8 warten und vor dem JoomlaUpdate die SEO-Komponenten deinstallieren und die Datenbank säubern, dann auf Joomla 3.8 updaten und alle URLs mit den bisherigen vergleichen. Wo es Unterschiede gibt, werde ich in der htaccess 301-Umleitungen einfügen.


    Meine bisherigen Erfahrungen mit einer SEO-URL-Komponente waren sehr gut. Seit Joomla 1.5 hatte ich immer ACE-SEF eingesetzt. Die aktuellen beiden Websites hatte ich im Sommer 2015 einem kompletten Redesign in der Menüstruktur und den Kategorien unterzogen und Keywords optimiert - auch die URLs sind Keyword-optimiert. Das hat mir weitere oberste Plätze bei den entsprechenden Keywords eingebracht.
    Einziges Problem bei Joomla 3.8 wird für mich sein, dass ich mir die SEO-URLs von Joomla gemäß dem Alias der Beiträge vorgeben lassen muss. Bis jetzt konnte ich dank der SEO-URL-Komponente manche URLs unabhängig von dem Artikel-Alias neu definieren.


    Ich meld mich ggfs. wieder, wenn der Wechsel auf Joomla 3.8 ansteht. :)


    Danke für deine Meinung! Clemens

    Danke Christiane!
    Ich erfuhr gerade über das JoomSEF-Forum von einem User, dass JoomSEF ab Joomla 3.7 nicht mehr funktioniert! Das steht aber so nirgends auf deren Website und auch nicht bei JED.
    Offensichtlich ist bereits beim Wechsel auf Joomla 3.7.x das Routing geändert worden. Und wenn es, wie du sagst, bei Joomla ab 3.8 erneut verändert wird, dann ist für mich klar, dass ich zurzeit wohl eher keine Änderung vornehmen sollte und ACE-SEF ablösen sollte.


    Problematisch sehe ich aber, dass ACE-SEF vermutlich seit Juni 2016 nicht mehr gepflegt wurde und daher Sicherheitslücken haben kann. Ferner hängt die derzeitige Funktionalität von ACE-SEF ja wohl nur noch am seidenen Fädchen: Schon beim nächsten Joomla-Update kann es endgültig crashen. Und dann? Bei einer derart zentralen Komponente wie SEF-URL ist das alles kein Spaß mehr.
    Meine Kundengewinnung läuft zu 95% über die Website.


    Freundliche Grüße, Clemens

    Hallo!
    Auf zwei in laufenden Betrieb befindlichen (=Produktiv) Sites habe ich bisher ACE-SEF eingesetzt. Das funktionierte bisher prima. Auffällig war lediglich, dass es seit Juni 2016 keine Updates mehr gab. Und nach dem Joomla-Update auf 3.7.x wurden im Backend in den Buttons von ACE-SEF keine Symbole mehr angezeigt, wodurch die Komponente de facto nicht mehr bedienbar wurde. Als ich nun einen neuen Beitrag anlegte, erhielt der zwar automatisch eine (korrekte) neue URL. Diese wurde aber nicht mehr wie üblich im SEF-URL-Verzeichnis im Backend angezeigt. Zudem wurde der Beitrag einer falschen Menü-ID zugeordnet.


    Das reicht mir, um ACE-SEF nun endlich auszutauschen. Nach viel Recherche in den Joomla-Foren scheint mir Artio JoomSEF der passende Nachfolger zu sein.
    Ich möchte nicht auf die in Joomla integrierte SEO-URL-Lösung zurück gehen, denn die derzeit rund 150 URLs sind bei Google und meinen Interessenten gut eingeführt und finden sich auch in meiner Print-Werbung in QR-Codes. Zudem glaube ich daran, dass „sprechende URLs” sehr wohl mit in das Ranking eingehen.


    Fragen:
    Wie kann ich ACE-SEF rückstandsfrei de-installieren, damit JoomSEF problemlos läuft? Reicht es aus, nach der Deinstallation die Datenbank zu säubern? Oder kann ich parallel zu ACE-SEF das JoomSEF installieren (ohne Letzteres zu aktivieren), um dann manuell URLs und Meta-descriptions im Backend nach JoomSEF übertragen zu können?


    Wie schaffe ich es auf zuverlässige und möglichst wenig Arbeit verursachende Weise, die derzeitigen SEF-URLs und die mit ACE-SEF angelegten Meta-descriptions komplett nach Artio-JoomSEF zu übertragen?

    Hi!
    Ich habe hier drei Joomla-Installationen, die bisher auf dem aktuellsten Stand waren inkl. AkeebaBackup. Bei allen drei Installationen zeigen sich folgende Probleme:

    • Unabhängig davon, ob ich AkeebaBackup upgedated habe oder nicht, kann die jeweilige Site nicht mehr mit AkeebaBackup gesichert werden. Das angestoßene Backup startet den ersten Step und belibt danach endlos lange hängen. Ich muss es abbrechen. In den Logs von AkeebaBackup sehe ich keine Fehlermedungen.
    • Ich habe versucht, das auf meinen PC herunter geladene Joomla-Update 3.7 (ZIP-Paket) über das Backend zu installieren. Egal ob mit oder ohne upgedatetes AkeebaBackup funktioniert das Update nicht. Konkret lässt sich das Update starten. Danach ist für mindestens 5 bis 8 Minuten nur der Joomla-Wartekreisel zu sehen. Danach erscheint das Backend mit der Meldung, das Update sei erfolgreich installiert worden.
      Aber am unteren Rand des Backend sehe ich nach wie vor Joomla 3.65 angezeigt. (Und ja, ich habe den Cache von Joomla und auch den des Browsers geleert!)

    Die letzte bedeutende Änderung an meinen drei Sites war die Ergänzung der htaccess um die Tags "Content-Security-Police" und "X-Frame-Options" und "X-SS-Protection" und "X-Content-Type-Options" wie folgt:
    Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' http://piwik.meinedomain.de https://www.initiative-s.de"
    Header set X-Frame-Options "SAMEORIGIN"
    Header set X-XSS-Protection "1; mode=block"
    Header set X-Content-Type-Options "nosniff"


    Keine Frage mehr:
    Das Problem war tatsächlich die htaccess mit den obigen Einträgen. Ich muss dazu sagen, dass mein Backend nur per https-Verbindung ansteuerbar ist (ebenfalls via htaccess so eingestellt). Evtl. müsste ich für den https-Zugang ebenfalls noch eine Ausnahme in die conten-Security-Policy einfügen.
    Jedenfalls lief jetzt Akeeba und das Joomla-Update prima durch und die Site funktioniert wieder, wie sie sollte.

    Die Einstellungen im PlugIn aber auch im Editor habe ich mehrfach bereits geprüft. Keine Unstimmigkeiten!
    Dass die Mediabox ein separates PlugIn ist und direkt mit dem JCE-Editor nix zu tun hat, ist mir schon klar. Aber erstaunlich ist doch, dass der Fehler mit der Mediabox auf Mobilgeräten erst jetzt nach diesem Update auftrat und seit August an meiner Website außer den üblichen Updates nichts geändert worden ist.


    Die gesamte Website hatte ich erst Ende August 2016 neu fertig gestellt und natürlich alle Funktionen incl. JCE-Mediabox sorgfältig geprüft, auch auf Mobilgeräten und diversen Mobilbrowsern. Da war alles OK und sah sehr ähnlich aus, wie auf dem Desktop. Sogar im Sinne des Flexible Response passte sich die Größe des PopUp an den Viewport an, wenn der kleiner war, als die Voreinstellungen.


    Es mag aber sein, dass du inzwischen eine viel bessere Alternative für die Mediabox gefunden hast. Ich bitte dich, mir diese Alternative zu nennen. Dann könnte ich ja damit das Problem lösen.

    Hi
    Das ist nicht nur ein Schönheitsfehler! Da stecken noch mehr Bugs dahinter!
    Ich habe ebenfalls das Problem mit einer winzigen Schriftgröße im Editor-Fenster. Zusätzlich habe ich aber auch gewaltige Probleme mit der JCE-Mediabox, mit der ich sowohl per Ajax andere Beiträge meiner Website aber auch per HTML5-Video-Tag oder iFrame Videos einbinde.


    Nach wie vor funktioniert das auf Desktop-Browsern einwandfrei. Aber auf Mobilbrowsern fehlt grundsätzlich neuerdings die Scroll-Leiste in den PopUps der Mediabox, getestet mit Chrome und einem alten Android-Browser auf Android. iPhone konnte ich noch nicht testen.


    Es kommt aber noch schlimmer: Firefox auf Android blockiert jegliche weitere Navigation auf der Website, sobald man einen Link zu einem Popup angeklickt hat. Der Besucher kann dann nur noch mit dem Smartphone-Return-Button (so vorhanden) oder mit dem Schließen des kompletten Browser reagieren.
    Meine Website hat zurzeit über 50% Mobil-Traffic. Es ist ein deutlicher Einbruch in der Statistik zu sehen, seit ich dieses verdammte Update 2.6.0 und dann 2.6.1 installiert habe.


    Dass der Ärger tatsächlich und nachweisbar auf JCE zurück zu führen ist, sehe ich daran, dass zwei andere, sehr ähnlich aufgebaute Websites mit gleichen Extensions aber ohne JCE-Update diese Probleme nicht haben!


    Welche Möglichkeit habe ich, auf eine alte JCE-Version downzugraden? Alet Versionen vor 2.6.0 bietet Ryan nicht auf seiner Site an und ich habe nur noch eine viel ältere Version hier herum liegen. Fragt sich dann auch, wie ich die installiert bekomme. Vermutlich müsste ich JCE vorher deinstallieren.


    FRUST!!! - Und Verlust an Besuchern und potenziellen Kunden!!!

    Hallo!
    Ich habe in meinem Joomla 3.6.x im Pfad "http://meine-site.de/images/video/kunterbunt/" mehrere Videos (mp4) liegen. Einige davon sind zurzeit noch nicht auf der Joomla-Website in Artikel eingebunden und können somit nicht über Joomla ausgeliefert werden.
    Nun habe ich einem Kollegen per eMail einen Link zu einem dieser Videos gesendet, damit wir uns in einem Telefonat darüber fachlich austauschen können. Er sagt, das Video lässt sich nicht aufrufen. Ich prüfe nach. Er hat Recht - Firefox meldet: Seitenladefehler: "Server nicht gefunden"


    Meine Website ist über NON-www-URLs erreichbar und dies ist per htaccess auch so eingestellt. Der Link, den ich dem Kollegen zugesandt habe, hatte eine NON-www-URL, Pfad und Datei waren definitiv korrekt geschrieben.


    Versuchsweise habe ich in einem der vielen Artikel der Joomla-Website einen unauffälligen Link zu diesem Video eingebaut. Kaum war dieser Artikel gespeichert / veröffentlicht, konnte ich das Video sowohl über den Link im Artikel aufrufen als auch über den Link, den ich dem Kollegen per eMail gesendet hatte.
    Damit Google das Video nicht crawlt / indiziert, habe ich natürlich den Link schnellstmöglich wieder aus dem Artikel entfernt. Und prompt war es auch nicht mehr möglich, das Video über den direkten Link abzurufen, den ich meinem Kollegen gesendet hatte.


    Aber jetzt kommt der Oberhammer! – Ein weiteres Video, das definitiv in keinem Joomla-Artikel verlinkt ist, lässt sich über solche Links problemlos aufrufen!


    Welche Ursache hat dieses Phänomen? Hat es evtl. mit dem Caching zu tun? Oder mit htaccess-Regeln?


    Folgende Einträge in meiner htaccess könnten etwas mit dem o.g. Effekt zu tun haben:


    Allerdings: Wenn eine der Regeln den zuerst beschriebenen Effekt auslöst, wieso ist dann ein anderes Video (gleiches Dateiformat = mp4) im gleichen Ordner abrufbar?


    Die gleiche Problematik habe ich auch mit anderen Dateiformaten wie z.B. PDF-Dokumente, GIF, PNG, mp3, usw.


    Was tun?

    Hallo!
    Das Ganze hat sich nun aufgeklärt:
    Ich hatte ganz zu Anfang bei Google meine Doamin mit www-URL angemeldet und so crawlen lassen. Allerdings hatte ich später mal wegen der möglichen DoubleContent-Problematik die Entscheidung getroffen, per htaccess alles auf die NON-www-URL umzuleiten. Bei GoogleSearch fand ich dazu, dass Google automatisch die NON-www-URL beim Crwalen berücksichtigen würde, wenn es beim Crawlen auf die NON-www umgeleitet würde.
    Diese Aussage von Google ist ganz offensichtlich FALSCH!


    Nun habe ich das NON-www-URL Property zu der gleichen Website angelegt und dieses natürlich auch (das muss man auch!) als bevorzugte Crawling-Adresse angegeben. Resultat:
    Google crawlt dann NICHT automatisch die neue NON-www-URL von Neuem, sondern man muss das Crawling von Neuem veranlassen!


    Aber nicht nur das! Google findet für die NON-www-URL keine sitemap.xml und reklamiert diese auch als fehlend, obwohl natürlich die sitemap.xml nach wie vor die gleiche geblieben ist und auch mit der gleichen URL erreichbar geblieben ist und obwohl die sitemap korrekt in der robots.txt eingetragen ist!
    Mit anderen Worten: Man muss jeden Furz von Neuem bei Google anmelden, weil es sonst nicht eigenständig von Google gefunden wird!!! – Wenn Google doch sonst so pfiffig beim Crawlen ist, so scheint hier aber Vieles im Argen zu liegen.


    Ein weiterer Knackpunkt liegt bei meiner Suche nach den Such-Ergebnissen. Es ist hinlänglich bekannt, dass Google die Suche individualisiert an den Benutzer anpasst, sodass er bevorzugt immer nur etwas Ähnliches geboten bekommt, wie das, was er schon zuvor mal gesucht hat. Also scheint die eigene Seitenposition immer besser zu werden, je öfter man danach sucht und womöglich auch noch auf das Suchergebnis klickt. Deshalb hatte ich die Suchmaschine Startpage benutzt, welche im Hintergrund durchaus Google-Ergebnisse verwendet.
    Nun zeigte sich aber (auch bei anderen Suchen), dass die Trefferqualität bei Startpage allmählich immer schlechter wird und zeitweilig gar nichts Sinnvolles mehr gefunden wird! Füür eine neutrale Überprüfung der eigenen Ranking-POsition für bestimmte Keywords taugt Startpage also gar nicht mehr.
    Also habe ich auf einem alten Laptop eine Linux-Runtime (Ubuntu) von DVD gestartet und habe mit dem dort integrierten Firefox mein Ranking überprüft. Und siehe da, es ist bei etlichen Seiten besser, als ich dachte, bzw. besser, als von Startpage angezeigt.


    Aktuell bleibt mir also nur, etwas zu warten, bis die durchgeführten Änderungen Erfolg zeigen.


    Ich danke allen, die versucht haben, mir bei der Lösung des Problems zu helfen!


    Noch ein Tipp: Ich hatte versucht, über ebay-Kleinanzeigen einen SEO-Spezialisten zu finden, der mir bei der Problemlösung hilft. Was ich dabei erlebt habe, ist derart krass, unverschämt, beleidigend und arrogant, dass ich dort nie wieder eine Anzeige zu solchen Themen aufgeben werde. Von etwa 26 „selbsternannten SEO-Spezialisten” wussten allen Ernstes 11 nicht, welche Funktion / Wirkung die Tags "noindex, follow" auf einer Webseite auslösen! Weitere 8 wollten entgegen meiner klar formulierten Anzeige mir einen 6-Monats oder 1-Jahres-Service-Vertrag verkaufen mit mindestens 500 bis 1.000 Euro Pauschalzahlung zu Beginn und dann monatlich zwischen 200 und 800 Euro.
    99% aller Antworten bewiesen durch Rückfragen, dass sie nicht einmal dazu in der Lage oder dazu bereit waren, meinen Anzeigentext so sorgfältig zu lesen, dass die von mir klar und deutlich beschriebene Aufgabe überhaupt verstanden wurde!!!

    Hallo!
    Mehrere Versuche, bei Google Webmatsertools die URL auf NON-www umzustellen, blieben ergebnislos. Es wurde keine Änderung übernommen. Aber Google weist darauf hin, dass sie beide URLs auswerten würden.
    An der ganzen Problematik hat sich leider bis jetzt nichts geändert. Weder bei den Webmastertools noch in meiner PIWIK-Statistik sehe ich positive Veränderungen.


    Ich fand aber plötzlich, dass bei der Suche nach Keyword-Kombinationen wie Zwänge Rottweil auf der fünften oder siebten Suchergebnisseite meine Praxis in Tübingen aufgelistet wurde! Und dabei denke ich jetzt an „DoubleContent”, denn die Struktur und Teile des Inhalts sind schon sehr ähnlich. Kunststück – ich biete in Tübingen ja genau das gleiche an, wie hier in Rottweil!


    Meine zwei Fragen richten sich nun auf die Vermeidung von DoubleContent:
    1.) Geben mir Google Webmastertools einen Hinweis darauf, dass meine Site wegen „DoubleContent” abgestraft wurde? Wenn ja, wo finde ich den Hinweis?


    2.) Mir ist die Pflege der Inhalte von zwei Websites einfach zu aufwendig, zumal, wenn ich deutlich unterschiedlcihe Texte entwickeln muss für die gleichen Angebote und der gleichen inhaltlichen Struktur. Daraus meine Frage jetzt:
    Würde es ein mögliches „DoubleContent-Problem” lösen, wenn ich auf der Website der Tübinger Praxis nur kurze Introtexte in die Artikel setze und nach dem Klick auf den Weiterlesen-Button ein iFrame gezeigt wird, in dem der „Original-Artikel” meiner Rottweiler Website gezeigt wird? Immerhin würde Google dann ja beim Crawlen erkennen, dass hier fremder Content über iFrame eingebunden wird.


    Und falls die Idee mit dem iFrame funktioniert: Wie realisiere ich den Link des iFrames auf die Rottweiler Website, sodass nur der Artikel aber nicht die gesamte Website mitsamt Header und Menü im iFrame erscheint?