Creating Area Pages for Bali Handbook (SEO + Web Design) - Day 22
Good morning! So I'm back after a few days offline - we had some internet issues here in Bali, plus it was Nyepi (silent day), so I had to break my 60-day upload streak. But honestly? Sometimes these forced breaks are exactly what you need to come back with fresh eyes.
Quick summary
Today I'm tackling area pages for the Bali Handbook - you know, those location-specific pages that help people discover what to do in places like Ubud or Canggu. Sounds simple, right? Well, it turns out creating a proper admin interface, connecting multiple database tables, and dealing with Google Maps integration is... let's just say it's more complex than I initially thought.
Why location pages matter for a travel directory
Here's the thing - when people plan trips to Bali, they don't just search for "hotels in Bali." They search for "things to do in Ubud" or "best restaurants in Canggu." These location-specific pages are absolute gold for SEO because they target exactly how people actually search.
Plus, from a user experience perspective, it makes total sense. If I'm staying in Ubud, I want to know what's popular in Ubud specifically, not scroll through everything across the entire island.
The challenge I was facing
So we already had a locations table in our database with basic info - coordinates, descriptions, that sort of thing. But I realized we needed way more content for proper area pages. We're talking highlights, travel tips, things to do, best time to visit, hero images... basically everything that makes a location page actually useful.
The question was: do I stuff all this extra content into the existing locations table, or create a separate table?
What I tried first (spoiler: it got messy)
Initially, I thought "eh, let's just add more columns to the locations table." But then I started thinking about all the rich text content, multiple images, SEO meta descriptions... that table was going to become a monster.
Living here in Bali, I've learned that sometimes the simple solution isn't actually the right solution. You need to think a few steps ahead.
The breakthrough moment
I decided to use Claude Sonnet (honestly, it's become my go-to for mapping out database structures) and asked it to help me think through this properly. The solution was actually pretty elegant: keep the locations table for basic geographical data, but create a separate location_details table for all the rich content.
This way, I can have locations without detailed content pages, and I can manage the content separately. Much cleaner.
Here's how I actually built it
Step 1: Creating the new database structure
First, I needed to create that location_details table. Here's what I included:
ID (linked to the main locations table)
Highlights (rich text)
Travel tips (rich text)
Things to do (rich text)
Best time to visit
Hero image
Gallery images
Meta title and description for SEO
The cool thing about using a rich text editor (we're using TipTap) is that content creators can format everything nicely without touching code.
Step 2: Building the admin interface
This is where things got interesting. I needed an admin dashboard where we could manage all these location pages. The interface needed to:
List all locations
Allow editing of rich text content
Handle image uploads
Connect everything to the right database tables
I'm using Cursor AI for most of the coding, and I've got to say - when you give it a clear structure and reference existing components, it does pretty solid work.
Step 3: Creating the public-facing pages
Now for the fun part - the actual pages people will see. I wanted two types:
Category page: Shows all locations in a nice grid
Single location pages: Detailed pages for each area
For the single pages, I'm reusing components from our accommodation pages - same hero structure, same styling patterns. Why reinvent the wheel?
The stuff that went wrong
Oh man, the Google Maps integration. This has been haunting me for weeks now.
I keep getting billing issues with the Google Maps API, even though I've set it up properly. The maps just won't load, and I get these cryptic error messages. It's honestly frustrating because maps are pretty important for a travel directory.
I think the issue might be with how I'm calling the API or maybe some configuration I missed. If anyone watching has dealt with this before, seriously, let me know in the comments.
How I'm fixing the problems
For now, I'm moving forward with placeholder content and focusing on getting the structure right. The maps will work eventually - I just need to sit down and properly debug the API setup.
What I did do is make sure the image upload system works properly. I created a new storage bucket specifically for location images, set up the proper permissions, and connected it all to the admin interface.
What it looks like now
So we've got the basic structure working. When you go to a location page like /locations/ubud, you see:
Hero section with a beautiful image
Rich description
Highlights section
Travel tips
Things to do
Popular accommodations in that area
Popular dining options
The admin interface lets us manage all this content easily, and everything's connected to the database properly.
Lessons I'm taking from this
Database design matters: Taking time to think through the structure upfront saves hours later
Reuse components: Don't build everything from scratch - reference what already works
API integrations are tricky: Sometimes the simple stuff (like maps) becomes the biggest headache
Content structure is key: Think about how people actually consume travel information
You know what's funny? I used to think building a travel directory was mostly about collecting listings. But it's really about creating useful, structured content that helps people make decisions.
What I'm working on next
Next episode, I need to:
Fix those damn Google Maps (seriously, this is driving me crazy)
Add proper image galleries to location pages
Connect the featured listings functionality
Start doing keyword research for each location
I'm also going to ask Grace to start adding real content for the locations we've actually visited. We've been to most of these places, so we can write authentic, helpful content instead of generic travel guide stuff.
Final thoughts
We're getting close to launch, and I'm honestly excited to see if this thing will actually rank in Google. The structure feels solid, and we're building something that's genuinely useful for people planning Bali trips.
Building in public like this has taught me so much about staying focused and actually shipping things. Sure, I broke my upload streak, but sometimes life happens - especially when you're building from a tropical island with occasional internet issues.
Following along with the 60-day challenge? I'm documenting everything as I build this travel directory from scratch. Subscribe if you want to see how this experiment turns out - the good, the bad, and the Google Maps API failures.