Making Open Transit Data Visible, Part 2: The Results

Introduction

Six months ago, at MobilityData we updated the Mobility Database React application to Next.js for better search engine visibility. Our vision to provide open and discoverable data was the engine for this decision. We’ve written previously about the migration, and in this article we’ll discuss the results, the SEO gains, the AI learnings, and the new dev experience

SEO and Traffic Gains

At the core of this migration, we wanted to gain a stronger presence on search engines like Google search for more traffic and brand awareness. Before the migration we had roughly 300 pages that were poorly indexed and not being ranked on Google. Six months after the migration, we have 8.1k pages that are properly indexed. This is a 27x increase in pages indexed. These were pages that always existed and were never crawled properly. This led to an increase of 200% traffic into our website through organic search comparing September 2025 to September 2026.

Another important point is that we are now being indexed on non-branded search queries such as “gtfs data”, the image below shows the difference in search result for the query “gtfs data” this year compared to the previous one

Source: Google Analytics. Comparison of non-branded query “gtfs data” 28 day period to 1 year ago

Last year before the migration, we were effectively not ranked for this relevant query, and now we rank well on it, creating awareness e of the service we provide and the availability of high quality transit data.

AI indexability and traffic coming from AI

With the rise of LLMs, we wanted to make sure our data was properly indexed by these systems so that people using these systems would have access to the best transit data available. And, it worked.

Source: Google Analytics. AI Assistant traffic data from from year to date

This graph is a little misleading as Google only started tracking AI Assistant traffic in May 2026, but as we can see, it’s trending upwards. We can assume the migration greatly assisted in this, as AI crawlers do not accept pages that require javascript, and that’s what the application was before the migration.

We can see an example of this from asking an LLM a question very specific to the type of data the Mobility Database produces:

Source: ChatGPT 5.5. LLM sourcing the Mobility Database in a concise manner

One discovery to note is that our AI traffic is still relatively low in comparison to the rest of traffic, at only 4% of total traffic coming in. We expect this number to grow as LLMs become more adopted, which makes this a great future proofing step.

Another great and unexpected result was that our catalog is being used as ground truth in generated answers, and cited at the level of individual fields in Google search in the AI Overview

Source: Google. AI overview highlighting key data from the Mobility Database

Because our data was indexed properly and was found to be high quality, Google was able to parse it and display key information right away for queries such as “brasilia gbfs data”

Application Performance

The biggest performance gains were from static and ISR (Incremental Static Regeneration) pages. Because of the removal of PersistGate, pages no longer had to wait on redux-persist rehydration, they could be pre-rendered at build time. Paired with Vercel's caching on its CDN, these pages load just about instantly. This is a huge improvement as the landing page, which is the most visited page, now loads very fast through a CDN.

Our key content pages are the feed detail pages (example). These are the pages we want indexed as they contain key information regarding transit data for a feed. Since there are 6000+ feeds that change independently of build time, we went with an ISR strategy to assure better feed freshness. This, paired with a solid revalidation strategy, worked out very well, not only for performance, but for server costs. This caching of key pages was not possible before. In our data pipeline, when we detect a change in feed data, we also trigger a revalidation of that associated feed page. This led to an overall ~95% ISR cache read.

Source: Vercel. 24 hour timelapse of feed detail page non-authenticated cache hits

A caveat is that this caching does not work for authenticated users as their experience has to be unique in the data displayed. The good news is that since most users and all bots are unauthenticated, we get very high value out of this caching

Infrastructure - Vercel

After using a Vercel Pro plan for roughly 4 months we are quite pleased with it, but found some setbacks.

What We Liked

• The preview urls per branch commit has been great for users to test PRs but also for deploying test branches
• Easy to understand logs, billing usage, caching graphs, setting environment variables, monitoring deployments and promoting to production
• Integrated very easily into our pipeline with no complicated configuration files

What We Didn’t Like (Pro plan, as of September 2026)

• Pro includes one custom environment beyond production and preview. We wanted three (prod, staging, and a stable dev), which meant moving up a tier or working around it.
• Several things we assumed were included were actually metered add-ons: Web Analytics, Speed Insights, and Observability Plus. Without Observability Plus, we were limited to a 24-hour log retention window, which is tight when you're diagnosing a traffic spike that started yesterday.

These cons aren’t deal breakers but they definitely dampen the Vercel experience.

Cost

• We expected Vercel to cost 75$ - 100$ per month, but due to our use of caching, it’s been closer to 40$ - 50$ per month. This includes 2 paid seats.

Overall, we are currently happy with our choice to go with Vercel. It provides a lot of features out of the box, which speeds up development for a small team. We are going to monitor the cost as our application scales, but as long as we are conscious about caching, our bill should be manageable.

Developer Experience

We’ve spoken a lot about the SEO and performance gains we got from migrating to Next.js and having a SSR application, but there is one cost: increased dev complexity.

In the traditional React application, managing the state of data is relatively straightforward: all data is accessed client side and typically managed through a library like Redux. It is typically more acceptable to wait for the data before showing content, maybe throwing a loading state while waiting. This made development and data access more straightforward at the sacrifice of the user experience.

Next.js gives developers more tools to give a better user experience. For example, one of the most visited pages on the Mobility Database is the home page. The content on the home page is static and doesn’t change at all. In a traditional React application, the main <App> element typically waits on data to load, whether that's user data or waiting for Redux to initialize. With Next.js, since the landing page is static, we can load it using SSG and serve it using a CDN which is near instant response.

The complexity of working with SSG is that certain data that comes from the root layout (ex: global feature flags) will be compiled at build time. Now we have to think in terms of trade-offs: near instant presenting home page vs how often feature flags update. We could use a revalidating strategy, and we can get the best of both worlds. This is just an example of how passing root data in a Next.js application requires more thought and care than a traditional React application.

Our Next Steps For Visibility

• Automate the process of updating the sitemap. We noticed that when we updated the sitemap manually, it is well received by bots, leading to an increase in indexed pages as well as richer results
• Improve the metadata of certain pages to include more relevant keywords. This will help users to find transit data most relevant to their needs

Conclusion

Six months in, the migration met its objective. Indexed pages went from roughly 300 to 8.1k, organic search traffic is up 200%, and we now rank on non-branded queries like "gtfs data" where we previously didn't appear at all. We also picked up something we hadn't planned for: our feed pages are being cited by LLM assistants and surfaced in Google's AI Overviews, which is a channel we expect to matter more over time than its current 4% of sessions suggest. The performance gains were real, and cheaper than we budgeted for.

Worth it, for one reason: open data that can't be found isn't really open. A catalog that only surfaces for people who already know our name serves the agencies and developers who need it least.

About MobilityData

MobilityData is a global non-profit maintaining the development of open data standards that power transit and shared mobility apps worldwide. We support specs like GTFS and GBFS, working with agencies, companies, and developers to make mobility data more usable and consistent.