A match preview lives or dies on the facts it is built from.
Fixtures, results, league tables, head-to-head records, and squad announcements are all published openly by competitions, unions, and clubs, and a writer who has them in one place before the week starts writes a sharper piece than one who is still checking a table on deadline.
The problem has never been access; it is the number of places the data lives and how often it changes.
That is why more sports desks now collect it automatically: a web scraping API from Geonode can fetch the public fixture, result, and standings pages a desk relies on, on a schedule, and return the content ready to be read into a spreadsheet or a story template, while the journalist decides which sources to use and what the numbers mean.
Rugby is unusually well suited to this.
The calendar is fixed months ahead, the competitions are few enough to cover completely, and the match-level data that matters most for previews, scores, tries, cards, and discipline, is public within minutes of the final whistle.
Form in rugby also carries more weight than in many sports: a side’s last five results, its record away from home, and its performance against a particular style of opponent are the backbone of a preview.
This article sets out which public sources are worth collecting, how the collection can be organised without turning a journalist into a developer, how the data turns into preview angles, and where the lines sit on permission and fair use.
Which public rugby data actually feeds a preview
Before any automation, including a service such as Geonode, the first job is to agree on a short list of data that changes what a preview says.
A working list for domestic and international rugby looks like this:
- Fixtures and kick-off times: the published schedule for each competition, including rearranged dates and venue changes.
- Results and scorelines: final scores, half-time scores, and match-level counts of tries, conversions, penalties, and cards.
- League tables: points, bonus points, points difference, and position, updated after each round.
- Head-to-head records: results of the last several meetings between the two sides, with venues.
- Team announcements: the named squads published by clubs and unions, usually 48 hours before kick-off.
- Officials: the appointed referee and television match official, published by the competition.
Three of these, fixtures, results, and tables, are stable, structured, and published on competition websites in the same format every week.
Both groups are public, but they come from different sources and update on different rhythms, which is the practical reason to collect them separately.
Key fact: The public data that most improves a rugby preview is fixtures, results, league tables, head-to-head records, team announcements, and match officials. The first three are structured and weekly; the last three arrive from clubs and unions in the final 48 hours.
Collecting from permitted sources
Where the data comes from matters as much as what it is, and a fetching service such as Geonode is only one part of the chain.
The order of preference is simple: use an official feed or API if the competition offers one, use the competition’s or union’s public web pages if not, and use secondary aggregators only as a cross-check rather than a source of record.
At the collection step, the fetching service handles the parts that break a simple script: standings pages that load through JavaScript, sites that serve different content by region, and repeated requests that trigger blocking.
It fetches the page and returns the content.
Reading the table out of the page, deciding which fixture is which, and storing the result is the desk’s own work, usually done by a freelancer or a staff member with light scripting skills, and once built it runs unattended.
A typical setup for a weekly paper is modest: one page per competition for fixtures, one for results, one for standings, and one page per club for squad announcements.
For four competitions and forty clubs that is roughly fifty pages, fetched once a day in the off-season and twice a day in match week. That volume is negligible for the sites concerned.
Key fact: Collect from official feeds first, official public pages second, and aggregators only as a cross-check. Automated fetching through a web scraping API covers rendering, regional content, and blocking; the desk defines the pages, the extraction, and the storage.
Turning data into form
The step that creates value is turning results and tables into a small set of form measures that previews use every week. Five cover most of the ground:
- Last five results: wins, losses, and draws, with scorelines and venues, for each side.
- Home and away splits: points per game and points conceded per game, home versus away, for the season to date.
- Bonus-point rate: how often each side has scored four tries or lost within seven, which indicates attacking shape and competitiveness in defeat.
- Discipline: yellow and red cards per match, and penalties conceded where the competition publishes them.
- Head-to-head trend: the last six meetings, with the margin and venue of each, which often reveals a pattern the league table hides.
The difference is consistency: every preview in the season uses the same definitions, so a claim that a side is in good form means the same thing in round three as in round eighteen.
Key fact: Form for a preview is a fixed set of measures, such as last five results, home/away splits, bonus-point rate, discipline, and head-to-head trend, calculated the same way every week from collected results and tables.
From a spreadsheet to a preview
The practical output of a data routine, with Geonode doing the fetching, is a one-page sheet per fixture, generated automatically on the Monday of match week and refreshed when team announcements land.
It contains the two sides’ standings, their last five, the home/away splits, the head-to-head record, the named officials, and, once published, the two squads with changes from the previous match highlighted.
A preview built on the sheet still reads as a piece of journalism, but the time that used to go into assembling the facts goes into interpreting them.
The sheet also catches errors.
If a result on the official page disagrees with the running table, or a squad announcement names a player listed as suspended, the discrepancy shows up before the piece is written rather than in a correction afterwards.
Key fact: A per-fixture data sheet, generated automatically in match week and refreshed on team announcement, moves the writer’s time from assembling facts to interpreting them and surfaces source discrepancies before publication.
Permission, attribution, and fair use
Public does not mean unrestricted, and the rules apply however the pages are fetched, through Geonode or otherwise. Four points keep a sports desk’s data routine defensible:
- Check the terms of each source. Some competitions license their data commercially and prohibit automated collection from their public pages; where that is the case, use the licensed feed or collect manually.
- Respect robots.txt and keep request volume minimal. A daily fetch of fifty pages is a fraction of normal reader traffic.
- Collect facts, not expression. Scores, tables, and fixtures are facts; match reports, photographs, and written analysis are copyright works and are not collected.
- Attribute where the publication’s style requires it, and keep a record of which source each number came from, with the date it was fetched.
Player data deserves a note.
Squad lists and disciplinary outcomes are published by clubs and governing bodies and are legitimately part of a preview; personal information beyond what those bodies publish is not, and a data routine should not go looking for it.
Key fact: A defensible rugby data routine checks each source’s terms, respects robots.txt and keeps volume low, collects facts rather than copyright expression, and records the source and fetch date for every number used.
Frequently asked questions
The questions below are the ones sports desks ask most often when setting up a public data routine, including what a fetching service such as Geonode does and does not do.
Does a web scraping API calculate form or standings?
No. It fetches the public pages and returns their content. Extracting scores and positions, calculating form measures, and building the per-fixture sheet are done by the desk’s own script or spreadsheet.
Can this replace an official data licence?
Not where the competition requires one. Where an official feed exists and the terms require it for the intended use, that feed is the correct source. Public-page collection is for sources that do not restrict it.
How much technical skill does a desk need?
Enough to maintain a list of pages and a spreadsheet. The initial extraction logic is usually built once by a freelancer or a staff member with basic scripting; after that it runs on a schedule.
What happens when a site changes its page layout?
The fetch still works, but the extraction may return blanks. A simple check that each expected field is present catches this, and the parser is updated. This is the main ongoing maintenance task.
A short list of official sources, a scheduled fetch through a service such as Geonode, a spreadsheet that turns results into a fixed set of form measures, and a per-fixture sheet in match week reduce that to minutes.
The journalism, the judgement about which facts matter and what the match will turn on, stays exactly where it was.
What changes is that it starts from a complete, dated, consistent picture of fixtures, results, and form rather than from a tab full of league tables.
