Sitemap customizen
Pfade für Unterdomains
Wenn man seine Sitemap nicht als „Unterseite der Startseite“ positioniert, oder mit Unterdomains arbeitet, dann muss der Zugriffspfad (ggf.) optimiert werden. Normalerweise wird jeder Link mit „..“ begonnen, und damit kehrt man im Verzeichnis-Pfad auf das Hauptverzeichnis zurück. D.h. die Link-Angabe „../index.php“ auf der Seite http://www.meinedomain.de/sitemap.php zeigt mit relativen Pfaden auf das Hauptverzeichnis. Wird eine Subdomain genutzt, dann wird der Startpfad „..“ automatisch um die Pfadangabe für die Subdomain erweitert.
Pfad Domain Startpfad
http://www.meinedomain.com ..
http://www.meinedomain.com/de ../de
Die Formel dazu findet sich in Zelle I30 auf Blatt <e-sitemap>.
=".. "&WENN(ISTFEHLER(FINDEN("/";'Easy Use'!I21;8));"";TEIL('Easy Use'!I21;FINDEN("/";'Easy Use'!I21;8);99))
Will man aber einen Pfad für die Sitemap-Seite nutzen, der nicht direkt unter der Startseite liegt, sondern unter einer anderen Hauptseite, dann muss man, um weiterhin relative Pfade zu nutzen, zwei oder drei oder vier Verzeichnisse nach oben wechseln, je nachdem wo die Sitemap-Seite in der Pfade-Hierarchie liegt.
Pfad Sitemapseite | Startpfad |
http://www.meinedomain.com/sitemap.php | .. |
http://www.mdom.com/services/sitemap.php | ../.. |
http://www.mdom.com/de/services/sitemap.php | ../../../de oder auch ../.. |
Summary: Sitemaps, die nicht unter der Startseite liegen, müssen in der Formel angepasst werden, Subdomains jedoch nicht.
Die Formel wird dort verändert, wo die zwei unterstrichenen „..“ Punkte den normalen Startpfad ausgeben. Der Rest der Formel ist für die Ermittlung der Pfade von Subdomains.
Verändert man die führenden „..“, also die relative Pfadangabe zu einer fixen Adresse, die beginnt dann einfach mit „http://www.meinedomain.de/“, dann ist das zwar auch möglich, aber in der Vorschau zeigen alle Pfade bereits auf die „finale“ Webadresse und sind nicht mehr „lokal“. Damit ist ein Test der Ausgabe eingeschränkt, bzw. nicht so durchgängig möglich, denn solange die Seiten nicht hochgeladen sind, gehen die Pfade ins Leere. Sind die Daten hochgeladen, zeigen die Pfade immer auf die zuletzt hochgeladenen Seiten und nicht auf die aktuellen Inhalte. Aber die Möglichkeit hier einzugreifen bietet die Chance, die auch Sitemaps ganz wo anders abzulegen und dann auf die eigene Domain zu verzweigen. Es ist also auch ein Feature, wenn man weiss, es sinnvoll zu nutzen.
Kleinere Logos
Gerade für große Seiten sind die Logos zu groß und der nötige Zeilenabstand von 24 px führt zu extrem langen Seiten. Es gibt im Blatt „Read Me“ ein Zip-File mit kleineren Icons. Die Icons können auch mit einem beliebigen Bildeditor bearbeitet und verkleinert werden. Dann kann man den Zeilenabstand auch entsprechend verringern.
Sichtbar vs. unsichbar
Die Sichtbarkeit einer Seite wird in web2date durch die Checkbox “in Navigation und Aufmachern anzeigen” in dem Eigenschaftsfenster festgelegt. Dies wird von web2date führend genutzt. Wenn man aber gezielt eingreifen will und einige sichtbare Seiten unsichtbar stellen will, oder obwohl eigentlich unsichtbar, diese Seiten in der Sitemap darstellen will (z.B. die Danke-Seite auf Anfragen), dann kann man in e-sitemap mit der Option (3) während der Sitemap-Erstellung anhalten. In die Spalte A) kann man in MappeX.xls dann editieren und WAHR und FALSCH ggf. abweichend zur main.mdb vergeben.
Hat man diese Option gewählt, wird man mit einer MessageBox zur Pflege aufgefordert. Nach der Pflege klickt man in <e-sitemap> auf den jetzt sichtbaren Button „Weiter“. Stellt das Tool dann fest, dass es eine manuelle Pflege gab, dann fragt das Tool, ob diese Abweichungen im Tool dauerhaft gespeichert werden sollen. Antwortet man mit „Ja“ werden die Abweichungen in das Blatt <Löschliste> übernommen:
Die Löschliste wird additiv zu den Angaben in der main.mdb. Sind die Angaben einmal gespeichert, und wurde dann das Tool gespeichert, sind beim nächsten Sitemap-Generierungslauf diese gepflegten Abweichungen wieder verfügbar. D.h. über die Unique-ID eines Absatzes kann die einmal gepflegte Eigenschaft dauerhaft hergestellt werden. Die Löschliste wird immer additiv. Dabei löscht sie nicht nur, sie kann auch sichtbar machen.
Wenn eine neue Löschliste gespeichert wird, und bereits Einträge vorhanden sind, dann wird man gefragt, ob die vorhandene Liste überschrieben, oder ergänzt werden soll "Additive Speicherung nach den vorhandenen Einträgen". Damit kann man mehrere Projekte getrennt nach Domains gleichzeitig im Tool verwalten.
Hat man aber die Option 4 aktiviert, wird unabhängig ob sichtbar oder nicht, ob manuell gepflegt oder aus der main.mdb ausgelesen, dann wird also immer jeder gefundene Seite in der Sitemap ausgegeben.
Hat man Option 5 deaktiviert, dann wird die Löschliste im Tool deaktiviert. D.h. die manuell gepflegten Abweichungen werden nun nicht berücksichtigt.
Die weiteren Optionen 6… sind selbsterklärend, und die Optionen 10 und 11 sind nicht zu verändern, die Werte werden im Tool selbständig definiert.
Nebeneffekte:
- Nur in der Sitemap enthaltene Seiten werden auch indexiert für eine Suche und im Tagging berücksichtigt.
- Die Löschliste wird über die Unique-ID der Absätze. Wenn jemand mehrere Projekte gleichzeitig verwaltet mit eigenen Löschlisten, dann muss er das Tool mehrfach pflegen. Beim Download einer neueren Tool-Version muss man die Löschliste im Blatt <Löschliste> aus der alten Version per STRG+C herauskopieren und in die neue Version übernehmen mit STRG+V oder die Löschliste neu pflegen.