Schema-First Lab

Case studies 4 entries

Case studies

Four working examples from Fort Dodge Radio and MyFortDodge.com.

Each case study follows the same order: the problem, what was built, and what it taught.

1. Fort Dodge Radio: one identity, described once

The problem. Fort Dodge Radio signed on April 1, 2019 with no transmitter, no frequency and no license: nothing a machine could look up. Its identity had to be built from scratch, in a form search engines and assistants could read.

What was built.

The Workday Engine hour: six songs between each of two 2-minute breaks '80s song'80s song'80s songStation ID and 2-minute break'70s song'70s song'70s song'80s song'80s song'80s songStation ID and 2-minute break'70s song'70s song'70s song 56 MIN MUSIC PER HOUR :00:15:30:45
  • '80s
  • '70s
  • ID + 2-min break
The Workday Engine clock. Song lengths are schematic.

Behind the sound. A library of 1,250 tracks, 625 from the '70s and 625 from the '80s, all ripped from CD. The same artist never plays twice within four hours, and no song repeats during business hours.

What it taught. Fingerprints belong only on things that never change. In September 2026 the station stopped publishing a fingerprint of its living schema file, because every edit broke it, and now uses a last-modified date instead. The award photo and archive keep theirs.

Seven years on. Fort Dodge Radio has been on the air since April 1, 2019: more than seven years, still going, still learning, still improving.

2. MyFortDodge.com: making events visible

The problem. MyFortDodge's community events lived in an embedded Tockify calendar. People could see it; search engines and AI crawlers couldn't. To a machine, the events page was nearly empty.

What was built. Events still start with people: locals submit them through a form, and Bill approves each one. Since July 2026, a Python script, sync_events.py, reads the approved events from the Tockify feed and writes them directly into the static events page twice over: as a visible list people can read, and as structured Event data machines can read. It runs every three hours on the Arvixe server.

The result. Google Search Console validates the event markup. Every event is now plain text on the page, readable by anything that visits.

What it taught. If a machine can't see it, it didn't happen. Embedded widgets are convenient for people and invisible to crawlers.

3. The market pages: how it scaled

Why a page for every market. The stream plays anywhere, but being available isn't the same as being found. When someone in Omaha asks a phone or smart speaker for classic rock radio, the answer depends on where they are as much as on what they asked for. Most online stations never say where they belong, so they rarely come up anywhere.

So for each market, the station has a page that introduces Fort Dodge Radio to that city: its communities, its commute, its music history, and why the format fits the workday there. The pages don't claim a hometown in those cities. They're written so people and search tools can both read them, and when someone in that market asks for this kind of music, the station is a match.

Twenty market pages work like twenty nets in the water instead of one. The network now covers the Fort Dodge home market plus 19 DMAs, from Sioux Falls to Detroit. Being found is only the first phase; turning a first listen into a regular listener comes next, and that takes time.

Round one: a script that guessed. The first version, built with Microsoft Copilot in 2025, used a geo-targeted script to inject each market's details into the page. It didn't work well, and was dropped.

Round two: routing at the edge. The routing moved to Cloudflare, which knows a visitor's city before the page loads and sends them to their market's page. Smoke tests checked, one market at a time, that each city landed in the right place. It is still running today.

Round three: built to scale. Scale was the goal from the start. Every market page shares one template, divided into tagged modules (header, schema, local hero, the Workday Engine, player, contact, footer), so a change can be made across every market at once. Each market's structured data sits in its own file, anchored to that city's Wikidata record.

Bill worked with Google Gemini to write master prompts for Claude. Given a market, the prompt produces a finished page, with local commute routes, major employers and music history woven in and the station's core promises untouched, in about two minutes instead of the 20 to 30 it took by hand.

What it taught. Plan for the hundredth page while building the first one.

4. Alexa: being found by name

The problem. "Alexa, play Fort Dodge Radio" has to work every time. Voice leaves no second page of results.

What was built. Fort Dodge Radio first had a custom Alexa skill, built on a third-party platform. When that platform dropped support, Bill moved the station to Amazon's Radio Skills Kit: a free listing that Amazon itself maintains. The station is listed as web-only (no frequency, no band) with a Fort Dodge location, genres of classic rock, '70s and '80s, and the Live365 stream.

Tuning the names. In August 2026 the alternate names listeners might say were rewritten. Broad phrases like "Minneapolis classic rock" came out; names that belong to the station went in: "F D Radio," "Fort Dodge Radio dot com," "The Workday Engine," "Fort Dodge Classic Rock." "Iowa Classic Rock" was considered and rejected, because it could collide with terrestrial stations using similar names.

The result. "Alexa, play Fort Dodge Radio" has worked reliably since the move.

What it taught. On a voice platform, a listener asking for you by name is discovery you control. Being recommended when they don't is the platform's decision. Build for the first; don't count on the second.