When a transit agency adds real-time service information to its website, the first instinct is often to display every available feed item. That can create a different problem: riders see a vendor alert, a homepage banner, a manual notice, and a social post that all describe the same disruption in slightly different words.
The better goal is not “show more alerts.” It is “show one clear version of each active issue.”
Start with message ownership
Before connecting an operations feed to WordPress, decide what each system is responsible for. A real-time platform can provide route, stop, or vehicle-service information. Website staff may need to explain a detour, confirm a temporary boarding location, or provide a customer-service instruction. Those are different jobs, and both are valuable.
In a practical setup, an automated item should not silently overwrite a staff notice. Likewise, a staff notice should not require a person to turn off the entire feed. Give each item a recognizable source, a status, and a clear expiration rule.
Use matching rules people can understand
- Match on the operational issue when the feed supplies a reliable identifier.
- Keep a manual notice distinct when it adds rider instructions rather than repeating the disruption.
- Display the most useful current message first, not simply the most recently received data.
- Show when an alert was last updated so riders can judge freshness.
These are editorial decisions as much as technical ones. A clean interface has to account for exceptions: a feed item can be incomplete, a detour can change twice in one day, or a staff member may need to post before an automated system reflects the situation.
Give staff a safe manual lane
WordPress is useful here because staff can create a concise, time-bound notice without needing an operations-system login. The public page can then bring automated and manual information together, while the agency preserves a simple publishing workflow and an internal record of the communication.
For riders, the architecture should be invisible. They should see one service-disruptions page that answers three questions quickly: Is my service affected? What changed? What should I do next?