Install Dynamic Pages
Activate a domain, connect your website routes and verify the installation.
This guide connects a saved widget design to match, league, team and player pages on your website. Start with one domain and verify it before activating more.
You need access to your website’s routing
Dynamic Pages provides entity links and widgets. It does not create or host pages for you. You or your developer must configure the website to open those links, including when a visitor pastes a URL into a new browser tab. If your website builder only lets you paste an embed and cannot handle these routes, use Modal or in-widget navigation until the route integration is ready.
Before you start
- Pro or Ultra includes one Dynamic Pages domain. Additional domains cost €9/month each, requested through support. Custom accounts can arrange capacity.
- The website domain must be approved in the admin. Activating Dynamic Pages does not increase your base domain or traffic limit.
- Have permission to publish the website and configure its routes, or send this guide to the person who maintains it.
- Use the domain’s generated code and saved configuration throughout this guide. Do not copy another account’s identifiers or use the configurator preview as proof that your public website works.
1. Activate the domain and choose its design
Open Configurator → Domains and select your approved website domain. Check the Configuration assigned to it. This is the design visitors will receive, even if you are editing a different configuration in the top toolbar.
Enable Dynamic Pages. The counter shows the number of activated domains and your allowance. Activating your included domain does not charge your card. If the allowance is already in use, disable it on the previous domain or request additional capacity; wait for confirmation before activating another domain.
Open the assigned configuration, choose Dynamic Pages/page navigation and review the URL prefixes for matches, leagues, teams and players. Save the configuration. Domain activation alone does not switch the design’s navigation mode.
Return to the domain and select Get code. Confirm the domain and configuration in the summary. If the editor and the domain use different designs, save first and explicitly assign the intended configuration before continuing.
2. Connect the website
In Get code, expand Connect your Dynamic Pages · setup instructions. The displayed language and prefixes come from the configuration assigned to the domain. Use those values, rather than assuming every installation uses English or the default paths below.
| Entity | Default path | Widget attributes from the path |
|---|---|---|
| Match | /en/matches/{slug}/{id} | entity="match", matchid |
| League | /en/leagues/{slug}/{id}/{seasonid} | entity="league", leagueid, optional seasonid |
| Team | /en/teams/{slug}/{id} | entity="team", teamid |
| Player | /en/players/{slug}/{id} | entity="player", playerid |
Use real links generated by your widget for testing. The braces above are placeholders, not URLs to publish. The numeric ID identifies the entity; the human-readable slug is not a replacement for it.
Option A: start with the downloadable HTML
- Select Download page starter. The file already contains your widget identifiers, the selected language and the route prefixes.
- Publish that file on the approved website. Opening it as a local
file://document is not a test of domain approval or website routing. - Configure your host to serve the same HTML at the matching detail URLs while preserving the requested URL. This is a route mapping or internal rewrite, not a redirect back to the homepage. Configure only the paths used by these widgets; keep the rest of your website’s routes unchanged.
- Provide a livescore entry page using the installation code from Get code. Open a real entity link from that page. The starter reads its path, chooses the matching widget and passes the entity ID.
- Test direct visits and reloads using the checks below. If you change the language or prefixes later, download a fresh starter and update the host’s route mappings to match.
The starter is a client-rendered example, not a complete website. Its root paths
/ and /{language} can render livescore when served there; you do not need to
replace an existing homepage. It displays a not-found message for an unmatched
path, but your server must also return the appropriate HTTP status. It cannot
prove that a syntactically valid entity ID exists.
Option B: connect an existing application or CMS
Your developer can keep the existing page layout and routing. For each matching route, they need to:
- Read the language, entity ID and optional league season from the URL.
- Render the corresponding widget with the attributes in the table, keeping
the
uidandwidget-idfrom the domain’s generated installation code. - Load the widget script and styles from the generated code. On client-side route changes, update or remount the entity widget so the visible detail matches the current URL.
- Make the route work on a direct server request, not only after clicking within the application. WordPress and other CMS installations need route/template handling too; pasting a shortcode or the widget snippet alone does not add it.
- Handle malformed URLs, missing entities and loading errors without showing an unrelated livescore page as if it were the requested detail.
This is a routing contract, not a preconfigured React, Next.js or WordPress plugin. The exact route setup depends on your application and hosting.
3. Verify before announcing the installation
Run these checks on the approved public domain, on desktop and on the mobile browsers your visitors use. Use a fresh tab as well as the tab where you installed it.
| Check | Expected result |
|---|---|
| Open a match from livescore | Its URL opens and the match widget shows the same teams and match. |
| Open a league, team and player link where available | Each URL shows the corresponding entity, not the same generic page. |
| Paste each detail URL into a fresh tab | The detail loads without first visiting the homepage. |
| Reload a detail page | The same entity remains visible; no host 404. |
| Use Back and Forward | URL and visible entity stay in sync. |
| Open a link in a new tab | The original page stays usable and the detail works independently. |
| Visit an invalid path and a missing entity | The website gives an appropriate not-found/error response, not an unrelated page or an endless loader. |
| Select Check installation traffic | The selected domain shows activity after loading; this confirms requests, not correct rendering. |
Complete these checks with the published widget before sharing your new pages. The admin preview does not test the routes on your website.
Common problems
| Symptom | What to check |
|---|---|
| Details still open in a modal | Confirm Dynamic Pages is enabled on this domain, the assigned design uses page navigation, and that design was saved. |
| A click works but a reload returns 404 | The browser can change the URL but the host does not serve that route. Fix the route mapping/internal rewrite. |
| Every link returns to the homepage | Replace the redirect with a route that preserves the detail URL and renders its entity. |
| The wrong design appears | Check the domain’s assigned configuration and the domain/configuration summary in Get code. |
| Links use different language or prefixes | Compare the saved design, the displayed routes and the deployed starter; update them together. |
domain_unauthorized | Check the domain where the public page actually runs, including redirects, against Domains in the admin. |
| The domain allowance is full | Review the activation counter. Moving your included activation requires disabling its old domain; paid extras require confirmation. |
Search engines and page metadata
Having a working URL is only part of a page integration. Your website owns the HTTP responses, page titles, descriptions, canonical links, any server-rendered content and sitemap. Widget entity data can help your integration, but it does not automatically create those elements. Dynamic Pages does not promise search indexing or ranking.
Getting help
Send support the public URL, selected domain, configuration name, the entity URL that fails, browser/device and what happened versus what you expected. Include whether the failure happens on a click, direct visit or reload. Do not send API secrets, login credentials or payment details.
For plan eligibility and the feature overview, see Dynamic Pages.