Claude Code can speed up building a set of city × course landing pages for a bootcamp or edtech brand, think "Full-Stack Development Bootcamp in Bangalore" or "Data Science Bootcamp in Delhi", but only if you feed it real, city-specific inputs and use it to assemble structured content rather than spin out templated filler. This walkthrough covers the practical setup, and where the line between "programmatic" and "thin" actually sits.
Programmatic SEO gets a bad reputation because most implementations are lazy: swap a city name into an identical template, publish 200 pages, watch Google eventually notice they're near-duplicates and suppress or deindex them. That risk is real. But the underlying idea, that a bootcamp with a genuine multi-city presence deserves a genuine multi-city page for each program, is sound. The difference is entirely in the execution.
Why Bootcamps Are a Natural Fit for This, And Where It Goes Wrong
Edtech and bootcamp brands are one of the few business types where city × course pages have a legitimate reason to exist: cohorts, hiring partners, and placement outcomes often really do vary by city. Masai School, for example, runs cohorts and has hiring relationships that differ across Indian cities, which means a Bangalore page and a Delhi page for the same Full-Stack course can honestly say different things about placement partners, local meetup activity, or cohort timing, not just swap a city name into the same three paragraphs.
Where it goes wrong is when a team treats "programmatic" as "identical content, different H1." Search Engine Land and other SEO publications have covered this extensively, Google's helpful content guidance and various core updates have specifically targeted pages built primarily for search engines rather than users, with mass-produced near-duplicate location pages a frequent target of that kind of enforcement. If you've read anything in this series about avoiding a programmatic SEO penalty, the rule carries over here directly: scale the process, not the content itself.
What Claude Code Is Actually Good At Here
Claude Code is a coding agent that works inside a project's codebase or file structure, reading templates, generating variations, and helping assemble structured pages from data you provide (docs.claude.com, Anthropic's Claude Code overview). For a city × course page project, that means it's useful for:
- Building the template logic, the reusable page structure (headings, schema markup, internal linking pattern) that every city page will follow.
- Merging structured data into that template, if you give it a spreadsheet or JSON of per-city facts (hiring partners, cohort start dates, local meetup info, placement stats where available), it can assemble pages that pull the right fact into the right slot.
- Flagging thin output, you can explicitly ask it to check whether a generated page has enough unique content to stand on its own, and to call out sections that are still generic.
- Generating city-specific FAQ variations, real differences in visa/relocation questions, local salary ranges, or commute-to-office norms genuinely vary by city and make legitimate FAQ content.
What it's not good at, and shouldn't be used for: inventing city-specific facts you don't actually have. If you don't have real per-city hiring partner data, don't let it hallucinate placeholder partners just to fill a section, that's the fastest way to create duplicate-feeling, or worse, factually wrong pages.
The Walkthrough: Building One City × Course Page Set
Step 1, Build the real data layer first. Before touching page generation, assemble an actual spreadsheet: city, course, local hiring partners, cohort schedule, any city-specific stats (application volume, average outcomes if you track them by city), and local social proof (testimonials from learners in that city, if available). This is 80% of the work and the part that can't be shortcut.
Step 2, Design one template with real content variance built in. Not just a headline swap, design sections that only render if you have genuine per-city content, and have Claude Code flag any city where a section would otherwise come up empty. An empty section is a signal you don't have enough to justify that page yet, not a place to paper over with filler.
Step 3, Have Claude Code assemble the batch, then generate a variance report. Ask it to output a diff-style summary showing how much of each page's copy is truly unique vs. shared template, the unique-content percentage is roughly the metric Google's own guidance implies matters. Aim high; if two city pages are 90%+ identical in body copy, merge them into one broader page instead.
Step 4, Add internal linking that reflects real structure, not a flat list. Link course pages to their city's other course pages, to a city hub page, and to genuine proof content (a case study, a cohort outcome page), this is where a track record like the growth work behind Masai School's own multi-city, multi-course presence becomes a natural internal-linking asset rather than a keyword-stuffing exercise.
Step 5, Manually review a sample before publishing the batch. Read five to ten pages fully, not skim them. If they read as genuinely useful to a prospective student in that specific city, publish. If they read as a template with a city name pasted in, go back to Step 1.
A Simple Test for "Is This Page Thin?"
Before publishing any page in a programmatic batch, ask:
- If I deleted the city name and course name from this page, could a reader still tell which city and course it's about from the remaining content?
- Does this page contain at least one fact that's genuinely not true of any other city page in the set?
- Would I be comfortable if a competitor screenshotted this page and compared it side-by-side with the others in the set?
If the answer to any of these is no, that page needs more real content, not better prompting.
FAQ
Can Claude Code pull real-time data like current cohort dates automatically? Not on its own, it works with data you provide it (files, spreadsheets, CMS exports). You still need a process for keeping that source data current.
How many unique facts does a city page really need to avoid feeling thin? There's no fixed number, but as a practical bar: at least three to five genuinely city-specific data points (not just the city name repeated) per page, beyond the shared program description.
Is it worth building a city page for every city we operate in, even small markets? Only if you have enough genuine content to support it. A handful of strong hub pages consolidating smaller cities usually outperforms many thin individual pages.
How does this relate to a Google penalty risk? The risk isn't "programmatic SEO" as a technique, it's publishing near-duplicate content at scale. Google's guidance targets content made primarily for search engines rather than users; genuinely differentiated city pages aren't the target.
Should Claude Code write the final page copy, or just assemble it? Treat it as an assembly and drafting tool. Final copy, especially claims about outcomes or partners, should be reviewed by someone who can vouch for its accuracy.
If you're an edtech or bootcamp brand thinking through a programmatic SEO build without the thin-content risk, this is exactly the kind of technical-and-content strategy work I do, more breakdowns like this at younusfardeen.com.