Most county election offices already export a precinct file from their election management system every cycle. SleekRank reads that CSV directly. Some offices keep a parallel Google Sheet for editorial fields like accessibility notes and language support, joined to the export by precinct number.

Each row carries a ballotStyle identifier and an array of contests that appear on that style. List mapping renders the contest list, and selector mapping injects the ballot-style code into the hero section so voters can verify they are on the right page.

Yes. Store coordinate or boundary data per row and the template embeds a Leaflet or Google Maps view centered on the precinct. The polling-site marker comes from the address field, geocoded once during the cache refresh.

Standard accessibility fields cover ramps, parking, restrooms, voting-aid devices, and language support. The template renders an Accessibility section per page so a voter or advocate can see at a glance what the site provides without calling the clerk.

Yes. The URL is anchored to the precinct, not the election. After certification, the cache version increments and the contest list rolls forward to the next election, while a small archive section links to past-cycle pages for transparency and history.

Yes. SleekRank registers every generated URL with the sitemap and noindexes the base template page so only precinct URLs get crawled. New precincts added after redistricting appear in the sitemap on the next cache refresh.

After redistricting, some precincts split or merge. Keep retired slugs published with a notice and a link to the new precinct page, or 301 redirect them. The source file should carry both legacy and current precinct numbers during the transition window.

Yes. Build sibling page groups at /wards/{slug}/ and /districts/{slug}/ that read aggregations of the same precinct file. Internal links between precinct, ward, and district pages compound topical authority for the entire election section.