A sports betting news publisher has more live sports data than most sites: prices, fixtures, start times, venues, results. On the site I have been working on, most of it used to arrive in the browser through JavaScript widgets. Readers could see it. Search engines mostly could not, and nobody could link to a particular view of it.
Recently I turned four of those data sources into real pages. The same handful of rules applied to all four.
Rule one: render live sports data on the server
If the table, the fixture list or the result is in the HTML that WordPress sends, it can be indexed, cached, read by a screen reader before scripts load, and seen by anyone with JavaScript off. The interactive layer goes on top. The sports calendar has a working filter form without JavaScript; with JavaScript it switches views in place.
Rule two: every value says how old it is
A price without a time is a guess. Each odds block shows the age of its prices. Closed markets keep their last prices, clearly marked, with the bet links removed. The calendar's status line says when scores and fixtures were last refreshed. Every block that shows a price also carries the 18+ and safer gambling line, because a cached fragment can end up anywhere.
Rule three: merge sources with care
The calendar draws from several places: data feeds, season hubs, the tips in published articles and recurring festivals. Merging them was most of the work. The rules that mattered:
| Problem | Rule |
|---|---|
| The same match from two sources, spelt differently | One entry per match, matched across punctuation and abbreviations |
| No known start time | Say "TBC" and group the entry under "Time to be confirmed", rather than showing midnight |
| A real midnight start, such as an evening game overseas | Keep 00:00, because it is true |
| A region that was not supplied | Work it out from the venue, terms and sport, never fall back to a default region |
| Festivals and biennial events | Narrow to the actual week, respect odd or even years, and hide one only with dated evidence for the same edition |
| A tip with no time | Date it from the race day or event name in the article |
The TBC rule is my favourite. The easy thing is to show 00:00 for an unknown time, and that is wrong in a way that looks right. Separating "unknown" from "midnight" took a few lines and removed a whole class of confusing entries.
Rule four: one address per view
Readers share things. A month view, a picked day or a single event should each have an address that reopens exactly that view. On the calendar, switching between month, week and list happens without a reload, and the address follows. Clicking an event opens a sheet over the page, and that sheet has its own shareable address too.
For search engines, the important part is the opposite: not every combination deserves indexing. Filter combinations are useful to a reader and noise to a crawler. My rule is that the canonical address of a view carries no filter parameters, and filtered views point back to it.
Rule five: one canonical, one robots tag
This sounds obvious. It was not happening. Some of the racing results pages were sending two canonical tags and two robots tags. Two canonicals that disagree are worse than none. They now output exactly one of each, section indexes lost a doubled slash in their addresses, and a beta query string no longer leaks into REST addresses.
Rule six: cache what has settled
A results day that has finished does not change. Those pages can go into the full page cache and be served instantly. A day still in progress cannot. Telling the two apart is one check, and it moves most of the results archive from expensive to free. The calendar's source caches rebuild when a post is published, so a new tip appears without waiting for an expiry.
The map
The sports map uses the same data with a different view: venues and race meetings as pins, filtered by the same rail as the calendar. It uses only the brand palette, in light and dark, and its fly-to animations respect the reader's reduced motion setting. The map is an interface. The calendar and event pages behind it are what get indexed.
Checklist
- Is the data in the server HTML?
- Does every value say how old it is?
- Is "unknown" distinguishable from a real value?
- Does each useful view have a stable address, and do filter combinations point back to it?
- Exactly one canonical and one robots tag?
- Are finished, unchanging pages cached as such?