Adding FAQ Schema for Better Google Visibility | Learning In Public Day 20
So here's something I've been excited to share with you - I just added FAQ sections to my Bali travel directory, and honestly, the process taught me way more about database design than I expected.
Quick summary
I wanted to add FAQ sections to my listing pages (stays and dining spots) with proper schema markup so they could potentially show up in Google search results. What started as a simple feature addition turned into a fascinating deep dive into database architecture decisions. Plus, I got to test out Cursor AI's planning abilities, which was pretty cool.
Why I'm obsessing over FAQ schema right now
You know what's wild about FAQ schema? When you mark up your frequently asked questions properly, Google can actually display them directly in search results. I'm talking about those expandable question-and-answer sections you sometimes see when you search for something.
Living here in Bali and building this travel directory, I realized that people searching for accommodations or restaurants probably have tons of questions. "Do they have wifi?" "Is it family-friendly?" "What's the cancellation policy?" If I can get those answers to show up right in Google search results, that's potentially huge for getting more visitors to my site.
The challenge I was facing
So basically what happened was this: I had my single listing pages for stays and dining spots, but they felt incomplete. I wanted to add FAQ sections at the bottom of each page, but I had no idea how to structure this in my database.
The tricky part wasn't just adding the FAQs - it was figuring out the best way to store them. Should I add FAQ columns to each category table? Create one master FAQ table? Add it to the main listings table as an array? I honestly had no clue what would be the most maintainable approach.
What I tried first (and why I asked AI for help)
Here's where it gets interesting - instead of just diving in and potentially making a mess, I decided to ask Cursor AI to help me think through the database design first. I'm not gonna lie, this felt a bit weird at first because I usually just start coding and figure it out as I go.
I explained my situation: "I have listings separated by category (dining, stays, beach clubs, etc.), and I want to add FAQs that will work with schema markup. What's the best database approach?"
The breakthrough moment with AI planning
This probably sounds weird, but watching Cursor think through the problem was actually fascinating. It considered three main approaches:
Separate FAQ columns for each category table - Easy but repetitive
FAQ array in the main listings table - Simple but not very flexible
Dedicated FAQ table with relationships - More complex but super flexible
The AI recommended option 3, and honestly, it made perfect sense. A dedicated faqs table with content_type and content_id fields means I can use the same structure for listing FAQs, category page FAQs, homepage FAQs - basically anything.
Here's how I actually built it
Step 1: Database design that actually makes sense
First, I created the FAQ table in Supabase. The structure is pretty clean:
CREATE TABLE faqs (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
question TEXT NOT NULL,
answer TEXT NOT NULL,
content_type TEXT NOT NULL,
content_id UUID NOT NULL,
is_user_submitted BOOLEAN DEFAULT false,
submitter_name TEXT,
created_at TIMESTAMP DEFAULT now()
);The genius part (well, Cursor's genius) is the content_type and content_id combo. For a stay listing, content_type would be "listing" and content_id would be the listing's UUID. Super flexible for future expansion.
Step 2: Row level security setup
Since I'm using Supabase, I needed to set up proper row level security. The policy allows authenticated users (admins) to manage FAQs while keeping everything secure:
CREATE POLICY "Admins can manage FAQs" ON faqs
FOR ALL USING (
EXISTS (
SELECT 1 FROM profiles
WHERE profiles.id = auth.uid()
AND profiles.role = 'admin'
)
);Step 3: Admin dashboard integration
This is where things got really smooth. I added FAQ management to both my stays and dining forms in the admin dashboard. Users can add multiple question-answer pairs, and they get saved with the proper content type and ID relationships.
The form is pretty straightforward - just dynamic input fields where you can add/remove FAQ pairs as needed.
Step 4: Frontend display with schema markup
On the actual listing pages, I added an FAQ accordion section at the bottom. But here's the important part - each FAQ section includes proper JSON-LD schema markup:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Question text here",
"acceptedAnswer": {
"@type": "Answer",
"text": "Answer text here"
}
}
]
}This tells Google exactly what these sections are and makes them eligible for rich search results.
The stuff that went wrong
Okay, so not everything went perfectly. I ran into a few issues:
Duplicate forms: Cursor accidentally created duplicate dining forms, which was confusing until I caught it. Always double-check AI-generated code, folks.
Image upload bug: I discovered that vertical images aren't displaying properly on my listing pages. That's a separate issue I need to fix, but it reminded me that testing in production (I actually visited one of the places listed) reveals problems you miss in development.
Database relationships: Initially, I wasn't sure how the content_id was linking back to listings. Turns out it's just using the listing's UUID, which makes perfect sense but took me a minute to confirm in the database.
How I fixed the problems
The duplicate form issue was easy - just deleted the extra code. The image display problem is still on my todo list, but at least I know about it now.
For the database relationships, I just queried the actual data to see how everything connected. Sometimes the best debugging tool is just looking at what's actually stored.
What it looks like now
The FAQ sections are working really well. I can add questions and answers through the admin dashboard, and they display nicely in an accordion format on the listing pages. More importantly, each page now has proper FAQ schema markup that Google can understand.
I tested it with a few sample FAQs, and the data is storing correctly with the right relationships. The next step is to start adding real FAQs for actual listings and see if Google picks them up in search results.
Lessons I'm taking from this
AI planning is actually useful: Having Cursor think through the database design before coding saved me from making a mess I'd have to clean up later
Flexible database design pays off: The content_type/content_id approach means I can easily add FAQs to category pages, the homepage, or anywhere else
Schema markup matters: It's not just about having FAQs - marking them up properly for search engines is crucial
Test in production: Visiting the actual places I'm listing revealed issues I never would have caught otherwise
What I'm working on next
I want to add FAQ sections to category pages too - like having FAQs about staying in Canggu or dining in Seminyak. With the database structure I built, this should be pretty straightforward.
I'm also curious to see how long it takes for Google to start recognizing the schema markup. I'll probably do a follow-up post about that once I have some data.
Final thoughts
This whole experience reminded me why I love building in public. What started as a simple feature request turned into a lesson about database design, AI-assisted development, and the importance of thinking through architecture decisions.
The FAQ schema markup might seem like a small addition, but if it helps people find the information they need directly in search results, that's a win for both users and my site's visibility.
Following along with my 60-day challenge? I'm sharing every step of building this Bali travel directory - the wins, the mistakes, and everything in between. What features would you want to see next?