Ten artykuł opisuje, jak w HD SofT zbudowaliśmy własną stronę internetową z wykorzystaniem sztucznej inteligencji — od bazy Squarespace na WordPress + Bricks Builder, w 13 językach, na własnym serwerze, ze zautomatyzowanym pipeline’em publikacji i analityką. Oraz czego nauczyliśmy się po drodze.
Dlaczego zrezygnowaliśmy ze Squarespace
Nasza poprzednia strona stała na Squarespace. Służyła nam długo, ale trzy kwestie przesądziły o zmianie:
- Wielojęzyczność była zbyt droga i niewygodna. Jesteśmy fińskim software house’em, ale realizujemy projekty na całym świecie. Chcieliśmy, aby nasze treści były czytelne w 13 językach — funkcje wielojęzyczne Squarespace nie radziły sobie z tym bez dodatkowych wtyczek i stale rosnących kosztów miesięcznych.
- Byliśmy zamknięci w ekosystemie jednego dostawcy. Chcieliśmy posiadać cały stos: bazę danych, serwer, proces deploymentu i pełną treść. Tylko w ten sposób możemy testować nowe rozwiązania AI i integracyjne bez ograniczania samych siebie.
- SEO i wyszukiwarki AI wymagają kontroli. Dane strukturalne (JSON-LD),
llms.txtoraz tagi Open Graph poszczególnych stron nie są możliwe do realizacji na standardowych usługach w sposób, w jaki potrzebowaliśmy.
Postanowiliśmy zbudować stronę od nowa — i przy okazji praktycznie sprawdzić, jak daleko sięgają współczesne narzędzia AI, gdy software house tworzy z ich pomocą własną stronę na poziomie produkcyjnym.
Wybór stosu: WordPress, Bricks i własny VPS
Jako platformę wybraliśmy WordPress, jako builder stron Bricks Builder, a jako serwer własny VPS w środowisku opartym na Dockerze i Kubernetes.
- WordPress, ponieważ to standard: REST API, Yoast SEO i dziesięcioletnia biblioteka wsparcia dla wszystkiego, czego potrzebujemy. W użyciu: Yoast SEO, Redirection (przekierowania URL), Converter for Media (automatyczna konwersja WebP) oraz AI Engine.
- Bricks Builder obsługuje warstwę wizualną. Kluczowa decyzja: cały styling (typografia, kolory, odstępy, siatki) pozostawiliśmy w Theme Style Bricksa — nie kodujemy pikseli na sztywno dla pojedynczych stron. Dzięki temu maszyna (czyli AI) może tworzyć nowe treści, które wpasowują się w gotowy layout bez dodatkowych poprawek.
- Własny VPS daje pełną kontrolę: koszty są przewidywalne, serwer stoi w Finlandii, a obok możemy budować automatyzacje
n8ni inne projekty w tym samym środowisku.
Czego nie wzięliśmy? Wtyczek wielojęzycznych. Zamiast tego zbudowaliśmy własne rozwiązanie, w którym każdy język ma swoją stronę pod własną ścieżką (na przykład /en/services/, /de/dienstleistungen/). Struktura URL jest prosta, a wyszukiwarki traktują strony jako odrębne byty, nie jako magiczne tłumaczenia.
Produkcja treści z AI — powtarzalny proces
Podstawą każdej treści jest FI-master: oryginalna wersja w języku fińskim, którą piszemy i redagujemy ręcznie. Dopiero gdy jest zatwierdzona, AI tłumaczy ją na pozostałe 12 języków.
W praktyce proces wygląda tak:
- FI-master jest pisany i sprawdzany ręcznie. Fiński wymaga ludzkiego korektora — wyrazy złożone, interpunkcja i niuanse często wymykają się AI.
- Po zatwierdzeniu tekstu uruchamiamy skrypt tłumaczący, który generuje wersje we wszystkich potrzebnych językach (en, de, es, fr, pt, pl, ro, tr, hi, ko, ar, fa).
- Każde tłumaczenie otrzymuje meta pole
_hdsoft_translation_key, które wskazuje na ID posta FI-master. Dzięki temu system wie, które wersje należą do siebie. - Obrazek wyróżniający i data publikacji są kopiowane automatycznie z mastera, więc wersje tłumaczone są spójne wizualnie.
Języki RTL (arabski, perski) otrzymują specjalną uwagę: atrybut HTML dir="rtl", odpowiedni układ i native speaker jako korektor.
AI nie dodaje nowych informacji, nie wymyśla liczb i nie zmienia tonu. Jego zadanie jest proste: tłumaczyć, a nie pisać od nowa.
Automatyzacja techniczna: REST API, mu-pluginy i GitHub Actions
To część, w której AI naprawdę oszczędza czas.
Strony budowane są przez REST API. W Bricksie struktura pojedynczej strony zapisuje się w meta polu _bricks_page_content_2 w formacie JSON. Gdy chcemy utworzyć nową stronę usługową, AI tworzy strukturę JSON zgodną z Bricksem (Section → Container → Block → Heading + Text), wysyła ją POST-em przez REST API, i strona jest gotowa. Korektę można robić bezpośrednio w edytorze, ale podstawowa praca wykonuje się jedną komendą.
Mu-pluginy obsługują zadania specjalne. Oprócz standardowych komponentów mamy kilka własnych mu-pluginów:
hdsoft-jsonld.php— generuje rozszerzone schematy SEO (Service, SoftwareApplication, CreativeWork, ContactPage, FAQPage) jako warstwę nad podstawą Yoasta.hdsoft-tracking.php— tagi Google Analytics, Lead Feeder i Bing Webmaster.hdsoft-domain.php— wymusza, aby wszystkie URL-e widoczne na stronie wskazywały na finalną domenę hdsoft.fi (zapobiegł pozostałościom URL-i przy cutoverze).hdsoft-llms.php— serwuje plik/llms.txtdla wyszukiwarek AI z prawidłowym charsetem UTF-8.
Wszystkie mu-pluginy są deployowane automatycznie przez GitHub Actions: po pushu na gałąź main, runner aplikuje zmianę na klaster K8s. Ręczna komenda kubectl cp nie jest potrzebna.
Jeden globalny JS obsługuje nawigację wielojęzyczną. Element Bricks Code w szablonie nagłówka odczytuje kod języka z URL-a, tłumaczy menu, stopkę oraz linki poprzedni/następny. Oznacza to, że nie tworzymy nagłówka per język, lecz aktualizujemy jeden plik, gdy dodajemy nową usługę.
SEO i GEO od razu w strukturze
Wyszukiwarki AI (ChatGPT, Perplexity, Claude, Bing Copilot) to inna kategoria niż Google. Nie indeksują i nie pozycjonują linków — czytają stronę jako podsumowanie i odpowiadają bezpośrednio na pytanie. To wymaga dwóch rzeczy:
- Danych strukturalnych w formacie JSON-LD. Yoast obsługuje podstawy (WebPage, Article, BlogPosting, BreadcrumbList, Organization). Nasz
hdsoft-jsonld.phpdodaje kluczowe typy specjalne: Service dla stron usługowych, SoftwareApplication dla produktów, FAQPage automatycznie, gdy treść zawiera wzorce pytanie/odpowiedź. llms.txtw katalogu głównym strony. To krótkie streszczenie tego, kim jest firma, co robi i gdzie znaleźć więcej informacji. Aktualizujemy je za każdym razem, gdy dodajemy nową usługę, produkt lub projekt.
Kombinacja działa: wyszukiwarki AI potrafią poprawnie odpowiedzieć na pytania typu „co robi HD SofT”, bez zgadywania ani mylenia nas z inną firmą.
Dodatkowo każda strona ma:
- pole
inLanguagew JSON-LD, generowane na podstawie prefiksu URL - tag
og:localedla wersji tłumaczonych (fi_FI, en_US, de_DE …) - linki
hreflang, gdy wszystkie tłumaczenia są gotowe - akapity zorientowane na odpowiedzi — krótkie, w formie pytanie–odpowiedź, dzięki czemu AI otrzymuje z nich jednozdaniową odpowiedź
Analityka podłączona od razu
Strony internetowej nie da się ulepszać bez danych. Od razu uruchomiliśmy:
- Google Analytics 4 — ruch podstawowy, kanały, strony, zachowanie.
- Google Search Console — widoczność organiczna, top zapytania, problemy z indeksowaniem.
- Lead Feeder — identyfikacja na poziomie firmy, gdy ktoś wielokrotnie odwiedza strony z rozpoznawalnego zakresu IP.
- Bing Webmaster Tools — Bing wciąż jest istotny zwłaszcza w rynku B2B, a Microsoft Copilot czyta Binga.
Szczególnie jedna rzecz: tygodniowy snapshot marketingowy. Napisaliśmy skrypt CLI, który pobiera dane z GA4 i Search Console, porównuje je z poprzednim tygodniem i drukuje podsumowanie w Markdown: kanały, kraje, top strony, top zapytania, delty. To nie jest fancy dashboard, lecz raportowanie praktyczne, ale zapewnia, że nie przegapimy trendu.
Pipeline wspierany przez AI dał tu szczególną przewagę: gdy zapytanie do GA4 lub Search Console trzeba sformatować w odpowiedniej strukturze, AI realizuje to w kilku linijkach kodu i interpretuje wynik z powrotem dla nas w czytelnej formie.
Cutover DNS i obsługa po wdrożeniu
Domenę produkcyjną przełączyliśmy na hdsoft.fi 4 maja 2026. Do cutoveru przygotowaliśmy się następująco:
- Zbudowaliśmy 28 przekierowań ze starych URL-i Squarespace na nowe — wszystkie jako względne, dzięki czemu przetrwały zmianę domeny.
- Błędy 404 zostały podpięte do GA4 jako osobne zdarzenie, aby szybko zauważać uszkodzone linki.
- Mapę witryny przekazaliśmy do Search Console dopiero po zmianie DNS, nie wcześniej (w innym razie Google oznaczyłby ją jako błędną).
Po cutoverze uruchamiamy snapshot marketingowy co tydzień przez pierwsze cztery tygodnie, następnie raz w miesiącu. Dzięki temu szybko zauważymy, jeśli któryś URL zostanie 404 lub któraś strona zacznie nieoczekiwanie dobrze konwertować (wtedy więcej treści).
Czego się nauczyliśmy
Najważniejsze wnioski nie są techniczne, lecz dotyczą sposobu pracy.
- Zaprojektuj style w jednym miejscu, zanim AI zacznie tworzyć treść. Theme Style i Global Classes w Bricksie to narzędzia AI: gdy struktura jest gotowa, maszyna jedynie wypełnia luki. Jeśli zostawisz style otwarte, AI wkoduje piksele na każdej stronie i zacznie się chaos.
- Zablokuj FI-master przed tłumaczeniami. Jeśli master wciąż żyje, tłumaczenia zdążą się rozjechać między różnymi pokoleniami. Jedno źródło prawdy — a reszta podąża za nim.
- Kontrola wizualna obowiązkowo. AI potrafi wyprodukować stronę, która na poziomie JSON jest bezbłędna, ale dla użytkownika wygląda na chaos. Uruchom zrzut ekranu Playwright po każdej zmianie — człowiek czyta, nie tylko walidator.
- Fiński wymaga człowieka. Wyrazy złożone, interpunkcja i ton: AI popełnia błędy, których maszyna nie zauważa. Trzymaj native speakera jako ostatni filtr.
- Zbierz kontekst w jednym pliku. Mamy
CLAUDE.mdw katalogu głównym repo: wszystkie zasady, narzędzia, ścieżki, mechanizmy deploymentu. Gdy otwiera się sesję AI, najpierw czyta ten plik. Człowiek robi to samo, zanim zacznie edytować: przeczytaj instrukcje, a nie zaczniesz od zera.
Ostatecznie najlepsze narzędzie AI to takie, które użytkownik potrafi zatrzymać. Generowanie jest tanie — to zapewnienie jakości jest tą częścią, która decyduje.
Chcesz to samo pod klucz?
HD SofT realizuje dla klientów projekty webowe i contentowe oparte na AI. Ta sama metoda, ten sam poziom jakości, ta sama kontrola: WordPress + Bricks, pipeline automatyzacji, wielojęzyczność i analityka — wszystko podłączone i zoptymalizowane, zanim strona zostanie nawet opublikowana.
Zapytaj o więcej: formularz kontaktowy, Marketing cyfrowy lub Rozwój oprogramowania.
