Xparo Blog - ASP.NET, jQuery, Silverlight, Sharepoint, contentXXL and more ...

Sep 22
2011

Onsite SEO: Der page title (Seitentitel)

Tags: SEOpage titleusabilityCMS Simon Schramm

Der page title (dt.: Seitentitel) ist einer der wichtigsten Rankingfaktoren für Suchmaschinen - nichtsdestotrotz findet der page title bei Aufbau von Websites oder in der Suchmaschinenoptimierung oft nicht die nötige Beachtung und wird geradezu stiefmütterlich behandelt.


Was ist der page title?

Der page title ist ein Wert im html-Quellcode, der im <title>-tag einer Seite definiert wird. Üblicherweise findet sich der page title im <head>-Bereich einer Seite (falls nicht, besteht hier schon ein Problem). Sichtbar wird der page title an verschiedenen Stellen:
 

Im Quelltext einer Seite:

<?xml version="1.0" encoding="UTF-8" ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional
<html lang="de" xml:lang="de"  xmlns="http://www.w3.org/1999/xhtml">
    <head>
<!-- internal url: http://www.xparo.com/desktopdefault.aspx/tabid-1/ -->
        <title>Xparo | Internetagentur auf Basis Microsoft .NET CMS-Technologie</title>

Im Browser (Beispiel Mozilla Firefox):

Xparo-Page-Title-SEO

page title bei xparo.com
 

In der Suchergebnisliste (Beispiel google):

 

Xparo-SEO-Serps

page title in den Serps

Anhand dieser Beispiele wird ersichtlich, dass der page title zum einen eine hohe Relevanz für den (potentiellen) Besucher einer Website besitzt - der page title liefert für den Webseitenbesucher wichtige Hinweise hinsichtlich der Relevanz der Webseite, zum anderen ist der page title eines der wichtigsten Kriterien für die bots von Suchmaschinen, um die Wichtigkeit und thematische Relevanz einer Webseite zu erfassen. 

Deswegen gilt es bei der Verwendung des page titles einige Grundregeln zu beachten:

Jede Seite eines Webauftritts sollte einen einzigartigen page title besitzen: Ungünstig sind vor allem Konstellationen, in denen mehrere Seiten innerhalb eines Portals den gleichen page title verwenden (z.B. lediglich den Unternehmensnamen) -Suchmaschinen tun sich dann sehr schwer, diese Seiten voneinander zu unterscheiden, im Extremfall werten Suchmaschinen diese als duplicate content. Noch ungünstiger sind Webseiten, die gar keinen page title verwenden. 

In vielen Content Management Systemen wird der page title anhand der angelegten Verzeichnis- oder Navigationsstruktur automatisch generiert. Gibt es z.B. in der höchsten Ebene "Produkte" und in der darunter liegenden Ebene mehrere Items "Produkt 1 - n", wird der page title oft lauten: "Produkte - Produkt 1 - n". In vielen Fällen mag diese Anordnung sinnvoll sein (und vor allem zeitsparend für den content editor), in einigen Fällen kann dieser Umstand eher ungünstige Effekte hervorrufen, nämlich wenn der page title zu lang oder zu kurz ist: Generell sollte der page title nicht länger als 60-70 Zeichen sein, aber auch nicht kürzer, gerade wenn es sich um landing pages handelt, auf denen passende keywords untergebracht werden sollen. Der page title kann durchaus auch länger als 60-70 Zeichen  sein, allerdings ist er dann z.B. in den google Ergebnislisten nicht komplett sichtbar.

Im Fokus bei der Erstellung von page titles sollte die angenommene Erwartungshaltung des Users stehen: Kann der User anhand des page titles und der dort verwendeten keywords sofort und schnell die Bedeutung der Website erfassen?
 

Generell gilt: Keywords, die am Anfang des page titles stehen, werden höher gerankt als keywords, die am Ende des page titles stehen. Ungünstig sind page titles, in denen seitenübergreifend der Unternehmensname am Anfang des page titles steht - gerade wenn es um Dienstleistungen oder angebotene Produkt geht, sollten deren Bezeichnungen und thematisch passende Begrifflichkeiten am Anfang des page titles stehen. Die Verwendung des Unternehmensnamens am Anfang des page titles macht Sinn:

    auf der Home-Seite
    auf der Kontaktseite
    auf der Impressumsseite

auf allen anderen Seiten sollten seitenbezogen passende Begrifflichkeiten in den Vordergrund gestellt werden. Nichtsdestotrotz kann der Unternehmensname seitenübergreifend z.B. als Abschluss des page titles eingesetzt werden: "Leistungen rund um Internet, Intranet, Extranet - Xparo" (Beispiel). Wichtig ist in diesem Zusammenhang auch, dass keywords nicht mehrfach und in zig Kombinationen im page title untergebracht werden.
Abhängigkeiten zu headings, content, URLs und Metatags

Generell gilt - wie bei allen onsite SEO-Maßnahmen - , dass auch die Erstellung von page titles nicht als isolierte Maßnahme betrachtet werden sollte. Eine Optimierung macht nur Sinn, wenn vor allem folgende Punkte beachtet werden:

    im page title verwendete keywords sollten auch in den Überschriften (H1 - Hx) des Textes vorkommen
    im page title verwendete keywords sollten auch im Text und in den alt tags von Bildern platziert werden
    auch der description und keywords metatag sollte keywords aus dem page title enthalten
    die keywords sollten sich auch in der verwendeten sprechenden URL wiederspiegeln

Jun 21
2011

Getting the most out of contentXXL editing

Tags: contentXXLusability Nina Hofmann

Customize your Basicdata

  1. Tailor the displayed fields to your needs

    Hide the fields, the editor doesn’t need and show only those that are required or used in the template.
     
    By default, e.g. the contacts form probably shows far more fields that you might ever need. So, to make editing simpler, just remove those, you don’t need.
    Depending on the module type you want to customize, you’ll find the layout of the form in the basicdata files saved in the folder:

    /contentxxl/modules/[ moduletype]/admin/basicdata.ascx


    Copy this file to your shadow directory, in order to prevent it from being overwritten by a future software update:

    /portaldata/[portalid]/shadow/contentxxl/modules/[moduletype]/admin/basicdata.ascx

     
    In the end, your form might look like this:
     
    Beware:

    You can’t simply delete those additional controls from the basicdata.ascx, as you’ll run into a problem when trying to save your data: contentXXL requires several fields to be set (NOT NULL values in the database). Therefore, the solution is to simply make the table row runat=”server” and set visible=”false”.

    ?
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    <fieldset class="admin-fieldset" runat="server" visible="false">
        <legend runat="server" id="Legend4">[l_employee_data]</legend>
        <table class="admin-inner-table">
            <tr>
                <td align="right" class="adminlabel">
                    [l_profession]
                </td>
                <td class="admin-settingsvalue" id="professionrow2">
                    <asp:TextBox ID="profession" Rows="1" CssClass="admin-element-width" runat="server" />
                </td>
            </tr>

    See also: http://partner.contentxxl.com/desktopdefault.aspx/tabid-11/5_read-434/

  2. Hide tabs based on roles

    Hide the tabs the editor doesn’t need, in order not to overwhelm him.

     

    To do this you need to edit the configuration file that defines the edit dialog. 

     

    Since you don’t want lose any change through a software update, remember to copy the file into the shadow folder of you portaldata folder.

     

    Then edit editobjectconfiguration.xml to hide the tabs.

    ?
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    <?xml version="1.0" encoding="UTF-8"?>
    <oem GlobalIDPrefix="Blogs" MayAttachTask="true" MayPublish="true" ObjectName="Blogs" ShowLangSelection="true" HelpTopic="blogs_editor">
      <tabs>
        <tab name="basicdata" ContainsCustomData="true"
            Src="/contentxxl/modules/Blogs/Admin/basicdata.ascx"
            CheckShadow="true" Label="basic_data" Type="page_custom" />
        <tab name="smartedit" ContainsCustomData="true"  Type="page_layout" />
        <tab name="metadata" ContainsCustomData="false"  Type="page_metadata" />
        <tab name="related" ContainsCustomData="false"  Type="page_relatedobjects" loadOnDemand="true" />
        <tab name="publishinfo"  roles="6" ContainsCustomData="false"  Type="page_publishinfo" loadOnDemand="true"/>
        <tab name="security"  roles="6" ContainsCustomData="false"  Type="page_securityinfo" loadOnDemand="true"/>
        <tab name="history" roles="6" ContainsCustomData="false"  Type="page_protocol" loadOnDemand="true"/>
      </tabs>
    </oem>
     

    See also: http://partner.contentxxl.com/desktopdefault.aspx/tabid-11/5_read-2075/

  3. Get rid of the default WYSIWYG editor

    Exchange it with FCK editor, that’s already used for inline forms

     

    You can do this by editing editobjectconfiguration.xml. Remember to please a copy of it into the shadow folder for each module type you want to change the editor (see above).

    ?
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    <?xml version="1.0" encoding="UTF-8"?>
    <oem GlobalIDPrefix="Blogs" MayAttachTask="true" MayPublish="true" ObjectName="Blogs" ShowLangSelection="true" HelpTopic="blogs_editor">
      <tabs><br>    <tab name="basicdata" ContainsCustomData="true" Src="/contentxxl/modules/Blogs/Admin/basicdata.ascx"
            CheckShadow="true" Label="basic_data" Type="page_custom" />
        
        <tab name="smartedit" ContainsCustomData="true" Src="/portaldata/0/fckeditor/fckeditor_description.ascx"
             CheckShadow="false" Label="wysiwyg" Type="page_custom" />
        
        <!--<tab name="smartedit" ContainsCustomData="true"  Type="page_layout" />-->
        
        <tab name="metadata" ContainsCustomData="false"  Type="page_metadata" />
        <tab name="related" ContainsCustomData="false"  Type="page_relatedobjects" loadOnDemand="true" />
        <tab name="publishinfo" ContainsCustomData="false"  Type="page_publishinfo" loadOnDemand="true"/>
        <tab name="security" ContainsCustomData="false"  Type="page_securityinfo" loadOnDemand="true"/>
        <tab name="history" ContainsCustomData="false"  Type="page_protocol" loadOnDemand="true"/>
      </tabs>
    </oem>

    Create a new file, e.g. fckeditor_description.ascx, that will hold the definition of the new WYSIWYG tab (wherever you like)

    ?
    1
    2
    3
    4
    <%@ Control Language="C#" AutoEventWireup="false" Inherits="ContentXXL.Admin.EditObjectManagerControl" %>
    <%@ Register Assembly="ContentXXL" TagPrefix="xxl" Namespace="ContentXXL.Admin.UI" %>
    <asp:TextBox runat="server" Visible="false" ID="Author" />
    <xxl:FCKeditor runat="server" ID="Description" Height="500px" />

    The file needs to include a field for Author. If it doesn’t exist, the author field would always be saved as a blank string. Even if something was entered in the basicdata form.

    Limitations:
    - some functions, like text snippets don’t work yet
    - you can’t save while you’re in html editing mode

Simplify page & module creation

  1. Create module settings templates

    The process of creating module can be significantly optimized by creating module setting templates.
    After creating a new module, the first step would be to select the templates the module should use to display the content.

     

    This can be a bothersome task, if you don’t know what each template does and how the templates have to be used together.

    So it’s much easier to import the template settings.


     
    The module setting templates can either be defined manually through the “ModuleSettings” manager:
     

    It allows you to configure most general and  custom settings per module type. Especially useful is the “Use as Default” setting, as this will get applied to every new module of that type.

    Tip: In most portals the majority of pages contain news modules, which are configured to show one article directly (contentXXL feature mode). Therefore, if you configure a module setting template for “Feature Mode” and set it as the default template, every new module will use it and you can quickly fill in you content.

    Another way to create such a template is by using existing modules as a boilerplate:
     
    Beware:  Plan ahead when creating modulesettings. If the “Export” function is used without care, you might end up with heaps of settings for the same layout.
    Also, consider a naming scheme, e.g. add a prefix based on function.

    System_ for settings only an administrator would use
    List_  for settings that include list and detailview
    SingleView_ for settings that use the feature mode

  2. Hide not required modules

    With version 2888 it’s possible to hide not used modules from the user. This can be done for each user role in the role administration.


     
    It affects both the layout mode of the pagesettings manager and the module manager

     
    See also: http://partner.contentxxl.com/desktopdefault.aspx/tabid-30/30_read-2198/