If you use the tt_news extension to publish news on you site, cooluri provides you with a default configuration to generate nice urls for your news articles.

tx_ttnews[tt_news]
SELECT title FROM tt_news WHERE uid=$1


1


However, this default snippet is not complete if you have news lists with more news items than the maximum to be displayed on a single page. In such a case, you tt_news provides a pagination below the news list to switch to further pages listing more news. This pagination is not supported by the default CoolURI configuration. If you click on a pagination link, you will stuck on the first page.

To fix this issue, you need to teach CoolURI about the pointer parameter of cooluri. Just search the xml snippet presented above in your CoolURI configuration (CoolUriConf.xml) and add the following lines:

tx_ttnews[pointer]

Refresh Typo3 cache and there you go.

As an example, you can check out the news archive on www.catering-guide-stuttgart.de : http://www.catering-guide-stuttgart.de/news/news-archiv.html

There are a lot of tools out there which take a website url as input and return several metrics also including the keyword density.

However, if you have to write your text before it is published on a website accessible for those tool, you need to keep an eye on on your keyword density upfront. To do this, you could use general word count facilities as provided by MS Word or others. But this requires you to count the keywords and calculate the density on your own. A more usable approach is to use a tool which directly returns the keyword density of the most frequently used words in your text.
There is a pretty simple but useful online tool provided by vexeo which you can use without any local installation: http://optimierung.vexeo.de/textoptimierung.html
Just put in your text, click the button and there you get your keyword density.

At the end, the reason for this is pretty simple. The apache webserver does not accept urls to have the %2F character in the url. In this case, the 404 page is used even before your .htaccess is evaluated. Unfortunately, the required apache configuration to allow %2F characters in URLs can not be set in the .htaccess within your webspace, but only in the server configuration in http.conf or in a virtual host configuration (http://httpd.apache.org/docs/current/mod/core.html#allowencodedslashes).

At the end, your only way is to ensure that your website does not generate any %2F encoded slashs in your URLs.

To fix this problem, you should open your .htaccess file and check your RewriteBase configuration.
If your website is located in a subdirectory of your webspace, you need to set the RewriteBase configuration to:
RewriteBase /

For Example, if you want to configure the .htaccess file shipped with Typo3, and your installation is in a sub-directory “/mywebsite/”, you should modify the file as shown below:

### Begin: Settings for mod_rewrite ###
# You need rewriting, if you use a URL-Rewriting extension (RealURL, CoolUri, SimulateStatic).
...
# Enable URL rewriting
RewriteEngine On

# Change this path, if your TYPO3 installation is located in a subdirectory of the website root.
RewriteBase / # <= The important part of the configuration ...

However, CoolURI does not support url preparation for urls generated by the calendar base extension out of the box. To enable this for a Typo3-based website you have to edit your CoolUriConf.xml configuration file. The required modifications teaches CoolURI how to translate the calendar base specific query parameters of your url into a nice url segments.
For example, there is a parameter “…html?tx_cal_controller[uid]=12” and we want CoolURI to integrate the title of the event with the uid 12 into the url itself such as “…/my-event-title.html”. Below, you will find much more parameters that need to be treaten.

Generally, there are two major sections (uriparts and predefinedparts) in your CoolURI configuration XML file you can use to tell CoolURI how to handle parameters:

...
<uriparts>
....
</uriparts>

<predefinedparts>
....
</predefinedparts>
...


“uriparts” are about query parameters that should be integrated in the nice looking url if they are present in the original url.
“predefinedparts” are about query parameters that should not be integrated in the nice url if they are present in the original url.
All query parameters in the original url that are not specified in one of these sections but present in the original url will be kept as query parameters in the nice looking url as well because CoolURI does not know how to handle them. This is also the reason why calendar base query parameters are not handled by CoolURI out of the box.

So let’s move on.

There are two parameters that we will not simply move from query parameters to url parts: the internal id of the event category and the internal id of the event itself. Those two parameters are defined as parts used for a lookup of the corresponding titles in the database:


<part>
<parameter>tx_cal_controller[category]</parameter>
<lookindb>
<to>SELECT title FROM tx_cal_category WHERE uid=$1</to>
<translatetoif>
<match>^[0-9]+$</match>
</translatetoif>
<urlize>1</urlize>
</lookindb>
</part>
<part>
<parameter>tx_cal_controller[uid]</parameter>
<lookindb>
<to>SELECT title FROM tx_cal_event WHERE uid=$1</to>
<translatetoif>
<match>^[0-9]+$</match>
</translatetoif>
<urlize>1</urlize>
</lookindb>
</part>

While we want them to be present in the nice looking url, we should place those two parts in the uriparts section.

All the other calendar base specific parameters are simply defined to be treaten and either ignored or moved inside the url. The following code snippets show the part definitions that can be placed either in the uriparts or in the predefinedparts section. But you should keep in mind, that the resulting nice url should still be able to uniquely identify url event page. So for example, if it might happen that there are multiple events with the same title make sure, that you include parts for the date (year, month, day) inside the uriparts section. If there might be events with the same name at the same date, you might need to include other parameters inside the uriparts section as well.


<part>
<parameter>tx_cal_controller[year]</parameter>
</part>
<part>
<parameter>tx_cal_controller[month]</parameter>
</part>
<part>
<parameter>tx_cal_controller[day]</parameter>
</part>
<part>
<parameter>tx_cal_controller[lastview]</parameter>
</part>
<part>
<parameter>tx_cal_controller[page_id]</parameter>
</part>
<part>
<parameter>tx_cal_controller[view]</parameter>
</part>
<part>
<parameter>tx_cal_controller[getdate]</parameter>
</part>
<part>
<parameter>tx_cal_controller[preview]</parameter>
</part>
<part>
<parameter>tx_cal_controller[type]</parameter>
</part>
<part>
<parameter>tx_cal_controller[gettime]</parameter>
</part>


Example Configuration
If you are not surehow to start in your specific case, you can move one with a common configuration we use in most cases:

Add the following lines at the end of you uriparts section:


...
<part>
<parameter>tx_cal_controller[category]</parameter>
<lookindb>
<to>SELECT title FROM tx_cal_category WHERE uid=$1</to>
<translatetoif>
<match>^[0-9]+$</match>
</translatetoif>
<urlize>1</urlize>
</lookindb>
</part>
<part>
<parameter>tx_cal_controller[uid]</parameter>
<lookindb>
<to>SELECT title FROM tx_cal_event WHERE uid=$1</to>
<translatetoif>
<match>^[0-9]+$</match>
</translatetoif>
<urlize>1</urlize>
</lookindb>
</part>
<part>
<parameter>tx_cal_controller[year]</parameter>
</part>
<part>
<parameter>tx_cal_controller[month]</parameter>
</part>
<part>
<parameter>tx_cal_controller[day]</parameter>
</part>

</uriparts>


And add the following code at the end of your predefinedparts section:


...
<part>
<parameter>tx_cal_controller[lastview]</parameter>
</part>
<part>
<parameter>tx_cal_controller[page_id]</parameter>
</part>
<part>
<parameter>tx_cal_controller[view]</parameter>
</part>
<part>
<parameter>tx_cal_controller[getdate]</parameter>
</part>
<part>
<parameter>tx_cal_controller[preview]</parameter>
</part>
<part>
<parameter>tx_cal_controller[type]</parameter>
</part>
<part>
<parameter>tx_cal_controller[gettime]</parameter>
</part>
</predefinedparts>


Note
Depending on your current configuration, you might need to specify the part order at the end of your CoolURI configuration file. If it is not present yet, try to add the following lines before the ending </cooluri>


<partorder>
<part>pagepath</part>
<part>uriparts</part>
<part>predefinedparts</part>
<part>valuemaps</part>
</partorder>


A simple but effective solution is to place a robots.txt in your root that marks your template directory as disallowed for search engines. Even if a view craweler ignores this directory, the most important ones like google take care of it.
Btw: An .htaccess protectoin of the template directory is no solution while it still needs to be accessible for referenced resources like images, stylesheets or scripts.

# Example robots.txt
User-agent: *
Disallow: /fileadmin/templates

By default, typo3 palces the site title before the page title in the <title> tag.
While the order of the words in the page title make a big different for search engines, and search result presentation as well, it would be better to first present the page title and use the site title as as suffix.
For example:
<title>My Site : Infos</title>
<title>My Site : News</title>
could be improved to
<title>Infos – My Site</title>
<title>News – My Site</title>

Most Common Way
page.config.noPageTitle = 2
page.headerData.1 = TEXT
page.headerData.1.field = subtitle//title
page.headerData.1.wrap = <title>|&nbsp;-&nbsp;My Site</title>

This works fine as long as you only use simple pages.
As soon as extensions like tt_news enter the game, you will run into problems, because the configuration above always use the subtitle or title field of the page which would not work for tt_news single new view.
In this case, you can use the following setup within an extension template placed on the page containing the single news view:

#
# Page title from tt_news
#

page.config.noPageTitle = 2
temp.newsTitle = COA
temp.newsTitle {
10 = RECORDS
10 {
source = {GPvar:tx_ttnews|tt_news}
source.insertData = 1
tables = tt_news
conf.tt_news >
conf.tt_news = TEXT
conf.tt_news.field = title
}
}
temp.newsTitle.wrap = <title>|&nbsp;-&nbsp;Ellen Kamrad Eventmanagement</title>
page.headerData.1 < temp.newsTitle

#
# Keywords and Description in NEWS SINGLE
#

page.headerData.999 {
local >
local {
description.data = register:newsSubheader
keywords.data = register:newsKeywords
}
}

For the news page you are fine now. But what about other extensions such as cal or others able to automatically adopt your page title?
Even tt_news would be able to place the news item title in the page title.

mf_pagetitle Extension
With this extension, you do not need to block the default page title generation. The extension could be used to automatically add a suffix to the page title instead of the site title as prefix.
Just install the extension from the extension manager and add the following lines to your template setup.

includeLibs.pagetitle = typo3conf/ext/mf_pagetitle/pagetitle.php
plugin.mf_pagetitle.title = {page:title} – My Site
config.titleTagFunction = user_pagetitle_class->changetitle

If you need different page title suffix on a multilanguage website, this can be managed with the standard typo3 language switch facilities:

includeLibs.pagetitle = typo3conf/ext/mf_pagetitle/pagetitle.php
plugin.mf_pagetitle.title = {page:title} – My Site
[globalVar = GP:L = 1]
plugin.mf_pagetitle.title = {page:title} – My Site
[globalVar = GP:L = 2]
plugin.mf_pagetitle.title = {page:title} – Meine Seite
[GLOBAL]
config.titleTagFunction = user_pagetitle_class->changetitle