How I Built a Smart WordPress Geolocation System for City Cave Australia
Most WordPress projects start from scratch. This one was different. City Cave Australia — one of the country's fastest-growing float therapy franchises — already had 70+ locations built, Elementor templates ready, and If So audiences fully configured. What they were missing was the intelligence layer that made it all automatic. Visitors still had to manually pick their nearest centre from a dropdown — a friction point costing conversions every single day.
Joe reached out needing a WordPress geolocation expert to detect the visitor's nearest centre automatically, serve the right Elementor content instantly, and respect the existing setup without breaking a single thing.
The Challenge: Precise Geolocation Across 70+ Centres
Centres Less Than 1km Apart
City Cave has multiple locations in close proximity in major cities — Aspley, Everton Park, Clayfield, Paddington, Newstead, and Bulimba are all within Brisbane, some less than 1km apart. Standard IP-based geolocation is accurate to a suburb at best. Joe was explicit: "Device-based location is required because some centres are less than 1km apart and IP isn't accurate enough."
What Was Already Built (And Must Not Break)
- 70+ If So audiences — one per centre
- Conditional content triggers controlling booking links, maps, and package buttons
- Elementor templates already built and mapped per location
- Working URL parameter system (?ifso=bulimba) triggering correct audiences
- Header dropdown listing all centres by state
Replacing any of this was never an option. The brief was clear: build on top of what exists, not replace it.
The Five Core Requirements
- HTML5 device-based geolocation as the primary detection method
- Strict 10km distance rule — nearest centre within range or show default content
- Auto-assign the correct If So audience without page reload
- Manual dropdown override with persistent preference across all visits
- Clean fallback for denied permissions, GPS errors, and no nearby centre
The Solution: A Geolocation Engine Built On What Already Works
After reviewing the backend with admin access, the approach was clear: build a standalone JavaScript geolocation engine that plugs into the existing If So URL parameter system. No migration. No rebuilding. Zero risk to 70+ existing configurations.
HTML5 Geolocation as Primary Method
The browser prompts the visitor to share their location using the navigator.geolocation.getCurrentPosition() API — GPS-level accuracy on mobile, WiFi-triangulation on desktop. Precise enough to distinguish centres one kilometre apart, unlike any IP-based approach. This is part of my custom WordPress development services at CodeSyte.
Nearest Centre Calculation with the Haversine Formula
Once coordinates are retrieved, the system calculates distance from the visitor to all 70+ centres using the Haversine formula — the standard method for shortest distance between two points on Earth. If the nearest centre is within 10km, it is selected. If not, the visitor sees default content and a Find Your Location CTA.
Plugging Into the Existing If So System
Rather than replace If So, the geolocation engine simply fires the URL parameter If So already listens for. Nearest centre identified as Bulimba? The engine appends ?ifso=bulimba. If So assigns the audience, triggers fire, and the correct Elementor template loads — exactly as before. Zero changes to 70+ existing configurations. Purely additive.
Manual Override and Persistent Preference
When a visitor selects their centre manually via the dropdown, that choice is saved to localStorage. On all return visits, their preference loads instantly — no prompt, no delay. Preference persists until the user changes it themselves. I build this kind of intelligent personalisation as part of my WordPress website development services.
Fallback for Every Edge Case
- Permission Denied — Default content + store locator CTA shown immediately
- Location Unavailable — Same default fallback, dropdown still works
- Timeout — Graceful fallback, no infinite loader
- No Centre Within 10km — Default content + Find Your Location prompt
Cross-Browser Testing
Tested and validated across Chrome (Android and Desktop), Safari (iOS and macOS), Firefox, and Edge — covering all geolocation prompts, fallback states, localStorage behaviour, and If So triggers.
The Result: A Self-Managing Location Experience
A visitor in Bulimba, Brisbane opens the page. They allow location access. In under two seconds, they see their nearest City Cave — correct booking link, correct map, correct packages. They never touched the dropdown.
A return visitor comes back a week later. No prompt. Preference remembered. Content loads instantly.
A visitor in rural Queensland opens the page. No centre within 10km. Default content, a clear prompt, store locator link. No confusion. No broken experience.
What Was Delivered
- HTML5 geolocation with GPS-level centre detection
- 70+ centre database with lat/lng coordinates integrated
- Haversine distance engine with configurable 10km radius rule
- If So audience assignment via existing URL parameter — zero config changes
- localStorage preference persistence across all sessions
- Manual dropdown override fully connected
- Four-state fallback system for all error scenarios
- Full cross-browser and cross-device testing
- Complete maintenance documentation for the City Cave team
Services Used on This Project
- Custom WordPress Development — JavaScript geolocation engine, AJAX integration, custom logic layer
- Elementor Expert Development — Template-to-audience mapping within the existing Elementor and If So setup
- WordPress Plugin Integration — Extending If So with custom logic rather than replacing a working system
- WordPress Performance Optimisation — Async script execution, localStorage-first logic for zero delay on return visits
- WordPress Website Design and Development — Scalable multi-location architecture built to grow with new centres
Key Lessons From This Project
1. Understand the Existing System Before Writing a Line of Code
Auditing the If So setup before proposing anything saved weeks of unnecessary migration work and avoided introducing risk into a functioning system.
2. IP Geolocation Is Not Good Enough for Dense Multi-Location Businesses
If your locations are within a few kilometres of each other, IP detection will fail regularly. HTML5 device-based geolocation is the only approach that delivers the precision needed.
3. Persistence Matters as Much as Detection
Detecting the right location once is only half the job. localStorage persistence — loading the saved centre instantly on every return visit — is what makes the system feel seamless rather than repetitive.
4. Cost-Effectiveness Means Knowing What Not to Build
The value here was not how much code was written — it was what the code protected. Preserving 70+ existing configurations and delivering a tested, documented, non-destructive integration is where the real value lives.
Final Thoughts
City Cave did not need a rebuild. They needed an intelligent layer on top of something that already worked. The geolocation engine is clean, non-destructive, and built to scale. Adding a new centre takes minutes. The logic handles the rest.
If you are running a multi-location WordPress website and need dynamic content that responds to where your visitors actually are — not where their ISP thinks they are — that is exactly the kind of problem I solve at CodeSyte.