Programmatic SEO: ponad 4700 stron z ERP

Na hiszpańskim rynku naprawy urządzeń nikt nie robił programmatic SEO. Każda kombinacja urządzenia, marki, modelu, typu naprawy i miasta była niewykorzystaną okazją long-tail.

Teza: jeśli ktoś szuka „wymiana baterii iPhone Sewilla”, powinna istnieć dedykowana strona — z realną ceną, szacowanym czasem realizacji i zdjęciami z prawdziwych napraw. Ręczne budowanie tysięcy stron się nie skaluje. Potrzebowałem systemu, który generuje je automatycznie z ERP i wystarczająco mądrego, by zdecydować, które indeksować, a które pominąć.

Santifer iRepair to był mój serwis naprawy urządzeń w Sewilli od 2009 roku. Szesnaście lat, ponad 30 000 napraw. W 2024 uznałem, że strona musi wyjść poza broszurę na Squarespace i zacząć przechwytywać popyt już obecny w Google. Zbudowałem ten system programmatic SEO jako moat konkurencyjny i sprzedałem firmę we wrześniu 2025 — w szczycie wyników.

Okazja

Hiszpański rynek naprawy urządzeń jest hiper-lokalny. Ludzie szukają po mieście, marce i typie naprawy. Większość punktów miała jednak generyczne strony — jeden landing na całą Hiszpanię, o ile w ogóle miała stronę.

Prawdziwe zapytania z GSC

Liczby

Dwie strategie, jeden system

Projekt zaczął się od ambicji ogólnokrajowych, ale Google miał inne zdanie. Wyszukiwania napraw mają silną intencję lokalną — Google faworyzuje wyniki blisko użytkownika, więc strony bez miasta nie konkurowały. Rozwiązanie: strategia dualna. Strony lokalne dla Sewilli (gdzie jest fizyczny punkt) oraz krajowe strony niszowe dla konkretnych napraw, gdzie lokalizacja ma mniejsze znaczenie.

Architektura

System ma cztery warstwy. Airtable działa jako headless CMS z 14 tabelami i ~60 polami na tabelę. ERP zasila realnymi danymi produkcyjnymi. DataForSEO decyduje, co trafia do indeksu. Astro generuje statyczny HTML z minimalnym JS po stronie klienta — tylko to, co potrzebne do UX (wyszukiwarka, karuzela), ładowane lazy.

Taksonomia URL

Serwis używa 6 wzorców URL, każdy odpowiadający poziomowi taksonomii biznesowej. Wzorce lokalne (z /sevilla) łapią intencję lokalną. Wzorce krajowe (bez miasta) łapią wyszukiwania niszowe.

Premiumowe trasy Apple

Od 2009 naprawialiśmy wyłącznie urządzenia Apple — ludzie nas z tego znali. Apple ma najwyższy wolumen wyszukiwań, a krótsze trasy oddają ten priorytet: /iphone/14-pro zamiast /reparar-movil/apple/iphone-14-pro. Krócej, czyściej, lepszy CTR. Jedna flaga boolean zmienia wszystko:

// Apple: /iphone/14-pro (short, clean, better CTR)
const records = await getRecordsModelos(true);  // modoApple = true → CMSAstro(Apple) view
return records.map(r => ({
  params: { paramMarcaApple: r.paramMarca, paramModeloApple: r.paramModelo },
}));

// Generic: /reparar-movil/samsung/galaxy-s21
const records = await getRecordsModelos();  // modoApple = false → CMSAstro view
return records.map(r => ({
  params: { paramTipo: r.paramTipo, paramMarca: r.paramMarca, paramModelo: r.paramModelo },
}));

Wewnątrz CMS

Airtable to nie tylko „arkusz na sterydach”. Tutaj działa jak pełny relacyjny CMS. Klucz: hierarchia 6 poziomów, która dokładnie odzwierciedla sposób działania firmy.

Kluczowe wzorce CMS

Anatomia strony

Każda z ponad 4700 stron powstaje z szablonu, ale treść jest unikalna, bo pochodzi z ERP. To nie tekst generowany AI ani wypełniacz — to dane produkcyjne.

Ścieżka konwersji na stronie

Każda strona ma strukturę konwersji zaprojektowaną tak, by przeprowadzić użytkownika od odkrycia do działania:

Użytkownik szuka „naprawa ekranu iPhone 14 Pro Sewilla”. Trafia na stronę z cenami (189 € oryginał / 89 € kompatybilne), szacowanym czasem (45 min), 3 prawdziwymi zdjęciami naprawy iPhone 14 Pro i 12 zweryfikowanymi opiniami. Bez zbędnej nawigacji — wszystko potrzebne do decyzji jest na miejscu.

Dynamiczny copy per model

Każdy model dostaje unikalny microcopy wygenerowany z realnych parametrów sprzętu. Pole w Airtable trzyma specyfikację (aparat, bateria, procesor, odporność na wodę), a prompt generuje opis różniący się per model. iPhone 14 Pro mówi o aparacie 48 MP i wyświetlaczu ProMotion. Pixel 7a podkreśla chip Tensor i fotografię obliczeniową. To nie generyczny wypełniacz — to copy, który dotyczy TYLKO tego modelu, na podstawie realnych danych sprzętowych. Ten sam szablon, unikalna treść na każdej stronie.

Live pricing z ERP

Ten sam CMS, który generuje copy, synchronizuje też ceny napraw w czasie rzeczywistym. Airtable łączy ERP (gdzie aktualizowane są koszty części i marże) ze stroną. Każda karta modelu pokazuje zakres cen z min i max dostępnych napraw. Gdy cena zmienia się w ERP, rebuild strony wgrywa nową cenę — zero ręcznej interwencji.

let cadenaPrecio = '';
if (mostrarPrecio.startsWith('desde') && detail.precioMinCard) {
  cadenaPrecio = `Desde ${detail.precioMinCard}`;
}
if (mostrarPrecio === 'desdeHasta' && detail.precioMaxCard) {
  cadenaPrecio = `${cadenaPrecio} hasta ${detail.precioMaxCard}`;
}
if (mostrarPrecio === 'exacto' && detail.precioMinCard) {
  cadenaPrecio = detail.precioMaxCard
    ? `Desde ${detail.precioMinCard} hasta ${detail.precioMaxCard}`
    : `${detail.precioMinCard}`;
}

Wyszukiwanie świadome kontekstu

Pasek wyszukiwania to nie prosty filtr tekstowy. Działa na własnym algorytmie scoringu — bez zewnętrznych bibliotek typu Fuse.js. Użytkownik wpisuje „iphone 12 pro”, a system ocenia wszystkie 867 modeli: +20 jeśli wszystkie słowa pasują, +30 za dokładne dopasowanie, +10 jeśli nazwa modelu zaczyna się od zapytania, i karze dodatkowe słowa w nazwie. Wynik: 6 najbardziej trafnych modeli, posortowanych po wyniku.

Ciekawe jest to, że wyszukiwanie jest świadome kontekstu. Na stronie głównej przeszukuje wszystkie 867 modeli ze wszystkich marek i typów. Na stronie marki (np. Samsung) — tylko modele Samsung. Na stronie typu urządzenia (np. tablety) — tylko tablety. Ten sam komponent, z propsami filtrów (`filtroTipo`, `filtroMarca`), zachowuje się inaczej w zależności od miejsca osadzenia. Modele ładują się lazy przy pierwszym fokusie inputu i cache’ują w localStorage, więc kolejne wyszukiwania są natychmiastowe.

Oto prawdziwa funkcja scoringu — 30 linii, zero zależności:

function calcularPuntuacion(modelo, terminosBusqueda) {
  let puntuacion = 0;
  const nombreModelo = modelo.n.toLowerCase();

  const todasPresentes = terminosBusqueda.every(t => nombreModelo.includes(t));

  if (todasPresentes) {
    puntuacion += 20;
    const palabrasModelo = nombreModelo.split(/\s+/);
    const extras = palabrasModelo.filter(p => !terminosBusqueda.includes(p)).length;
    puntuacion -= extras * 2;

    if (nombreModelo === terminosBusqueda.join(' ')) puntuacion += 30;
    if (nombreModelo.startsWith(terminosBusqueda.join(' '))) puntuacion += 10;
  }
  return puntuacion;
}

Silnik decyzji

System generuje tysiące stron (znacznie więcej niż 4730, które dostały ruch), ale nie wszystkie zasługują na indeksację. Jeśli nikt nie szuka „naprawa kamery przedniej iPhone 11”, ta strona nie powinna konkurować w Google — ale musi istnieć dla użytkownika przeglądającego stronę iPhone 11, który właśnie tej naprawy potrzebuje. Klucz: oddzielenie SEO od UX. Silnik decyzji odpytuje DataForSEO o realny wolumen dla każdej kombinacji i zapisuje wynik w polu „indexable” w airtable.ts.

Optymalizacja crawl budget

Przy ponad 4700 stronach zarządzanie crawl budgetem jest krytyczne — zgodnie z dokumentacją Google Search Central. Google nie powinien marnować czasu na strony, które nie będą rankować. Ponad 700 reguł robots.txt dokłada się do 1009 przekierowań odziedziczonych po migracji.

Wzorzec „Safe Noindex”

Przypadkowy noindex to jeden z najdroższych błędów SEO — jedna linia może zdeindeksować tysiące stron. Oto jak temu zapobiegliśmy:

{NOINDEXCUIDADO &&
  NOINDEXCUIDADO === 'Estoy absolutamente seguro que no quiero hacer no index por eso pongo esta cadena' && (
    <meta name="robots" content="noindex" />
  )}

Pipeline budowy

Pipeline zamienia dane CMS w gotowy do deployu statyczny serwis. W pełni zautomatyzowany. Sam schema.ts ma 1677 linii mapujących hierarchię Airtable na typy Astro.

Retry z exponential backoff

Pipeline zaczyna od pobrania danych z Airtable. Czternaście tabel, tysiące rekordów — wywołania API muszą być odporne. Jedna generyczna funkcja obsługuje wszystko:

function delay(ms: number): Promise<void> {
  return new Promise(resolve => setTimeout(resolve, ms));
}

async function retryWithBackoff<T>(
  operation: () => Promise<T>,
  retries: number = 5,
  delayTime: number = 500
): Promise<T> {
  try {
    return await operation();
  } catch (error: any) {
    if (retries > 0 && (error.statusCode === 502 || error.statusCode === 503)) {
      await delay(delayTime);
      return retryWithBackoff(operation, retries - 1, delayTime * 2);
    }
    throw error;
  }
}

System cache’u opinii

Opinie to najdroższe wywołania w buildzie: ponad 4700 stron może ich potrzebować, ale istnieje tylko 607. Ładujemy je raz na starcie builda, a każda strona czyta z pamięci:

let caches: { [key: string]: Reseña[] | undefined } = {};

async function loadReseñas(baseName: string, cacheKey: string): Promise<void> {
  if (caches[cacheKey]) return;

  const fetchOperation = () => new Promise<Reseña[]>((resolve, reject) => {
    const allRecords: Reseña[] = [];
    base(baseName)
      .select({ view: 'CMSAstro', fields: ReseñaFields })
      .eachStrona(
        (records, fetchNextStrona) => {
          records.forEach(record => allRecords.push(mapReseñaFields(record.fields)));
          fetchNextStrona();
        },
        (err) => err ? reject(err) : resolve(allRecords)
      );
  });

  caches[cacheKey] = await retryWithBackoff(fetchOperation);
}

export async function ensureCachesLoaded(): Promise<void> {
  await Promise.all([
    loadReseñas('Reseñas sincronizar Astro', 'cachedReseñas'),
    loadReseñas('Reseñas Internas', 'cachedReseñasInternas')
  ]);
}

// Runs on module import
ensureCachesLoaded().catch(console.error);

Zautomatyzowany pipeline treści

Wygenerowanie tysięcy stron to połowa roboty. Każda potrzebuje unikalnych obrazów, metadanych i copy. Osiem skryptów Node.js (łącznie 1411 linii) automatyzuje całą produkcję wizualną i tekstową — zero pracy ręcznej. Wszystko łączy się z 12 bazami Airtable w Business OS. Wynik: ponad 26 000 automatycznie wygenerowanych obrazów.

Każdy obraz naprawy dostaje współrzędne GPS punktu wstrzyknięte do metadanych EXIF. Google Images używa tych danych, by pokazywać obrazy w wynikach lokalnych:

// Shop coordinates in Seville
gps[piexif.GPSIFD.GPSLatitude] = convertToDMS(37.38606);
gps[piexif.GPSIFD.GPSLatitudeRef] = 'N';
gps[piexif.GPSIFD.GPSLongitude] = convertToDMS(-5.98585);
gps[piexif.GPSIFD.GPSLongitudeRef] = 'W';

// SEO description in both EXIF fields
exifObj['0th'][piexif.ImageIFD.ImageDescription] = description;

// UCS-2 for Unicode support (Spanish accents, ñ)
const userComment = Buffer.concat([
  Buffer.from('UNICODE\0\0\0', 'ascii'),
  encodeUCS2(description),
]);
exifObj['Exif'][piexif.ExifIFD.UserComment] = userComment.toString('binary');

Kaskada treści: jedna opinia, sześć stron

System automatycznie dziedziczy treść przez taksonomię. Opinia o „naprawie ekranu iPhone 12” nie pojawia się tylko na tej stronie — pokazuje się wszędzie, gdzie jest istotna:

Ta sama logika dotyczy zdjęć before/after: zdjęcie z naprawy ekranu iPhone 12 pojawia się na każdej stronie w tej gałęzi taksonomii. Mnoży unikalną treść bez sztucznego duplikowania ani generowania. Każda strona zbiera więcej social proof i treści wizualnej wraz ze wzrostem firmy.

Zobacz skrypty pipeline’u na GitHubie →

Wewnątrz pipeline’u obrazów

Poprzednia sekcja opisuje pipeline na wysokim poziomie. Tu widać dokładnie, jak działa: prawdziwe szablony overlay, kod kompozycji i co się dzieje przy uruchomieniu na 867 różnych modelach.

Szablony overlay

Każdy typ naprawy ma PNG overlay 384×256 px. Overlay wizualnie pokazuje, która część jest naprawiana: pęknięty ekran, bateria, aparat... Łącznie 17 szablonów, każdy zaprojektowany do złożenia na dowolne zdjęcie urządzenia.

Proces kompozycji

Każdy obraz naprawy powstaje w 6 krokach, w pełni automatycznie skryptem Node.js i Sharp.js:

Prawdziwy kod

To prawdziwy fragment z generarImagenesReparacionesModelos.mjs który generuje każdy obraz naprawy:

await sharp({
  create: {
    width: 384, height: 256,
    channels: 4,
    background: { r: 255, g: 255, b: 255, alpha: 1 }
  }
})
  .png()
  .composite([
    { input: overlayPath },
    { input: devicePhoto,
      top: Math.round(top),
      left: Math.round(left) }
  ])
  .webp()
  .toFile(outputPath)

1 zdjęcie → 18 wariantów

Z jednego zdjęcia iPhone 14 Pro pipeline automatycznie generuje 18 unikalnych obrazów: jeden generyczny hero i 17 wariantów naprawy. Każdy wariant składa zdjęcie urządzenia z konkretnym overlayem.

Wymiana ekranu iPhone 14 Pro

Wymiana baterii iPhone 14 Pro

Wymiana tylnego aparatu iPhone 14 Pro

Wymiana portu ładowania iPhone 14 Pro

Wymiana tylnej pokrywy iPhone 14 Pro

Wymiana szkła iPhone 14 Pro

Wymiana głośnika iPhone 14 Pro

Wymiana mikrofonu iPhone 14 Pro

Wymiana słuchawki iPhone 14 Pro

9 z 17 automatycznie wygenerowanych wariantów dla iPhone 14 Pro. Każdy obraz składa prawdziwe zdjęcie urządzenia z konkretnym overlayem naprawy.

Ten sam pipeline, inne urządzenie

Ten sam proces działa dla dowolnego urządzenia. Zmienia się zdjęcie, overlaye zostają. Dlatego da się skalować do 867 modeli bez pracy ręcznej.

Skala

Pipeline opinii

Opinie to najsilniejszy social proof na każdej stronie. Ale zarządzanie setkami profili klientów, synchronizacja dwóch źródeł i kaskadowanie sygnałów zaufania przez całą taksonomię wymaga własnego pipeline’u.

Źródło i synchronizacja

Opinie pochodzą z dwóch źródeł: Google My Business (publicznie zweryfikowane) oraz wewnętrznych ankiet po naprawie. Oba synchronizują się do Airtable i normalizują do jednego formatu.

Przetwarzanie zdjęć profilowych

Każda opinia ze zdjęciem profilowym przechodzi przez zautomatyzowany pipeline:

Prawdziwy kod

To prawdziwy fragment z `generarImagenesReseñas.mjs`, który przetwarza każde zdjęcie profilowe:

const imageBuffer = await fetch(attachmentUrl)
  .then(r => r.arrayBuffer())

await sharp(Buffer.from(imageBuffer))
  .webp({ quality: 95 })
  .toFile(outputPath)

// Write processed URL back to Airtable
await base('Reseñas sincronizar Astro')
  .update(record.id, {
    'imagen_procesada': outputUrl
  })

Kaskada social proof

Opinie nie pojawiają się tylko na jednej stronie — dziedziczą się przez całą taksonomię. Opinia powiązana z modelem propaguje się na każdą stronę, gdzie ten model jest istotny.

Setki przetworzonych profili

Prawdziwe profile klientów przetworzone przez pipeline. Każde zdjęcie pobrano, skonwertowano do WebP i powiązano z powrotem z Airtable.

Prawdziwe profile klientów. Każde zdjęcie jest pobierane, konwertowane do WebP i powiązywane z powrotem z Airtable.

Renderowanie: karuzela CRO

Na produkcji opinie renderują się w karuzeli z auto-rotacją co 9 s, wizualnym paskiem postępu i nawigacją kropkami. Top 20 opinii widać od razu; reszta rozwija się pod przyciskiem „Pokaż więcej”. Wszystko server-rendered — zero JavaScriptu dla bazowej karuzeli.

1 / 5

Skala

Pipeline before/after

Każda ukończona naprawa generuje dowód fotograficzny: 4 zdjęcia dokumentujące stan urządzenia przed i po. Ten pipeline przetwarza je automatycznie i rozsyła po serwisie.

Protokół zdjęć

Każda ukończona naprawa w punkcie ma protokół 4 zdjęć:

Automatyczne przetwarzanie

Każde zdjęcie przechodzi 6 kroków przetwarzania Sharp.js:

Prawdziwy kod

To prawdziwy fragment z CasosExito.mjs który przetwarza każde zdjęcie naprawy:

let pipeline = sharp(inputBuffer)
  .resize({
    width: Math.round(metadata.width / 4),
    height: Math.round(metadata.height / 4)
  })

if (record.fields.difuminar) {
  pipeline = pipeline.blur(8)
}

await pipeline
  .composite([{
    input: whiteOverlay,
    blend: 'over'
  }])
  .webp({ quality: 85 })
  .toFile(outputPath)

Prawdziwy wynik: iPhone 14 Pro

To prawdziwe zdjęcia przetworzone przez pipeline. Front i tył, przed i po naprawie.

Ten sam pipeline, różne marki

Pipeline działa tak samo dla każdej marki i modelu. Tu zastosowany do Samsung Galaxy A51 i Xiaomi Redmi Note 9S.

Ten sam pipeline przetwarzania dla każdej marki. Zdjęcia są pobierane, skalowane, w razie potrzeby rozmywane i automatycznie eksportowane do WebP.

Skala

Krzywa wzrostu

Start w październiku 2024. Pierwsze miesiące to czysty momentum indeksacji. Po początkowym szczycie w styczniu ruch wypłaszczył się od lutego do czerwca — i to nie była sezonowość. To była restrukturyzacja: oryginalna wersja generowała strony krajowe i lokalne dla każdej kombinacji, ale było ich za dużo, a Google wyraźnie faworyzował intencję lokalną. Przekierowałem strony krajowe na lokalne odpowiedniki /sevilla, zostawiając w formacie krajowym tylko niszowe naprawy (np. /cambiar-bateria-iphone-11), gdzie specyfika waży więcej niż brak lokalizacji. Dopóki Google reindeksował nową strukturę, ruch stał w miejscu. Po konsolidacji wzrost ruszył znowu — szczyt we wrześniu 2025: 2193 kliknięcia.

Kamienie milowe Google Search Console

Google świętuje progi ruchu odznakami. W 3 miesiące przeszliśmy z 1,2 tys. do 2 tys. kliknięć miesięcznie — ostatnia odznaka przyszła dokładnie przy domknięciu sprzedaży firmy.

Wyniki

Metryki skumulowane od startu (październik 2024 – luty 2026), bezpośrednio z Google Search Console:

Ale te wyniki nie wzięły się znikąd. Punktem startu była strona na Squarespace z problemami technicznymi, które trzeba było rozwiązać, zanim dało się zbudować system programmatic.

Punkt startu

Strona firmy przez lata działała na Squarespace. Brak kontroli URL, brak tagów canonical, brak własnych przekierowań. Nadchodziła nie tylko zmiana platformy — potrójna migracja: platforma (Squarespace → Astro), domena (santifer.me → santiferirepair.es) i hosting (Squarespace → Vercel/Cloudflare). Pierwszy krok: udokumentować, co trzeba naprawić — 144-stronicowy audyt techniczny, zrobiony jako Final Master's Project programu Big SEO.

Audyt techniczny

Pierwszym krokiem był pełny audyt techniczny, zrobiony jako Final Master's Project programu Big SEO. 144 strony dokumentujące każdy aspekt techniczny serwisu: od baseline ruchu po ostatni meta description.

Dług techniczny

Migracja

Serwer przekierowań

Potrójna migracja (platforma, domena, hosting) wymagała planu ochrony autorytetu zgromadzonego na starej domenie. Rozwiązaniem był dedykowany projekt Vercel, którego jedynym celem było serwowanie 301. Haczyk zmiany domeny: Squarespace nie pozwalał przekierować homepage, co blokowało change of address w GSC. Podwójny hop HTTP→308→301 uniemożliwiał walidację. Naprawione w jedno popołudnie: Vercel Redirect Domain + Cloudflare Redirect Rules dla jednego bezpośredniego 301.

Koszt migracji

Każda migracja ma koszt przejścia. Ponad 800 stron potrzebowało czasu na reindeksację, a kluczowe słowa chwilowo spadły — „reparar iphone sevilla” z top 2 na pozycję 6. To było oczekiwane: Google potrzebuje czasu na ponowną ocenę domeny po change of address. Odbicie przyszło.

Z Lighthouse 21 na Squarespace do 100 na Astro. Z DA 8 do konkurencji na rynku, gdzie liderzy mają 100× więcej ruchu. Audyt techniczny udokumentował 33 problemy; migracja rozwiązała je wszystkie naraz.

Stack i narzędzia

Stack dobrano pod konkretną potrzebę: generowanie tysięcy stron statycznych z relacyjnego CMS, z minimalnym JS po stronie klienta. Astro było oczywistym wyborem pod czyste SSG. Airtable działał jako CMS, bo już był Business OS firmy — migracja na Supabase pod statyczny serwis nie miała sensu. DataForSEO wybrano za cenę i pokrycie hiszpańskich słów kluczowych.

Astro

SSG, 21 szablonów, minimalny lazy JS

Airtable

Headless CMS, 14 tabel, ~60 pól/tabelę

DataForSEO

Wolumeny wyszukiwań, pole „indexable”

Własny ERP

867 modeli, ceny, stock, zdjęcia, opinie

Cloudflare

CDN, cache edge, deploy

TypeScript

1677-liniowy schema.ts do mapowania

JSON-LD

6 typów structured data na stronę

Wnioski

Co to pokazuje

FAQ

Zasoby

• Kod źródłowy na GitHubie (skrypty, layouty, trasy)
• Santifer iRepair (serwis programmatic)
• Case study: Business OS / ERP stojący za tymi stronami
• Astro, framework stron statycznych
• DataForSEO, API danych SEO
• Airtable, platforma danych i CMS