Choose a frontend framework that renders crawlable content without a separate SEO-focused rebuild.
Trade-off: less framework flexibility than a fully client-rendered app.Engineering note · 03 Product & SEO
Building search discoverability
into the architecture, not after it.
How India Hidden Gems' SEO requirements shaped rendering, URL structure, and content modeling from day one—rather than being retrofitted after launch.
Topic
Product & SEO · Search-friendly architecture
Grounded in
The India Hidden Gems platform build
The problem 01
A social audience doesn't show up in search results.
India Hidden Gems had built a large social audience—roughly 325K Instagram followers, 130K Facebook followers, and 70K YouTube subscribers—but none of that showed up when someone searched for a specific destination or experience. Social platforms are closed gardens for search engines; content posted there isn't indexed the way a web page is.
Moving the business onto its own platform was only useful if that platform could actually be found by organic search, not just by people who already followed the brand. That meant SEO couldn't be a marketing checklist applied after development—it had to shape decisions about rendering, URLs, content modeling, and metadata from the start.
The architecture decisions 02
Next.js rendering→Semantic content→Metadata & sitemaps→Organic search
Let the framework's rendering choice do the SEO work.
Next.js was chosen partly because it gave the customer-facing experience SEO-friendly rendering by default—pages could be crawled and indexed without a separate effort to make content visible to search engines. Trip and experience pages were built around descriptive, search-friendly URL and page structures instead of generic identifiers.
Content structures were designed around what people actually search for—destinations, experiences, and travel intents—rather than around whatever was most convenient for internal data modeling.
Next.jsSemantic HTMLCanonical URLsXML sitemaprobots.txtImage metadata
Key decisions 03
Model trip and experience pages around what people search for, not just internal data convenience.
Trade-off: content modeling required more upfront thought than a generic CMS schema.Ship XML sitemap generation and robots.txt configuration with the first release rather than adding them later.
Trade-off: a small addition to initial scope, but it closed a discoverability gap at launch.Link related travel content and experiences to each other so crawlers—and visitors—could discover related pages.
Trade-off: needed a content structure that supported it, not just ad hoc links.What changed 04
A platform search engines can actually find.
- Search-friendly URL and page structures shipped with the first release
- Dynamic metadata for trips and experiences, not static boilerplate
- XML sitemap and robots.txt in place from launch
- Canonical URL handling to avoid duplicate-content issues
- Internal linking connecting related travel content
Lessons 05
SEO is a rendering and content-modeling decision, not a plugin.
A framework's default rendering behavior matters more than any later optimization pass.
Model content around search intent, not internal convenience.
Sitemaps and robots.txt are cheap to ship early and costly to retrofit.
A large social audience doesn't substitute for being found in search.
Building something that needs to be found? 06
Let's design for
discovery from day one.
If a product's audience needs to find it through search, not just social or referral, I'd be glad to talk through how the architecture should support that.
Start a conversation ↗