Search Engine Indexing
To rank prediction content, fetch it from the platform API and render it in your own pages.
This guide gives the platform behaviour that changes how you do that. It does not repeat general SEO advice.
Do not expect the widget iFrame to rank
A crawler treats an iFrame as a separate document on its own origin. Your page gets no credit for the content inside it.
The predictions host also returns noindex on every route, and it stays that way. That host
serves the widget without login or payments, and it must not appear in search results.
Keep the widget for bet placement. Build the indexable pages as a separate server-rendered layer on the same page.
Render the content on your server
Three read endpoints supply the content. All three are public and need no JWT:
Fetch them from your server, not from the browser. A crawler that loads a page and finds an empty container indexes nothing.
Build category pages first
The platform generates a category slug once, from the category name, and never generates it again. A rename changes the display name and keeps the slug. Category slugs are also unique among live categories. A category slug is therefore a stable URL segment.
One list request returns the events with their markets and outcomes, so a category page needs one call:
curl "https://<your predictions host>/api/v1/events?category=politics&locale=en&limit=20"
Tag slugs are unique too, and the tags parameter filters the same endpoint. The platform
copies a tag slug from the upstream source, so a tag slug is less stable than a category slug.
Build event pages from the event slug
No two live events share a slug, and the platform does not change one. An event slug is therefore a stable URL segment, like a category slug. The platform can remove a slug, so read the caution below before you publish a page.
Filter the events list by slug. There is no slug route. GET /api/v1/events/{id} accepts a UUID
only.
curl "https://<your predictions host>/api/v1/events?slug=who-wins-the-2028-election&locale=en"
The response holds zero or one event, with its markets and outcomes. One call gives you the
content for a page at /predictions/<category slug>/<event slug>.
An unknown slug returns an empty list with status 200. The API does not return 404. Read the first element, or show your own 404 page when the list is empty.
You get an empty list in three cases:
- The event has no slug. The platform copies the slug of a sourced event from the upstream source, which does not always supply one. It builds the slug of a manual event from the title.
- The platform removed the slug. The upstream source can give a slug to a different event, and the platform then clears it from the event that held it.
- The list excludes the event. It drops a draft, closed, settled or hidden event, and an event with no open markets. The slug parameter does not change these rules.
Get the event from the API before you publish its page. Do the same check before you publish the sitemap.
Set the canonical URL to your own page
Set <link rel="canonical"> to your own URL.
Never set it to the predictions host. That host returns noindex, so a canonical that points
at it takes your page out of the index.
Build the sitemap from updated_at
Each event carries updated_at. Use it for <lastmod>.
A list response omits an event that has no markets. The event still exists, and updated_at
does not change when this happens. A page you published earlier can stay in your sitemap after
the content is gone.
Check each published page against the API before you publish the sitemap.
Declare hreflang only for a verified locale
Send ?locale= to get localized text. Supported values are en, es, nl, fr, de, and
ru.
If a translation is missing, the response returns 200 with the base-language text and the same
shape as a translated response. You cannot tell the two apart. A page built with ?locale=ru
can therefore contain English titles.
Declare hreflang for a locale only after you confirm that the content is translated. A page
that declares hreflang="ru" and shows English competes with your English page for the same
result.
Cache the responses
Cache the API responses and serve your pages from the cache. Do not call the API once for each page request. A crawler requests many pages in a short time, and your own visitors request the same pages.