A GTFS feed that passes technical validation can still display wrong information to riders. Times might be correct in your data but appear under the wrong route. Stops might be in the right positions but assigned to the wrong trip. Testing goes beyond running a validator — it means visually confirming that your data represents your service accurately before riders depend on it.
The cost of getting this wrong is real: riders miss connections, get on the wrong bus, or lose trust in your service when the app shows something different from reality. A thorough test before publishing takes an hour and prevents weeks of complaints.
Your first step is always to run the feed through AddTransit's built-in validator. This checks the technical specification — required fields, data types, referential integrity, and so on. The feed must have zero errors before you proceed. See our guide on how to validate a GTFS feed for the full process.
Open agency.txt and confirm:
Do not trust that stop coordinates are correct just because the validator accepted them. Open a small sample of stops — at least five, ideally more — and plot their lat/lon coordinates on Google Maps. Confirm they are exactly where they should be, not offset by a decimal place error or assigned to the wrong street. A stop that is 100 metres out of position will send riders to the wrong location.
Tools you can use: paste the lat,lon into Google Maps' search bar, or import your stops.txt into Google My Maps to see all stops on a map at once.
Pick one of your routes and trace a specific trip through stop_times.txt manually. Find all the rows that share a single trip_id and verify:
stop_sequence values increase)stop_id in the sequence exists in stops.txtservice_id in calendar.txt)Do this for at least one trip in each direction for each route.
Open calendar.txt and verify:
start_date is in the past or today (not a future date, which would mean routes show no service until then)end_date is at least six months in the futureIf you have calendar_dates.txt, check that exception dates are correct and have not been duplicated or set to wrong dates.
Open routes.txt and count the number of routes. Does it match how many routes your agency actually operates? Open trips.txt and spot-check that the number of trips per route is roughly what you would expect. An unexpectedly low number might indicate rows were accidentally deleted. An unexpectedly high number might indicate rows were duplicated.
Use a visual GTFS feed viewer to render your routes and stops on a map and display your timetables. AddTransit provides a live preview of your routes and timetables within the platform as you build — so you can spot problems before you even export your feed.
Look for any routes that appear in the wrong place on the map, any stops that are clearly mis-positioned, and any timetables that look unusual. These visual checks catch errors that the technical validator misses.
Open your ZIP and check that all GTFS text files are in the root of the archive — not inside a sub-folder. Some operating systems create sub-folders automatically when zipping. A feed where files are in a sub-folder will be rejected by Google Maps even though the files themselves are valid.
Once you upload your feed to a hosting URL, paste that URL into a browser in incognito mode (to confirm you are not using a logged-in session) and verify the feed downloads correctly. Then paste the URL into an online accessibility checker to confirm it works from outside your network. AddTransit handles hosting automatically and provides a URL that is guaranteed to be publicly accessible.
Before publishing, ask someone familiar with your service to review the rendered timetables and routes. They will often spot errors — a wrong stop name, a missing departure time, a route shown running on the wrong days — that you have overlooked because you have been looking at the data too closely. Fresh eyes catch what familiarity hides.
After your feed goes live on Google Maps or another platform, do a final verification on the live platform itself:
If you find discrepancies after the feed goes live, check your source data first, fix and re-publish, then allow 24–72 hours for the platforms to update. See our guide on how to fix common GTFS errors if you need help troubleshooting.
