jumpurl for TYPO3

jumpurl has been out of the TYPO3 core since 7.6 and should no longer be used

For years, jumpurl was a fixed part of the TYPO3 core and did one simple thing: route downloads and external links through a redirect URL so that clicks could be counted. A PDF download did not go straight to the browser. It went through a jumpurl address that TYPO3 processed as a request of its own and then forwarded the visitor to the actual file. At the extension’s peak, jumpurl was a widespread solution for download tracking. Since TYPO3 7.6, jumpurl is no longer included in the core. It lives on as a standalone extension, but its architecture is outdated and modern alternatives are superior in every respect.

Anyone still running jumpurl is working with technology from the TYPO3 v4 era. The extension generates cryptic URLs with hash parameters that are neither human-readable nor SEO-friendly. The extension does not produce click counts of its own; it only redirects. For a feature that any standard analytics setup now covers with events, an extra redirect per click is simply no longer current.

Typical use cases were download tracking and link monitoring

The main scenario was, and still is, download tracking: how often was the white paper downloaded, how often the price list, how often the product catalog? jumpurl itself does not log anything; counting happens through the redirect requests, for example in the server logs. Companies with 50 to 200 downloads a day use this data for content strategy and lead qualification.

The second scenario is tracking external links. When a corporate website links to partners, suppliers or resources, the jumpurl redirects in the server logs reveal which external destinations get the most clicks. That matters for affiliate programs, partner reporting and the analysis of user behavior.

The third scenario is secure downloads with access control. jumpurl can tie downloads to a user login so that only logged-in users can download files. The token system ensures that direct URLs to protected files do not work. For companies that want to release white papers, technical documentation or price lists only after login, this was the standard solution in the TYPO3 v6 and v7 era.

The technical architecture rests on URL rewriting and a redirect through TYPO3

Since version 8, jumpurl registers a PSR-15 middleware in the TYPO3 frontend that intercepts incoming requests carrying a jumpurl parameter. The parameter contains the target URL or the file path, and a second parameter (juHash) contains a hash that protects the address against tampering. The middleware validates the hash and forwards the browser to the actual target with a redirect, by default with status code 303. The extension does not create a table of its own for access data.

Configuration happens through TypoScript: globally with config.jumpurl_enable, per link or file link with the typolink option jumpurl, and for email links it can be switched off with config.jumpurl_mailto_disable. The extension automatically rewrites the generated links in the frontend, so editors do not have to change anything by hand. The integration is transparent: editors link files as usual, and jumpurl slips the redirect in between.

The extension has no tracking log or backend module of its own. What gets analyzed is what the web server logs anyway: timestamp, IP address, the requested jumpurl address with its target, HTTP referrer and user agent. The IP address alone brings these logs within the scope of the GDPR.

Common problems involve SEO, the GDPR and compatibility with URL routing

Problem one: SEO damage from redirect chains. jumpurl URLs are not real page URLs but redirect intermediaries. If Google indexes a jumpurl link, which happens with a misconfiguration, the result is a redirect chain that wastes crawl budget and dilutes link equity. The fix: make sure jumpurl URLs carry a noindex tag or are blocked by a robots.txt disallow rule.

Problem two: GDPR compliance. jumpurl itself stores nothing, but every click ends up in the web server log together with the IP address. Without pseudonymization or a deletion policy, that violates the GDPR. The server logs therefore have to be purged regularly, or the IP addresses have to be anonymized before they are stored.

Problem three: compatibility with modern URL routing. TYPO3 v12 uses site handling and Symfony-based routing. As a middleware, jumpurl does run under v12, but it appends its parameters to the page URL as a query string, so the speaking URLs of the routing get cryptic additions again. The fix is migrating to a modern alternative. On top of that, the cryptic jumpurl parameters in the address bar hurt the user experience: visitors see a URL full of hash values instead of a readable file path, which can breed mistrust.

Migrating to event-based tracking is the recommended path at every TYPO3 upgrade

The extension is still maintained: version 9.0.0 from November 2024 supports TYPO3 v12.4 and v13.4. For a migration, Gosign nevertheless recommends switching to event-based download tracking. In practice, that means a data attribute on download links (for example data-track=“download”) and a JavaScript event listener that sends clicks to Matomo, Google Analytics 4 or a custom endpoint. For secure downloads, the modern alternative is FAL-based file access combined with a token system.

The migration effort depends on the number of existing jumpurl links. If external sources such as newsletters, social media or print materials point to jumpurl URLs, redirects have to be set up. Gosign analyzes the existing access data for the jumpurl addresses, identifies the most-used downloads and configures the new tracking solution so that historical comparability is preserved. Typically, 80% of existing jumpurl links are internal links that can be rewritten automatically. The remaining 20% are external references that need permanent 301 redirects so that no link equity is lost.