Programmatic SEO: 4,700+ Pages from an ERP

In Spain's device repair market, nobody was doing programmatic SEO. Every combination of device, brand, model, repair type, and city was an untapped long-tail opportunity.

The thesis: if someone searches "iPhone battery repair Seville", a dedicated page should exist — with the real price, estimated turnaround, and photos from actual repairs. But hand-building thousands of pages wouldn't scale. I needed a system that auto-generated them from the ERP, smart enough to decide which ones to index and which to skip.

Jinank iRepair was my device repair business in Seville since 2009. Sixteen years, over 30,000 repairs. In 2024 I decided the website needed to move beyond a Squarespace brochure and start capturing the demand already sitting in Google. I built this programmatic SEO system as a competitive moat and sold the business in September 2025, at its peak.

The Opportunity#

The device repair market in Spain is highly local. Users search by city, brand, and repair type. Yet most competitors had generic websites: one landing for all of Spain, if they had a site at all.

Real GSC queries

The Numbers#

Two Strategies, One System#

The project started with national ambition, but Google has its own criteria. Repair searches have very strong local intent. Google prioritizes proximity results, so national pages without cities competed poorly. Solution: a dual strategy. Local pages for Seville (shop location) and niche national pages for specific repairs where location matters less.

The Architecture#

The system has four layers. Airtable works as a headless CMS with 14 tables and ~60 fields per table. The ERP feeds real production data. DataForSEO decides what to index. Astro generates static HTML with minimal JS — only for UX essentials (search, carousel), lazily loaded.

URL Taxonomy#

The URL structure follows a logical hierarchy that mirrors the business inventory. This allows for powerful wildcard redirects and breadcrumb schemas.

Premium Apple Routes

For Apple devices, the intent is so high that I built dedicated premium branches with custom layouts.

// Apple premium route mapping
if (brand === "Apple") {
  renderPremiumLayout(model, city);
}

The CMS Internals#

Airtable isn't just a spreadsheet on steroids. Here it functions as a full relational CMS. The key is the 6-level hierarchy reflecting actual business operations.

Key CMS patterns

Page Anatomy#

Each of the 4,700+ pages is generated from a template, but content is unique because it comes from the ERP. Not AI-generated filler: actual production data.

Conversion Flow per Page

Each page follows a conversion structure designed to move users from discovery to action:

A user searches "repair iPhone 14 Pro screen Seville". They reach a page with pricing (€189 original / €89 compatible), 45-min time estimate, 3 real repair photos, and 12 verified reviews. All info to decide is right there.

Model-Dynamic Copy

Each device model has unique microcopy generated from its real hardware specs. An Airtable field stores technical features (camera, battery, chip) and a prompt generates unique text per model. An iPhone 14 Pro highlights its 48MP camera and ProMotion display. A Pixel 7a highlights its Tensor chip. Not generic content: hardware-specific data on every page.

ERP-Synced Prices

The same CMS syncing copy also syncs prices in real-time. Airtable bridges the ERP (where part costs and margins live) and the web. Each model shows a price range calculated from its available repairs. When an ERP cost changes, the site regenerates with updated prices — zero manual work.

Contextual Search

The search component isn't a simple text filter. It uses a custom scoring algorithm — no external libraries like Fuse.js. It scores 867 models: +20 for all words present, +30 for exact match, +10 for "starts with", and penalizes extra words. Result: the 6 most relevant models, sorted by score.

The search is context-sensitive. On the home page, it searches all 867 models. On the Samsung page, it only searches Samsung models. The same component, filtered by props (`filtroTipo`, `filtroMarca`). Models load on first focus and cache in localStorage for instant subsequent searches.

The algorithm in 30 lines with zero dependencies:

The Decision Engine#

The system generates thousands of pages (far more than the 4,730 with traffic), but not all deserve indexing. If no one searches for "repair iPhone 11 front camera", that page shouldn't compete in Google — but it must exist for users navigating from the iPhone 11 page. The decision engine queries DataForSEO for real search volume, storing the result in Airtable's "indexable" field.

Crawl Budget Management#

With thousands of potential pages, I needed an algorithmic way to decide which ones warranted indexing to not waste Google crawl budget on low-value URLs.

Safe Noindex Pattern

A data field in Airtable, fed by DataForSEO volume checks, controls the meta robots tag:

if (!isIndexable) {
  return <meta name="robots" content="noindex, follow" />
}

Build Pipeline#

The pipeline transforms CMS data into a static site. Everything is automated. schema.ts has 1,677 lines mapping Airtable hierarchy to Astro types.

Inside the Image Pipeline#

The parametric generation process in detail: templates, composition code, and the results across 867 models.

Overlay Templates

Each repair type has a 384x256 PNG overlay showing what part is being repaired (cracked screen, battery, etc.). 17 templates designed to composite over any device photo.

The Composition Process

Automatic 6-step generation using Node.js and Sharp.js:

The Sharp.js Pipeline

The generation logic uses the Sharp library for high-speed image composition and WebP optimization.

// Parametric generation pipeline
await sharp(base)
  .composite([{ input: overlay }])
  .webp()
  .toFile(output);

1 Photo → 18 Variants

A single device photograph serves as the base for 18 automatic variants — one for each repair type plus the hero image.

Base photo

Screen repair

Battery repair

1 device photo → 18 static variants. Automatic composition via Node.js + Sharp.

Cross-Device Scale

The same composition logic applies to every brand and model in the ERP. From iPhones to obscure Android models, the visual quality remains consistent.

IMAGE SCALE

Review Automation#

A static site is only as good as its social proof. The review pipeline ensures every new verified customer review from the ERP propagates to the site automatically.

Source Sync (ERP → Airtable)

Reviews are fetched via the ERP API and mapped to the model hierarchy in the CMS.

Review Image Processing

Automated workflow for customer profile photos:

The Review Pipeline Code

Node.js scripts process the review payload and generate the static JSON assets.

// Process reviews
const reviews = await fetchERPReviews();
await generateReviewAssets(reviews);

Content Cascade: One Review, Six Pages

The system inherits content through the taxonomy hierarchy. An "iPhone 12 screen repair" review propagates to every relevant page in the branch:

The Review Profile

Airtable automated profile: downloads photos, blurs customer details, and generates WebP thumbnails.

Airtable automated profile: downloads photos, blurs customer details, and generates WebP thumbnails.

CAROUSEL CRO

Real reviews are not just text. They are proof. My system links every review to the specific model, family, or brand level in the taxonomy.

1 / 5

SOCIAL PROOF AT SCALE

Before/After Photo Pipeline#

Static model photos are not enough. High-intent users want to see that you have actually repaired their specific device.

The Capture Protocol

Every technician followed a strict 3-photo workflow within the ERP:

Image Processing Pipeline

A Node.js script processes the thousands of raw photos from the ERP:

The Processing Code

The pipeline uses sharp for image manipulation and piexifjs for local SEO signals.

// Image composition example
await sharp(basePath)
  .composite([{ input: overlayPath }])
  .webp({ quality: 80 })
  .toFile(outputPath);

Real Data Demo

This is not a mock. These are real photos from the production database.

Cross-Device Scale

The same pipeline works for 867 different models across all brands.

10,000+ real photos processed. Automated resizing, blurring, and EXIF injection.

10,000+ PHOTOS

Growth Curve#

Launched October 2024. Traffic stayed flat early 2025 due to a restructuring: I redirected broad national pages to specific local ones (/seville) once it became clear Google highly prioritized geographic intent for this domain. Once the hierarchy consolidated, growth exploded to the September 2025 peak.

The Results#

In 12 months, organic traffic went from near-zero to over 300,000 monthly impressions. More importantly, it captured high-intent transactional queries that were previously dominated by marketplaces.

But to understand how we got here, we have to look at the starting point: a legacy site that was invisible to Google.

The Starting Point#

The business website had been on Squarespace for years. No URL control, no canonical tags, no custom redirects. What was coming wasn't just a platform change — it was a triple migration: platform (Squarespace → Astro), domain (jinank.me → santiferirepair.es), and hosting (Squarespace → Vercel/Cloudflare). The first step was documenting exactly what needed fixing: a full technical audit of 144 pages, conducted as my Master's Thesis for the Big SEO program.

The Technical Audit

The first step was a full technical audit, performed as my Master's Thesis for the Big SEO program. 144 pages documenting every technical aspect of the site: from traffic health to meta descriptions.

The Technical Issues

The Migration

The Redirect Server

The triple migration (platform, domain, hosting) required a plan to keep domain authority. The solution was a dedicated Vercel project whose only job was serving 301 redirects. A domain change catch: Squarespace didn't allow redirecting the homepage, blocking GSC address change validation. Double hop HTTP→308→301 prevented validation. Solved via Vercel Redirect Domain + Cloudflare Redirect Rules for a single direct 301.

The Cost of Migrating

Every migration has a transition cost. 800+ pages took time to reindex, and key keywords temporarily dropped — "repair iphone seville" fell from top 2 to position 6. Expected: Google needs time to reevaluate a domain change. Recovery arrived.

From a 21 Lighthouse on Squarespace to 100 on Astro. From DA 8 to competing where leaders have 100x more traffic. The audit documented 33 issues; the migration solved them all.

The Stack#

Purely static architecture with minimal lazy-loaded interactivity.

Lessons Learned#

What This Demonstrates

FAQ#

Resources#

• GitHub source code (scripts, layouts, routes)
• Jinank iRepair (the pSEO site)
• Case Study: Business OS fueling these pages
• Astro — Static Site Framework
• DataForSEO — SEO Data API
• Airtable — Database & CMS