The Commit That Changed Everything
February 3rd, 2026. I get a message from the church: "We're moving to Calle Francisco Aritio, 107 (Dinoaventura)".
It could have been a simple database change. Update the address and done.
But we were building the website for Comunidad Cristiana de Guadalajara (CCG), and there was a more interesting opportunity hidden there.
The physical location change was the perfect excuse to build a local SEO system from scratch.
And here's what I actually spent the next 6 days implementing.
Why Venue Changes Are SEO Opportunities (Not Just Problems)
Most businesses see a location change as something that breaks their SEO. And they're right... if they only update the address and wait for Google to notice.
But a venue change forces you to do what you should have done from the beginning:
→ Review all your metadata (because you have to change it anyway) → Implement structured data correctly (because Google needs to understand the new location) → Communicate the change visibly (banner, dedicated pages, updated content) → Revalidate all your pages (so the change propagates quickly)
In our case, CCG is an evangelical church in Guadalajara, Spain. The move from Calle Padilla to Calle Francisco Aritio wasn't just logistical.
It was a local positioning opportunity that many businesses waste.
What I Built: Dynamic Location System with Next.js
Here's the real architecture I implemented between February 3rd and 9th:
1. Location Change Banner (Component-First)
First, I needed to communicate the change visibly and quickly. Not just in the footer.
```typescript // Commit: feat(ui): agregar banner de cambio de local (6464d75) // Date: February 9th, 2026
<LocationChangeBanner oldLocation="Calle Padilla" newLocation="Calle Francisco Aritio, 107 (Dinoaventura)" effectiveDate="2026-02-03" mapLink="https://maps.google.com/..." /> ```
The banner appears on all main pages. It's not invasive, but it's impossible to ignore.
Why it works:
- Users don't get lost searching for the old venue
- Google indexes the change quickly (visible content = strong signal)
- You can track map clicks as conversions
2. Structured Local Metadata (Schema.org + Open Graph)
Then, I updated all metadata so Google, WhatsApp and social networks understand the new location:
```typescript // layout.tsx - Next.js Metadata export const metadata: Metadata = { title: 'Comunidad Cristiana de Guadalajara - CCG', description: 'Evangelical church in Guadalajara. Services at Calle Francisco Aritio, 107.', openGraph: { locale: 'es_ES', type: 'website', siteName: 'CCG Guadalajara', }, keywords: [ 'church Guadalajara', 'christian community Guadalajara', 'services Guadalajara', 'Calle Francisco Aritio', 'Dinoaventura' ], } ```
Here's the trick: I didn't just change the address. I added the neighborhood name (Dinoaventura) as an additional keyword.
Why? Because people search "church near Dinoaventura" before searching by specific street.
3. Location Schema in Events (Structured Data)
CCG has an event management system with Sanity CMS. Each event (services, conferences, retreats) has location data:
```typescript // schemas/evento.ts export default { name: 'evento', type: 'document', fields: [ { name: 'location', title: 'Location', type: 'object', fields: [ { name: 'name', type: 'string', title: 'Place name' }, { name: 'address', type: 'string', title: 'Address' }, { name: 'city', type: 'string', title: 'City' }, { name: 'mapUrl', type: 'url', title: 'Google Maps link' } ] } ] } ```
When a pastor creates an event in Sanity Studio, the system automatically generates structured data:
```json { "@type": "Event", "location": { "@type": "Place", "name": "CCG Guadalajara", "address": { "@type": "PostalAddress", "streetAddress": "Calle Francisco Aritio, 107", "addressLocality": "Guadalajara", "addressCountry": "ES" } } } ```
Google sees this and understands: "This religious event happens at this physical location in Guadalajara, Spain".
4. Webhook Revalidation (Instant Changes)
Here's where it gets technical.
When you update the address in Sanity CMS, you need the change to appear immediately in production. Not in 24 hours. Not in the next build.
Right now.
For that, I built a webhook system that invalidates Next.js cache:
```typescript // app/api/revalidate/route.ts export async function POST(request: Request) { const body = await request.json() const documentType = body._type
// Granular revalidation by document type const pathsToRevalidate = { 'evento': ['/eventos', '/'], 'sermon': ['/predicas'], 'testimonio': ['/'], 'ministerio': ['/ministerios'], 'configuracion': ['/'] // Includes global location data }
const paths = pathsToRevalidate[documentType] || ['/']
for (const path of paths) { await revalidatePath(path) }
return Response.json({ revalidated: true, paths }) } ```
When I changed the address in the configuration schema, the webhook triggered a revalidation of all affected pages.
Result: The change appeared on Google in less than 2 hours.
Local SEO Lessons You Only Learn By Building
After implementing all this, here's what really matters:
1. Neighborhoods > Streets For Searches
People don't search "church Calle Francisco Aritio".
They search "church Dinoaventura Guadalajara" or "church north zone Guadalajara".
Action: Add the neighborhood/zone name as a secondary keyword in your metadata.
2. Update Speed Matters More Than You Think
Google crawls religious and local organization sites less frequently than e-commerce.
If you change your location and wait for Google to discover it in the next crawl... you could wait weeks.
Action: Use active revalidation (webhooks + sitemap ping) to force re-crawl.
3. Visual Communication > Invisible Metadata
The location change banner got more map clicks than the footer with the address.
Why: People ignore footers. But a yellow banner saying "We moved" is impossible to miss.
Action: Make important changes visible, not just technically correct.
4. Schema.org For Local Events Is An Unfair Advantage
Many churches and local organizations don't use structured data.
If you implement it correctly, Google can show your events directly in search results.
Not just your website. Your events.
The Real Tech Stack (If You Want To Replicate It)
Here's what I used:
- **Next.js 16 (App Router)** - ISR + webhook revalidation
- **Sanity CMS** - Flexible schema for location data in events
- **TypeScript strict mode** - Because location changes can't have typos
- **Tailwind CSS v4** - Fast responsive banner component
- **Vercel** - Automatic deploy + edge functions for webhooks
Repo: The project is on GitHub as `ccl-guadalajara` (last updated February 9th, 2026).
What I'd Do Differently Next Time
1. Implement map click tracking from day 1 2. A/B test banner text ("We moved" vs "New location") 3. Create a dedicated page `/nueva-ubicacion` with more context and photos 4. Automatic notification to Google My Business (haven't connected it yet)
Takeaway: Location Changes Are Opportunities, Not Just Problems
If your business, church or organization changes location, don't see it as an SEO headache.
It's the perfect excuse to:
✓ Review all your metadata ✓ Implement structured data correctly ✓ Build fast revalidation systems ✓ Communicate changes visibly ✓ Learn local SEO by doing, not reading
In CCG's case, the move from Calle Padilla to Calle Francisco Aritio forced us to build infrastructure that should have existed from the beginning.
And now we have a system that can handle any future change in seconds, not days.
Did your business recently relocate? How did you handle local SEO?
