README

License: GNU GPL, Version 2

Repository: https://gitlab.sgalinski.de/typo3/sg_seo

Please report bugs here: https://gitlab.sgalinski.de/typo3/sg_seo

About

This extension provides a Google sitemap implementation with additional features like:

• ignoring pages with canonical links to other pages
• respecting noindex & nofollow options
• ignoring shortcuts and status pages
• excluding Extbase detail/registration pages that only work with required route parameters (for example /details/{event} or /author/{author})

Sitemap filtering for parameterized plugin pages

To prevent SEO tools from reporting invalid sitemap entries, sg_seo excludes pages that only work when runtime route parameters are present.

How this works:

1. During sitemap page generation, a listener is executed on ShouldIncludePageInSitemapEvent.
2. The listener inspects site routeEnhancers and checks Extbase enhancers for required persisted route placeholders (for example {event}/{author}) without defaults.
3. Matching pages are collected from:
   • limitToPages (if present)
   • actual plugin usages in tt_content (CType and list_type)
4. These pages are excluded from the page sitemap index.

Practical effect:

• container/detail/registration pages such as /news/author/ or /events/details/registration/ are not emitted as empty URLs anymore.
• real detail URLs with concrete route arguments stay possible via dedicated sitemap providers (for example records-based providers).

Scheduler

There is one scheduler task for this extension:

1. A scheduler task to generate a sitemap for each language

Sitemap generation

This scheduler task can be activated to create static sitemaps of each language, which then can be delivered instead of a dynamic process which could take a long time.

The task takes 3 arguments:

1. relativePathToSitemap: Describes where to save the generated sitemap files in the file system. This defaults to the project root.
2. siteRootId: The id of the site root, where the sitemap will start
3. enableFilter: Switch to add hidden pages (does not affect "NOT_IN_MENU") to the sitemap

Extensions - SeoAccessPageListEventListener

You can hook into the process to extend the sitemap easily.

Example: Services.yaml

services:
    MyExt\Event\Listener\SeoAccessPageListEventListener:
        tags:
            -   name: event.listener
                identifier: 'accessPageListEvent'
                event: SGalinski\SgSeo\Events\AccessPageListEvent

EventListener class:

class SeoAccessPageListEventListener {
    public function __invoke(\SGalinski\SgSeo\Events\AccessPageListEvent $event) {
        $pageList = $event->getPageList();
        // ... do something with the list and write it back to the event
        $pageList[] = [
            'url' => 'MY FURTHER URL',
            'title' => ''
        ];
        $event->setPageList($pageList);
    }
}

More Events

Additionally there are new Events with sg_seo 5.3:

OverrideSitemapRendererEvent

allows to set a different Renderer for the final output

ShouldIncludePageInSitemapEvent

given an array of $pageInfo and a $language, you can decide not to use a page in normal pageRendering

Extensions - XmlSitemapDataProviders

We also support the official XmlSitemapDataProviders API of TYPO3. You can see more here https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/XmlSitemap/Index.html .

When we generate the sitemap, we generate every sitemap type to a new index. The default xmlSitemap type is being merged into our sitemap.xml. Please bear in mind, that we ignore any additional data providers for the pages unique key, as this is the default TYPO3 unique key and we don't want any duplicates. Use another unique key for your extension.

The other sitemap types are generated into their own respective sitemap indices.

Example (News extension):

plugin.tx_seo {
    config {
        xmlSitemap { // new entries to the default sitemap.xml
            sitemaps {
                news {
                    provider = GeorgRinger\News\Seo\NewsXmlSitemapDataProvider
                    config {
                        ...
                    }
                }
            }
        }
        googleNewsSitemap { // a completely new googlenewssitemap.xml
            sitemaps {
                news {
                    provider = GeorgRinger\News\Seo\NewsXmlSitemapDataProvider
                    config {
                        googleNews = 1
                        ...
                        template = GoogleNewsXmlSitemap.html
                    }
                }
            }
        }
    }
}

This example will result into the news unique key data provider entries being added into the default sitemap ( xmlSitemap). The googleNewsSitemap entry will fetch the entries from this dataprovider and create a brand new sitemap index.

Changing the values of your tags like , <description>, etc.</h2> <p>Overriding the values of <title> etc. is not trivial, as TYPO3's PageRenderer is sometimes called after caching the HTML output for the <head>. For this purpose we introduced the HeadTagService that you can call in your Controllers. It comes handy when you have plugins with database-driven models, and you want their metadata to be used for the page metadata. Check out this example with jobs:</p> <pre><code>$headTagService = GeneralUtility::makeInstance( HeadTagService::class, TRUE, $job->getTitle(), $job->getDescription(), '&tx_sgjobs_jobapplication[jobId]=' . $jobId ); $headTagService->execute(); </code></pre> <p>The second parameter is crucial - TRUE/FALSE describes whether the ControllerAction from which you are calling is cacheable or not. This way the service decides what is the proper way to override the values of the next arguments:</p> <ul> <li>title</li> <li>description</li> <li>GET arguments that must be appended to the router for the generation of the canonical and hreflang tags</li> </ul> <p>IMPORTANT: The way TYPO3 stores pages and extbase plugins in a separate cache can conflict with the usage of the HeadTagService. If you have a cacheable Plugin, which is executed on a cacheable page, the behavior results in the expected replacement of the head-tags. A cacheable Plugin on a non-cached page, however (as is the case with frontend logins, for example), will behave differently. Since the Plugin will eb saved, the code of the controller will not be executed and the head-tags will not be replaced. Since the page is not cached, it will generate the default tags, which might not match what SgSeo was supposed to generate for it. Keep in mind that you need to take care of those scenarios and set the Plugin to non-cacheable in such cases.</p> </body>