Tworzenie Stron i Aplikacji Web

Tworzenie stron internetowych w Next.js – czym różni się od strony na szablonie

Strona w Next.js to kod pisany pod konkretny serwis, w którym o sposobie generowania każdej podstrony, o szybkości i o tym, co widzą roboty, decyduje programista, a nie motyw i zestaw wtyczek. Strona na szablonie jest szybsza do uruchomienia, ale dziedziczy cudzy kod, którego większość nie jest Ci potrzebna.

Next.js to framework oparty na React, który potrafi wygenerować HTML z wyprzedzeniem, na serwerze przy każdym żądaniu albo w przeglądarce. Dla firmy oznacza to trzy rzeczy: treść jest w HTML-u, zanim zadziała JavaScript, strona ładuje tylko to, czego używa, a nowe funkcje (kalkulator, panel klienta, integracja z CRM) dopisuje się w tym samym projekcie, bez kolejnej wtyczki.

Nie uważam, że każda strona musi powstać w Next.js. Jeśli potrzebujesz prostej wizytówki, którą edytuje kilka osób, i nie planujesz rozwoju, dobrze utrzymany WordPress też wystarczy. Next.js wybieram, gdy strona ma zarabiać: generować zapytania, sprzedawać, obsługiwać klientów albo rosnąć o nowe funkcje.

Strona internetowa dla firmy, sklep czy aplikacja webowa – co naprawdę potrzebujesz

O rodzaju projektu decyduje to, co użytkownik ma zrobić: przeczytać i zostawić kontakt (strona), kupić (sklep) czy wykonywać pracę po zalogowaniu (aplikacja webowa). Od tej odpowiedzi zależy architektura, budżet i czas realizacji.

• Landing page – jedna strona pod jeden cel, najczęściej kampanię reklamową lub premierę. Opisuję ją w usłudze landing page w Next.js.
• Strona firmowa – kilkanaście lub kilkadziesiąt podstron dla klientów, kandydatów i partnerów, z CMS-em i integracjami. To zakres strony firmowej i korporacyjnej.
• Sklep – katalog, koszyk, płatności. Gdy szablon przestaje wystarczać, proponuję sklep headless na Shopify, a dla hurtowni z cennikami per kontrahent platformę B2B.
• Aplikacja webowa – panel, dashboard, system dla klientów lub zespołu. Tu liczy się projekt danych, API i uprawnienia, a nie tylko wygląd.

Częsty przypadek to projekt mieszany: strona firmowa z panelem klienta albo sklep z konfiguratorem. Wtedy warto od początku zaplanować wspólną architekturę, zamiast doklejać aplikację do strony na innym systemie.

Architektura SEO-ready – renderowanie, Core Web Vitals i dane strukturalne

Strona gotowa na SEO to taka, w której treść, linki i dane strukturalne są w HTML-u wysłanym przez serwer, a szybkość mieści się w progach Core Web Vitals. Tego nie da się dobrze dołożyć po starcie, bo decyduje o tym sposób renderowania wybrany na początku projektu.

Renderowanie: co widzą Google i crawlery AI

Google przetwarza strony JavaScript w trzech fazach: pobranie, renderowanie i indeksowanie, a renderowanie czeka w kolejce. W dokumentacji JavaScript SEO Google nazywa renderowanie po stronie serwera lub pre-rendering „wciąż świetnym pomysłem” i przypomina, że nie wszystkie boty uruchamiają JavaScript. Vercel w analizie „The rise of the AI crawler” (2024) stwierdził, że żaden z głównych crawlerów AI, w tym GPTBot i ClaudeBot, nie renderował wtedy JavaScriptu. Treść widoczna tylko po uruchomieniu skryptów może więc nie istnieć dla ChatGPT czy Claude. Szerzej opisuję to w tekście o JavaScript SEO i crawlerach AI.

Dokumentacja Next.js opisuje ISR jako aktualizowanie statycznych stron bez przebudowy całego serwisu, co pozwala obsłużyć duże ilości treści bez długiego budowania. W praktyce dobieram tryb do typu podstrony, a nie jeden dla całego serwisu.

Core Web Vitals i dane strukturalne

Według web.dev strona ma dobre Core Web Vitals, gdy LCP wynosi do 2,5 s, INP do 200 ms, a CLS do 0,1, mierzone na 75. percentylu wizyt. Google zaleca osiągnięcie dobrych wyników, ale w opisie page experience zaznacza, że nie gwarantują one pozycji na szczycie, bo trafność treści jest ważniejsza. Szybkość traktuję więc jako warunek konieczny, a nie przewagę samą w sobie. Jak poprawiać poszczególne wskaźniki, piszę w poradniku o Core Web Vitals.

Dane strukturalne dają Google, jak piszą w dokumentacji, wyraźne wskazówki o znaczeniu strony i mogą włączyć wyniki rozszerzone. Google zaleca format JSON-LD. Generuję go z tych samych danych co treść strony (Organization, Product, BreadcrumbList, FAQ), więc schema nie rozjeżdża się z tym, co widzi użytkownik. Szczegóły są w przewodniku po danych strukturalnych.

Jaki CMS wybrać – WordPress, headless CMS czy Shopify

CMS wybieram według tego, kto i jak często edytuje treści oraz co strona ma robić poza wyświetlaniem tekstu. Nie ma jednego najlepszego systemu, jest system dopasowany do zespołu.

• WordPress (klasyczny) – sensowny przy prostej stronie, wielu redaktorach i małym budżecie na rozwój. Słabość: wtyczki, które spowalniają stronę i wymagają ciągłych aktualizacji bezpieczeństwa.
• Headless CMS (Sanity, Contentful) – treści edytujesz w panelu, a frontend w Next.js pobiera je przez API. Dobry wybór, gdy liczy się szybkość, wersje językowe i własne komponenty. Tak buduję większość stron firmowych.
• Shopify – gdy sprzedajesz online i chcesz mieć sprawdzony backend do produktów, płatności i zamówień. Front może zostać na motywie albo przejść na headless.
• Bez CMS – landing page pod kampanię, który zmienia się rzadko, czasem nie potrzebuje panelu. Zmiany robię wtedy w kodzie, co bywa tańsze niż utrzymanie systemu.

Przy każdym z tych wariantów pilnuję jednej zasady: treści, kod i konta (domena, hosting, CMS) należą do Ciebie. Rozstanie z wykonawcą nie może oznaczać utraty strony.

Headless Shopify – kiedy własny frontend ma sens

Headless Shopify to sklep, w którym Shopify zostaje silnikiem do produktów, płatności i zamówień, a stronę widoczną dla klienta buduje się osobno, u mnie w Next.js. Shopify opisuje to jako pełną moc platformy „pod maską” z pełną kontrolą nad frontendem.

Ma to sens, gdy motyw blokuje rozwój: potrzebujesz nietypowego UX, łączysz sprzedaż z rozbudowanymi treściami, sprzedajesz w kilku krajach albo karty produktów ładują się wolno przez aplikacje i skrypty. Nie ma sensu, gdy sklep dopiero startuje, ma kilkanaście produktów i nikt nie zmienia w nim layoutu. Wtedy lepiej zainwestować w dobry motyw i treści.

Shopify oferuje własny framework Hydrogen z hostingiem Oxygen. Ja buduję frontend w Next.js, bo w jednym projekcie łączę sklep z blogiem, headless CMS i stroną firmową. Zespół dalej pracuje w Shopify Admin, a zmienia się tylko warstwa, którą widzi klient. Szczegóły zakresu są w usłudze sklep headless Shopify.

Migracja do Next.js bez utraty pozycji w Google

Migracja do Next.js jest bezpieczna, gdy każdy stary adres ma przypisany nowy odpowiednik i przekierowanie 301, a meta, dane strukturalne i linkowanie wewnętrzne przechodzą razem z treścią. Największe spadki widzę nie przez zmianę technologii, tylko przez zgubione adresy.

Google w dokumentacji o przenoszeniu witryny zaleca przekierowania po stronie serwera ze starych adresów na nowe zgodnie z mapą, bez łańcuchów i bez kierowania wszystkiego na stronę główną. Przekierowania warto utrzymać jak najdłużej, zwykle co najmniej rok. Google uprzedza też, że w średnim serwisie wymiana adresów w wynikach może zająć kilka tygodni lub dłużej, a wahania pozycji są wtedy normalne.

1. Eksport wszystkich adresów: z mapy strony, crawla, Search Console i danych o linkach.
2. Mapa przekierowań 1:1 i decyzja, które strony scalić lub usunąć.
3. Migracja trasa po trasie, zaczynając od podstron z największym ruchem, z testami przed i po.
4. Przełączenie i monitoring: błędy 404, indeksacja i Core Web Vitals w kolejnych tygodniach.

Tak prowadzę migrację do Next.js. Jeśli zmienia się też domena lub struktura całego serwisu, opieram się na checkliście z tekstu migracja strony bez utraty pozycji.

Jak powstaje strona lub aplikacja – proces krok po kroku

Pracuję w czterech etapach: strategia i audyt, architektura informacji z makietami, development z integracjami oraz audyt SEO, QA i wdrożenie. Każdy etap kończy się czymś, co akceptujesz, zanim przejdę dalej.

• Strategia i audyt – cel strony, ścieżka klienta, dane z analityki i mierniki sukcesu. Bez tego projektuje się „ładnie”, a nie skutecznie.
• Architektura i makiety – mapa podstron, hierarchia treści, makiety do akceptacji przed napisaniem kodu.
• Development i integracje – kod w Next.js, CMS, formularze, CRM, analityka, płatności. Każda zmiana trafia na podgląd, który możesz kliknąć.
• Audyt SEO, QA i wdrożenie – metadane, dane strukturalne, testy na urządzeniach, przekierowania 301 i monitoring po starcie.

Najwięcej czasu po stronie klienta zajmuje zwykle dostarczenie treści i zdjęć. Dlatego proszę o nie na etapie makiet, a nie tydzień przed premierą.

Ile kosztuje strona internetowa i ile trwa jej budowa

U mnie landing page kosztuje od 3 000 zł, strona firmowa od 9 100 zł, migracja do Next.js od 7 300 zł, a sklep headless Shopify od 13 500 zł. Interfejsy SaaS i platformy B2B wyceniam indywidualnie, bo ich koszt zależy głównie od integracji i logiki biznesowej.

Co podnosi cenę

• Integracje – CRM, ERP, ATS, płatności. Każdy zewnętrzny system to dokumentacja, testy i obsługa błędów.
• Wersje językowe – osobne treści, hreflang i często osobne ścieżki w CMS.
• Migracja treści – przeniesienie setek wpisów i adresów z przekierowaniami to osobna praca, nie „kopiuj-wklej”.
• Niestandardowe funkcje – konfiguratory, kalkulatory, panel klienta, 3D.
• Gotowość treści – projekt bez tekstów i zdjęć wydłuża się i drożeje, bo makiety trzeba poprawiać.

Przy porównywaniu ofert patrz na całkowity koszt: hosting, licencje CMS i wtyczek, utrzymanie i koszt każdej przyszłej zmiany. Tani szablon bywa drogi w drugim roku.

Jak mierzyć efekty i utrzymać stronę po starcie

Efekty strony mierzę liczbą zapytań lub sprzedaży, ruchem organicznym i Core Web Vitals z danych rzeczywistych użytkowników, a nie samym wynikiem Lighthouse z jednego testu. Utrzymanie to aktualizacje bezpieczeństwa, monitoring i drobny rozwój, a nie tylko opłacony hosting.

• Biznes – konwersje w GA4 (formularz, telefon, zakup) i koszt pozyskania leada z kampanii.
• Widoczność – kliknięcia, wyświetlenia i zaindeksowane strony w Search Console, a coraz częściej obecność marki w odpowiedziach AI.
• Technika – Core Web Vitals z danych terenowych, błędy 404 i 5xx, czas odpowiedzi serwera.

Rok 2026 dobrze pokazuje, dlaczego utrzymanie ma znaczenie. W grudniu 2025 zespół React ogłosił krytyczną podatność w React Server Components (CVE-2025-55182, CVSS 10.0), która pozwalała na zdalne wykonanie kodu i dotyczyła m.in. Next.js. Rozwiązaniem była natychmiastowa aktualizacja. Strona bez opiekuna, który śledzi takie komunikaty, zostaje podatna, choć „przecież działa”.

Drugi temat to dostępność. Od 28 czerwca 2025 r. obowiązuje w Polsce ustawa z 26 kwietnia 2024 r. wdrażająca Europejski Akt o Dostępności, która obejmuje m.in. usługi handlu elektronicznego. Według serwisu gov.pl przepisów nie stosuje się do usług mikroprzedsiębiorców, ale większy sklep musi zadbać o dostępność cyfrową. Czy ustawa dotyczy Twojej firmy, warto potwierdzić z prawnikiem. Ja projektuję semantyczny HTML, kontrast i obsługę klawiaturą od początku, bo dorabianie tego później jest droższe.

Agencja czy freelancer – jak wybrać wykonawcę strony i jakich błędów unikać

Agencja ma sens, gdy potrzebujesz wielu ról naraz (branding, kampanie, produkcja wideo) i dużego zespołu. Niezależny specjalista sprawdza się, gdy chcesz rozmawiać bezpośrednio z osobą, która pisze kod i odpowiada za wynik. W obu przypadkach ważniejsze od formy są odpowiedzi na kilka pytań.

Pytania przed podpisaniem umowy

• Kto konkretnie będzie pisał kod i czy mogę z nim rozmawiać?
• Jak wybierzesz renderowanie i jak sprawdzisz, co widzą Google i crawlery AI?
• Kto przygotuje mapę przekierowań przy zmianie strony i na podstawie jakich danych?
• Do kogo należą kod, repozytorium, domena i konta?
• Jak wygląda utrzymanie: aktualizacje, kopie zapasowe, reakcja na podatności?
• Czy mogę zobaczyć działające projekty i ich wyniki, a nie tylko zrzuty ekranu?

Najczęstsze błędy przy zamawianiu strony

• Wybór po wyglądzie makiety – bez celu, ścieżki klienta i mierników strona jest ładna, ale nie sprzedaje.
• SEO „na później” – renderowanie, adresy i struktura nagłówków decydowane po starcie oznaczają przebudowę.
• Migracja bez mapy 301 – najszybszy sposób na utratę lat pracy nad widocznością.
• Kod i konta na wykonawcę – utrudnia zmianę firmy i bywa kartą przetargową.
• Brak budżetu na utrzymanie – nieaktualizowana strona zostaje z podatnościami i spowalnia z każdą wtyczką.
• Wtyczka do wszystkiego – każdy dodatkowy skrypt to koszt szybkości, który rzadko ktoś liczy.

Łączę role programisty Next.js i specjalisty SEO, więc architekturę i widoczność planuję razem. Jeśli masz już stronę i chcesz najpierw wiedzieć, co ją spowalnia, zacznij od audytu technicznego SEO i Core Web Vitals.