From GTFS stop_times for a representative trip in each direction. The ETL step picks the longest trip on the route in each direction as the canonical stop sequence, with stop names and accessibility flags. SleekRank renders both lists side by side on the route page.

Most bus routes have a few branch variants (express, limited, late-night). Either render the most common variant as the canonical stop list and link to variants on supplemental pages, or model variants as separate routes in the source endpoint. The second approach generates more pages and captures more variant-specific queries.

GTFS marks timepoint stops with a timepoint=1 flag in stop_times. Render timepoints in a heavier weight or with a clock icon in the list mapping, so riders can quickly find the schedule landmarks without losing the full stop sequence.

Yes, via a client-side widget that fetches GTFS-RT predictions from the agency's endpoint on page load. The widget overlays the static stop list with next-arrival times for each stop. SleekRank renders the reference; the widget handles the live data.

Either fetch GTFS-RT alerts at cache time and attach the route_id list to each affected route record, or maintain alerts in a separate sheet keyed by route. The base template's banner block renders only when the alerts array is non-empty.

Add a transfers array column listing the routes that intersect or connect at major stops, with the connecting stop name and route badge. List mappings render the transfers as a compact grid; this content captures heavy transfer-related search demand.

Yes. Some agencies group routes into corridors (Geary corridor, Mission corridor). Run a second page group at the corridor level with each corridor page listing the routes that serve it. Cross-link from route pages to their parent corridor.

Yes. Bus rapid transit routes are still route_type=3 in GTFS (or sometimes 700-series), and the schema is identical. Render a BRT badge on those routes via a selector mapping driven by a brt_flag column on the route record.