Live CockpitCMS+Svelte Projects:

7. SEO and Analytics

Prerendering

Since crawlers cannot handle 100% JavaScript pages:

public/index.php uses custom functions, Cockpit and CockpitQL to prerender the page for all User-Agents in the file. For other User-Agents it delivers svelte.html, where the main script bundle.js is linked, which then handles the rest of the page.

For prerendering, the free service prerender.io is currently used with a limit of 250 pages, therefore it is also the task of index.php to call prerender_request on as few unique pages as possible.

Languages

Supported languages are separately defined in App.svelte, public/index.php and cockpit/config/config.yaml.

Languages in URL

The language is always stored in LanguageStore.svelte, from where components access it according to two needs:

App.svelte: Initial initialization of supported languages
Router.svelte: Immediately after initialization, it checks the URL composition via LangDetectModule.svelte, if the language is missing it adds it. It also monitors changes to the current language in LanguageStore.svelte and if a change occurs it changes the language in the URL. All changes are exported back to App.svelte via the bind:fullslug parameter
Nav.svelte: Adds the current language before all links starting with "/" for localization.
Header.svelte and Footer.svelte: Adds the current language before links to all pages.
LangSelector.svelte: Only changes the current language in LanguageStore.svelte according to user selection, the address change is handled by Router.svelte

Sitemap

sitemap.php (custom implementation) always generates current XML based on the Pages structure in Cockpit

Analytics

The site currently does not use Google Analytics. It only collects information about the direction of navigation within the site, clicked internal links, and the length of time spent on the page. All information is completely anonymous, no personal identification, cookies, fingerprinting, etc. is included.

For storage, updateCounter() is used (in App.svelte) connected to the router via the afterReroute prop, an additional climbToSection() function to obtain the section within which navigation occurred, stamp for calculating time on page in UNIX format, and prevSlug in combination with slug to store the navigation direction.

On the server side, the POST is processed:

It is checked whether the sent data does not exceed the length
It is checked whether the data has not been manipulated, i.e. contains what it should
A timestamp is added to the data

This does not really prevent unwanted data manipulation by third parties, but provides sufficient protection against absolutely false data. For complete protection, fingerprinting with at least cookies would be necessary and it would therefore be necessary to inform the site user (GDPR, ...).

Favicons

Generated via Real Favicon Generator, they also provide a Node CLI, but it is not currently used.

Previous: 6. Performance, Graphical and Compatibility Issues
Next: 8. Deployment