Firma z ponad 20-letnim doświadczeniem na rynku pożyczek pozabankowych, kilkadziesiąt zapytań miesięcznie, rozbudowana oferta produktowa — i strona internetowa, która była technicznym hamulcem całego biznesu. Klasyczny WordPress z rozbudowanymi wtyczkami, wolny TTFB, brak kontroli nad frontendem i coraz trudniejsza rozbudowa o nowe funkcjonalności.
Kiedy podhipoteke24.pl zgłosiło się do nas, zakres projektu był jasny: pełna przebudowa architektury — od monolitycznego WordPressa do nowoczesnego stacku headless, który daje przewagę zarówno w wydajności, jak i możliwościach dalszego rozwoju. Poniżej opisuję dokładnie, co zbudowaliśmy, jakie decyzje techniczne podjęliśmy i dlaczego.
Dlaczego headless? Decyzja architektoniczna
Klasyczny WordPress w branży finansowej napotyka na specyficzne ograniczenia. Klient potrzebował czegoś, czego żaden motyw WP nie byłby w stanie zapewnić bez kompromisów: 8 zaawansowanych narzędzi finansowych z logiką kalkulacyjną, interaktywnym UI i generowaniem raportów PDF. Próba wbudowania tego w WordPress oznaczałaby labirynt wtyczek, PHP po stronie klienta i niemożliwe do utrzymania rozwiązania.
Architektura headless rozwiązuje ten problem elegancko: WordPress pozostaje backendem treści — redaktorzy pracują w znajomym panelu, SEO jest obsługiwane przez Yoast — a frontend działa jako osobna aplikacja Next.js. Komunikacja przez GraphQL (WPGraphQL) daje pełen dostęp do wszystkich danych CMS-a bez żadnych kompromisów narzucanych przez motyw.
| Aspekt |
Klasyczny WordPress |
Headless Next.js |
| Wydajność | PHP na każdym żądaniu, TTFB >800ms | ISR + Edge CDN, TTFB <200ms |
| Frontend | Motyw narzuca ograniczenia | Pełna kontrola — React, Tailwind, TypeScript |
| Narzędzia finansowe | Wtyczki + shortcodes + hacki | Dedykowane komponenty React z pełną logiką |
| SEO | Yoast działa natywnie | Yoast zachowany przez WPGraphQL |
| Skalowanie | Każda nowa funkcja = wtyczka lub hack | Nowe route'y w Next.js, niezależnie od WP |
Stack technologiczny — konkretne wersje, konkretne powody
Stos dobierałem pod kątem długoterminowego utrzymania i możliwości zespołu klienta:
- Next.js 16.1.6 + React 19.2.3 — najnowsze mechanizmy renderowania, streaming SSR i App Router jako domyślna architektura routingu.
- TypeScript 5 — statyczne typowanie eliminuje całą klasę błędów w runtime'ie, szczególnie ważne przy skomplikowanej logice kalkulatorów finansowych.
- Tailwind CSS v4 — zero runtime, style kompilowane statycznie, brak wpływu na Core Web Vitals.
- Apollo Client 4.1.4 + GraphQL 16.12.0 — komunikacja z WPGraphQL z cache'owaniem zapytań po stronie klienta.
- Radix UI + shadcn/ui — dostępne komponenty UI bez narzucania stylów, idealne dla Tailwinda.
- React PDF Renderer — generowanie spersonalizowanych raportów PDF po stronie klienta bez zewnętrznych serwisów.
- Vercel + Edge Network + Speed Insights — deployment na globalny CDN z analityką wydajności.
Wydajność — jak architektura daje przewagę, której WP nie osiągnie
Wydajność w headless to nie kwestia optymalizacji — to kwestia fundamentów. Oto konkretne mechanizmy:
ISR (Incremental Static Regeneration) — strony są generowane statycznie przy pierwszym żądaniu i odświeżane w tle co 24 godziny. Użytkownik zawsze dostaje gotowy HTML z cache'u CDN, serwer PHP nie jest w ogóle pytany. W klasycznym WP nawet z agresywnym cachowaniem każde żądanie z niezakeszowanego IP powoduje wywołanie PHP.
Next.js Image z WebP i lazy loadingiem — wszystkie obrazy są automatycznie konwertowane do WebP, serwowane w odpowiednim rozmiarze (srcset) i ładowane leniwie. W klasycznym WP osiągnięcie tego wymaga przynajmniej dwóch wtyczek, które same w sobie spowalniają stronę.
Edge deployment przez Vercel CDN — treść jest serwowana z węzła geograficznie najbliższego użytkownikowi. Dla polskiego ruchu to kilkadziesiąt milisekund różnicy na starcie każdego żądania.
Apollo Client v4 z cache'owaniem GraphQL — zapytania do WordPressa nie są powtarzane przy każdym renderze. Apollo przechowuje odpowiedzi w pamięci podręcznej — dla powtarzających się danych (np. menu, treści stron) WordPress jest odpytywany jednorazowo.
8 narzędzi finansowych — interaktywny hub kalkulatorów
To serce projektu pod względem funkcjonalności i największa wartość dla użytkownika. Każde narzędzie to samodzielny komponent React z własną logiką kalkulacyjną, formularzem leadowym i integracją z GA4.
| Narzędzie |
Co robi |
Output |
| Kalkulator raty | Symulacja miesięcznej raty pożyczki | Harmonogram spłat + lead |
| Estymator kwoty | Ile można pożyczyć pod daną nieruchomość | Szacunkowa kwota + lead |
| Kalkulator konsolidacji | Analiza opłacalności konsolidacji długów | Oszczędności miesięcznie + lead |
| Porównywarka | Zestawienie różnych scenariuszy pożyczkowych | Tabela porównawcza |
| Diagnostyka finansowa | Quiz kwalifikujący do produktu | Rekomendacja produktu |
| Wynik diagnostyki | Spersonalizowany raport na podstawie quizu | PDF wysyłany na email |
| Wykres spłaty | Wizualizacja harmonogramu (Recharts) | Interaktywny wykres |
| Wykres oszczędności | Porównanie kosztów konsolidacji | Wykres Recharts + lead |
Każde z narzędzi generuje lead do backendu WordPress przez dedykowane REST API i jest w pełni śledzone w GA4 przez zdarzenia tool_started, tool_result i quiz_step/quiz_completed. Wybrane narzędzia generują spersonalizowany raport PDF — tworzony po stronie klienta przez React PDF Renderer i wysyłany na email użytkownika przez endpoint POST /wp-json/ph24/v1/send-pdf.
Własna wtyczka WordPress — system zarządzania leadami zamiast CRM
Zamiast podpinać zewnętrzny CRM z miesięcznym abonamentem i zależnością od zewnętrznego serwisu, zdecydowaliśmy się zbudować dedykowaną wtyczkę WordPress obsługującą cały lejek sprzedażowy.
Wtyczka podhipoteke-leads udostępnia REST API na /wp-json/ph24/v1/ i zarządza własną tabelą ph24_leads w bazie danych WordPress.
| Metoda |
Endpoint |
Funkcja |
| POST | /leads | Przyjmowanie leadów z Next.js (rate limiting: 5 req/min per IP) |
| GET | /leads + filtry | Panel administracyjny (tylko admin, paginacja) |
| PATCH | /leads/{id} | Zmiana statusu leada |
| DELETE | /leads/{id} | Usuwanie leada |
| GET | /leads/export | Eksport CSV z BOM (gotowy do Excela) |
| POST | /send-pdf | Wysyłka raportu PDF na email (base64 → wp_mail) |
Tabela ph24_leads przechowuje pełen zestaw danych: imię, telefon, email, miasto, wiadomość, dane z narzędzi (JSON), status leada, IP oraz pełną atrybucję UTM: utm_source, utm_medium, utm_campaign, utm_content, utm_term i gclid. Każdy lead wie, skąd pochodzi.
Panel administracyjny w WordPress pozwala zarządzać leadami bez wychodzenia ze znajomego interfejsu: filtrowanie po statusie i źródle ruchu, kolorowe badge'e SEO vs. Google Ads, zmiana statusu inline przez AJAX, podgląd danych z kalkulatorów i eksport CSV jednym kliknięciem.
UTM attribution end-to-end — skąd pochodzi każdy lead
To element, który odróżnia profesjonalne wdrożenie od przeciętnego. Standardowe formularze kontaktowe zbierają imię i telefon. Tu zbieramy pełną ścieżkę, którą przyszedł użytkownik.
Mechanizm działa w trzech krokach:
- Przechwytywanie przy wejściu — biblioteka analityczna czyta parametry URL przy pierwszej wizycie i zapisuje je w
sessionStorage.
- Dołączanie do zdarzenia GA4 — przy
form_submit parametry UTM są dołączane do payloadu zdarzenia.
- Zapisanie w bazie WP — te same parametry trafiają do każdego rekordu leada w bazie danych.
Efekt: klient może w dowolnym momencie wyeksportować listę leadów i zobaczyć, ile pochodzi z organicznego SEO, ile z konkretnej kampanii Google Ads (po utm_campaign), a ile trafiło bezpośrednio. To dane, których nie daje żaden standardowy formularz kontaktowy.
Śledzenie konwersji GA4 — 14 typów zdarzeń
Centralna biblioteka lib/analytics.ts obsługuje cały tracking w jednym miejscu. Żadnych rozproszonych wywołań po komponentach — jedno wywołanie funkcji, jeden punkt wejścia, pełna spójność danych.
| Zdarzenie GA4 |
Trigger |
phone_click | Kliknięcie numeru telefonu |
cta_click | Kliknięcie przycisku CTA |
form_start | Pierwsza interakcja z formularzem |
form_submit | Wysłanie formularza + pełna atrybucja UTM |
faq_expand | Rozwinięcie pytania FAQ |
scroll_depth | Głębokość scrolla (25 / 50 / 75 / 100%) |
file_download | Pobranie raportu PDF |
cookie_consent | Akceptacja lub odrzucenie cookies |
tool_started | Uruchomienie narzędzia finansowego |
tool_result | Wynik kalkulacji (z danymi wejściowymi) |
quiz_step | Przejście do kolejnego kroku diagnostyki |
quiz_completed | Ukończenie diagnostyki finansowej |
Osobne śledzenie konwersji Google Ads odpala się przy każdym wysłaniu formularza — bez duplikowania kodu, bo każde miejsce wywołuje tę samą funkcję z biblioteki analytics.
42 landing page'e dla miast — lokalne SEO w skali
Pożyczki pod zastaw nieruchomości mają charakter lokalny — klienci szukają konkretnych fraz z nazwą miasta. Sieć 42 landing pages dla największych miast Polski odpowiada na ten popyt.
To nie są strony z wymienioną tylko nazwą miasta. Każda z nich zawiera lokalne ceny nieruchomości (rynek wtórny i pierwotny), dzielnice danego miasta, treści SEO w poprawnych formach gramatycznych oraz dane strukturalne Schema.org z atrybutem LocalBusiness. Strony są generowane statycznie przez generateStaticParams() i serwowane z CDN — zero dodatkowego obciążenia serwera przy ruchu.
Middleware 301 i dynamiczna sitemap
Next.js middleware obsługuje całą logikę przekierowań w jednym pliku TypeScript — 9 slugów stron usługowych i stare wpisy blogowe przekierowane z zachowaniem wartości SEO. Zero ręcznych wpisów w htaccess, zero wtyczek.
Sitemap XML generuje się automatycznie z rewalidacją co 24 godziny. Pole lastmod pobierane jest bezpośrednio z pola modified WordPressa przez GraphQL — to rzeczywista data ostatniej aktualizacji treści, nie statyczna data deploymentu.
Skala projektu i wyniki
| Element projektu |
Liczba |
| Komponenty React (TypeScript) | 60 |
| Route'y aplikacji Next.js | 25 |
| Zapytania GraphQL (Apollo Client) | 8 |
| Narzędzia finansowe | 8 |
| Landing pages miast | 42 |
| Typy zdarzeń GA4 | 14 |
| Pola UTM w bazie leadów | 6 (+ gclid) |
Migracja z klasycznego WordPress do headless odbyła się bez żadnego downtime'u. Nowa architektura daje fundamenty, których monolityczny WP nie był w stanie zapewnić: Core Web Vitals na poziomie niedostępnym dla klasycznego WordPress, system leadów z pełną atrybucją UTM, 8 kalkulatorów jako maszyna do generowania zapytań i fundamenty pod dalsze skalowanie — nowe landing pages, nowe narzędzia, nowe produkty bez dotykania backendu.
Headless to w tym projekcie konkretna decyzja architektoniczna, która rozwiązuje konkretny problem: firma pożyczkowa potrzebuje narzędzi, których klasyczny WordPress nie jest w stanie dostarczyć bez kompromisów. Headless daje obie rzeczy jednocześnie — znajomy panel redakcyjny WP dla treści i pełną swobodę React dla funkcjonalności.
