Strona internetowa w HTML — kiedy wystarczy i co się dzieje potem

Statyczna strona w HTML to najstarszy sposób na obecność w internecie i wciąż bywa poprawnym wyborem — tyle że z innych powodów, niż zwykle się je podaje. Nie dlatego, że „taniej", bo koszt takiej strony nie siedzi w budowie. I nie dlatego, że „szybciej", bo dzisiejsze systemy potrafią być równie szybkie.

Ten tekst nie uczy pisać HTML-a. Odpowiada na pytanie, które firma zadaje naprawdę: czy statyczna strona wystarczy akurat u nas, i co się stanie, kiedy przestanie wystarczać.

Kiedy statyczny HTML naprawdę wystarczy

„Statyczna" znaczy tu dokładnie jedno: każda podstrona jest osobnym plikiem, a zmiana czegokolwiek polega na otwarciu tego pliku i poprawieniu go ręcznie. Nie ma panelu, nie ma logowania, nie ma bazy danych. Jest folder z plikami na serwerze.

Cztery warunki, które muszą być spełnione jednocześnie, żeby to był dobry wybór:

Podstron jest kilka, nie kilkadziesiąt. Strona główna, oferta, o nas, kontakt. Może dwie–trzy podstrony usługowe. Przy tej skali ręczna edycja jest wykonalna.

Treść się nie zmienia. Nie „zmienia się rzadko" — nie zmienia się. Firma, która raz na dwa lata poprawia cennik, mieści się w tym warunku. Firma, która chce dodawać realizacje albo pisać aktualności, nie mieści się, nawet jeśli dziś tak jej się wydaje.

Jest jedna osoba, która umie to zrobić. Ktoś, kto otworzy plik, zmieni tekst między znacznikami i wgra go z powrotem na serwer, nie psując reszty. Jeśli tą osobą jest zewnętrzny wykonawca rozliczany za godzinę, warunek jest spełniony tylko pozornie — o tym za chwilę.

Nie potrzebujecie niczego, co zapamiętuje. Formularz, który zapisuje zgłoszenia, rezerwacja terminu, konto klienta, koszyk — każde z nich wymaga czegoś poza plikami. Statyczna strona może mieć formularz, ale obsługę tego formularza i tak dokłada ktoś z zewnątrz.

Jeśli którykolwiek z tych czterech warunków nie jest spełniony, statyczny HTML nie jest oszczędnością — jest odroczeniem kosztu.

Tak wygląda cały szkielet takiej strony. Pokazujemy go nie po to, żeby nauczyć Was pisać, tylko żebyście zobaczyli, czym w tym modelu zarządzacie:

1<!DOCTYPE html>
2<html lang="pl">
3  <head>
4    <meta charset="utf-8">
5    <title>Usługi dla firm — nazwa firmy</title>
6  </head>
7  <body>
8    <header>Telefon: 000 000 000</header>
9    <h1>Co robimy</h1>
10    <p>Opis usługi.</p>
11    <footer>NIP 000-000-00-00 · 2026</footer>
12  </body>
13</html>
Copy

To jest jeden plik, czyli jedna podstrona. Numer telefonu w nagłówku i NIP w stopce są w nim wpisane na stałe.

Czym statyczna strona nie jest

Trzy przekonania krążą wokół tego wyboru i wszystkie trzy prowadzą do złej decyzji — dwa na „tak", jedno na „nie".

Nie jest szybsza w budowie. Czas powstania strony zjadają treści, zdjęcia i decyzje, a nie technologia. Statyczna strona z Waszymi tekstami powstaje tyle samo, co ta sama strona na systemie — różnica pojawia się dopiero przy pierwszej zmianie po odbiorze.

Nie jest z definicji szybsza dla użytkownika. To był mocny argument dekadę temu. Dziś nowoczesne systemy generują strony z wyprzedzeniem i serwują gotowe pliki dokładnie tak samo — ten serwis działa właśnie w tym modelu. Nie jest to nasz wynalazek ani interpretacja: dokumentacja używanego przez nas frameworka opisuje ten tryb wprost jako serwowanie wygenerowanych wcześniej, statycznych stron na większość żądań, z możliwością odświeżenia pojedynczej strony bez przebudowy całego serwisu (Next.js, „Incremental Static Regeneration"). Statyczność sama w sobie niczego nie gwarantuje: źle przygotowane zdjęcia spowolnią stronę statyczną tak samo jak każdą inną. Jak zmierzyć to u siebie, żeby wynik coś znaczył, opisujemy w tekście o testowaniu.

Nie jest gorsza dla wyszukiwarki. To przekonanie idzie w drugą stronę i też jest nieprawdziwe. Wyszukiwarce jest obojętne, czy plik powstał ręcznie, czy wygenerował go system — czyta to samo. Problemem statycznej strony bywa co innego: brak kogoś, kto regularnie dodaje treść, bo w tym modelu każde dodanie kosztuje więcej.

Jedna rzecz działa na jej korzyść i warto ją znać: statyczna strona nie potrzebuje bazy danych ani obsługi języka po stronie serwera, więc postawicie ją na najprostszym i najtańszym hostingu, jaki znajdziecie. Nie ma też co aktualizować pod kątem bezpieczeństwa — nie ma wtyczek, które mogą się zestarzeć. To realna zaleta i jedyna, która nie zniknęła przez ostatnie dziesięć lat.

Co to znaczy w utrzymaniu — rachunek, którego nikt nie robi

Tu jest cała różnica i nie widać jej w dniu odbioru.

W systemie zarządzania treścią stopka istnieje raz. Zmieniacie w niej numer telefonu i zmienia się wszędzie, bo każda podstrona ją wywołuje, zamiast ją zawierać. W modelu statycznym stopka jest skopiowana do każdego pliku. Zmiana numeru telefonu to otwarcie dwunastu plików i poprawienie dwunastu miejsc — a właściwie dwudziestu czterech, bo numer jest jeszcze w nagłówku.

Skala tego mechanizmu robi się czytelna, gdy przyłożyć ją do czegoś konkretnego. Ten serwis ma dziś 182 artykuły i wszystkie dzielą jeden nagłówek oraz jedną stopkę. Zmiana adresu firmy to u nas jedna edycja. W modelu statycznym byłoby to 182 pliki — i nie chodzi o to, że to długo trwa, tylko że przy stu osiemdziesięciu drugim pliku ktoś się pomyli i przez pół roku nikt tego nie zauważy. Zastrzegamy uczciwie: nie prowadziliśmy statycznej strony HTML i nie mamy z niej własnego pomiaru kosztu. To ilustracja skali mechanizmu, nie wycena.

Trzy operacje, które w tym modelu kosztują nieproporcjonalnie dużo:

Dodanie podstrony. Nie wystarczy nowy plik. Trzeba go dopisać do menu w każdym istniejącym pliku, bo menu też jest skopiowane.

Zmiana czegokolwiek wspólnego. Numer, adres, rok w stopce, nowy odnośnik do polityki prywatności. Każda taka drobiazgowa zmiana mnoży się przez liczbę plików.

Zmiana wyglądu. Jeśli style są wpisane w pliki zamiast w osobny arkusz, przemalowanie przycisków to przejście przez całą stronę. Jeśli są w osobnym arkuszu — to jedna edycja i to jest właśnie ta rzecz, którą warto sprawdzić, zanim kupicie szablon.

Praktyczny wniosek: jeśli tą jedną osobą, która „umie to zrobić", jest wykonawca rozliczany godzinowo, to statyczna strona nie jest tańsza w utrzymaniu — jest tańsza tylko w budowie, a różnicę oddajecie przy każdej poprawce. Rachunek wychodzi wtedy, gdy stronę realnie zostawiacie w spokoju.

Gotowy szablon — co kupujecie, a czego nie

Gotowe szablony HTML są sensownym skrótem i warto wiedzieć, co jest w pudełku.

Kupujecie pliki, nie stronę. Szablon to zestaw plików HTML, arkusz stylów, skrypty i przykładowe obrazy. Nie ma w nim Waszych treści, Waszych zdjęć ani niczyjego panelu. Praca, która zostaje po zakupie — wstawienie własnych tekstów i zdjęć do każdej podstrony — jest zwykle większa niż praca, którą szablon zaoszczędził.

Sprawdźcie, gdzie są style. Jeśli szablon trzyma wygląd w osobnym arkuszu, późniejsze zmiany są tanie. Jeśli style są powpisywane bezpośrednio w znaczniki na każdej podstronie, kupiliście coś, czego zmiana kosztuje tyle, co napisanie od nowa. To jest jedyna rzecz, którą warto obejrzeć przed zakupem, nawet nie znając się na kodzie — wystarczy zapytać wykonawcę albo sprzedawcę wprost.

Sprawdźcie licencję. Część szablonów wolno użyć na jednej stronie, część wymaga zostawienia odnośnika do autora, część zabrania odsprzedaży. To trzy zdania do przeczytania, a różnica bywa istotna.

Sprawdźcie, co znaczy „responsywny" w tym konkretnym szablonie. Prawie każdy tak się opisuje, a różnica bywa duża: jedne przebudowują układ na telefonie sensownie, inne tylko zmniejszają wszystko proporcjonalnie, przez co tekst staje się nieczytelny, a przyciski za małe, żeby w nie trafić kciukiem. Sprawdzenie zajmuje minutę — otwórzcie demo szablonu na własnym telefonie i przejdźcie ścieżkę do kontaktu.

Policzcie pracę po zakupie. Szablon ma zwykle pięć–osiem gotowych podstron z przykładową treścią. Doprowadzenie go do stanu, w którym jest Waszą stroną, to: wstawienie tekstów, podmiana wszystkich zdjęć, usunięcie sekcji, których nie potrzebujecie, poprawienie menu, wstawienie danych rejestrowych i polityki prywatności. To jest kilka–kilkanaście godzin czyjejś pracy i warto je wycenić przed zakupem, a nie po.

Zdjęcia z demo nie są Wasze. Szablon wygląda dobrze, bo ma dobre zdjęcia — a te niemal nigdy nie są objęte licencją. Strona po podmianie na Wasze materiały wygląda inaczej i warto to założyć z góry, a nie odkryć po wdrożeniu.

I jedna rzecz, której nie róbcie. Starsze szablony i starsze poradniki podają formularz kontaktowy zbudowany na action="mailto:". To rozwiązanie nie działa u większości odwiedzających: wymaga, żeby na ich urządzeniu był skonfigurowany program pocztowy, a na telefonie i w przeglądarkowej poczcie zwykle go nie ma. Efekt jest gorszy niż brak formularza — użytkownik klika „wyślij" i nic się nie dzieje, a Wy nie wiecie, że ktoś próbował. Formularz, który faktycznie dochodzi, wymaga usługi po stronie serwera, i to jest pozycja do ustalenia przed wyborem hostingu.

Trzy przypadki, w których to jest naturalny wybór

Warunki z poprzedniej sekcji brzmią abstrakcyjnie, więc warto je przyłożyć do konkretu. Trzy sytuacje, w których statyczna strona nie jest kompromisem, tylko trafnym dopasowaniem:

Portfolio. Fotograf, architekt, grafik, stolarz. Treścią są prace, a nie teksty; zmienia się je rzadko i w całych paczkach, nie po zdaniu. Nie ma cennika, który trzeba poprawiać, ani aktualności, których nikt nie będzie pisał. Ryzyko jest jedno i warto je znać z góry: jeśli prac przybywa co miesiąc, wracacie do progu pierwszego szybciej, niż się wydaje.

Wizytówka firmy, która sprzedaje gdzie indziej. Warsztat, gabinet, lokalna usługa — klienci i tak dzwonią albo przychodzą, a strona ma potwierdzić, że firma istnieje, pokazać zakres i podać adres. Cztery podstrony, zero zmian przez rok. To jest przypadek, w którym statyczna strona wygrywa najwyraźniej, bo wszystkie cztery warunki są spełnione naraz.

Strona jednorazowa. Konferencja, konkurs, akcja sezonowa. Ma żyć trzy miesiące i zniknąć. Budowanie pod to systemu zarządzania treścią jest pracą, która nie zdąży się zwrócić.

I sytuacja odwrotna, żeby granica była ostra: sklep, blog, cokolwiek z logowaniem, oraz każda strona, którą ktoś ma regularnie uzupełniać — tam statyczny HTML jest wyborem, który trzeba będzie cofnąć, a cofanie kosztuje więcej niż zrobienie tego od razu inaczej.

Trzy progi, po których HTML przestaje się opłacać

Nie są to progi wyczucia. Każdy da się sprawdzić w pięć minut.

Próg pierwszy: dziesięć podstron. Poniżej ręczna edycja wspólnych elementów jest uciążliwa, ale wykonalna. Powyżej zaczyna się mnożenie błędów — i to nie liczba plików jest problemem, tylko to, że nikt nie pamięta, w których z nich coś już poprawił.

Próg drugi: zmiana częściej niż raz na kwartał. Jeśli ktoś w firmie chce coś zmieniać co miesiąc, model statyczny znaczy, że co miesiąc ktoś inny to za niego robi. Policzcie tę godzinę razy dwanaście i porównajcie z rocznym kosztem systemu, który pozwala zrobić to samodzielnie.

Próg trzeci: druga osoba. W momencie, w którym treść ma zmieniać ktoś jeszcze — druga osoba w firmie, stażysta, agencja — statyczny HTML przestaje być wyborem technicznym i staje się wąskim gardłem organizacyjnym. Nie da się nadać komuś dostępu do „tylko opisów usług"; można dać dostęp do wszystkich plików albo do żadnego.

Jak policzyć to u siebie, zanim ktokolwiek wystawi ofertę: wypiszcie podstrony, które strona ma mieć za rok, a nie te, które ma mieć w dniu uruchomienia — to najczęstszy błąd w tym rachunku. Potem policzcie, ile razy w ostatnim roku chcieliście coś zmienić na obecnej stronie i tego nie zrobiliście, bo było to zbyt kłopotliwe. Jeśli takich sytuacji było więcej niż dwie, próg drugi jest już przekroczony, niezależnie od tego, co pokazuje kalendarz publikacji.

Przekroczenie jednego progu jeszcze niczego nie przesądza. Przekroczenie dwóch znaczy, że liczycie oszczędność, której już nie ma.

Czy trzeba umieć kodować

Pytanie wraca w tej rozmowie regularnie i odpowiedź jest węższa, niż się wydaje.

Do napisania strony od zera — tak. Nie na poziomie programisty, ale na tyle, żeby rozumieć, co robi każdy znacznik i dlaczego przeglądarka reaguje tak, a nie inaczej. To kwestia kilkunastu godzin nauki i tysięcy godzin wprawy, jeśli efekt ma wyglądać profesjonalnie.

Do utrzymania gotowej strony — zaskakująco mało. Jeśli ktoś zbudował ją porządnie, codzienna praca sprowadza się do otwarcia pliku i zmiany tekstu między znacznikami, dokładnie tak jak w edytorze tekstu. Osoba, która nigdy nie widziała kodu, po godzinie instruktażu radzi sobie z poprawieniem numeru telefonu albo opisu usługi.

Granica przebiega w jednym miejscu i warto ją znać: zmiana treści jest bezpieczna, zmiana struktury nie. Poprawienie zdania między znacznikami nie zepsuje niczego. Dodanie nowej sekcji, przesunięcie bloku albo wklejenie czegoś skopiowanego z innej strony potrafi rozsypać układ, a przyczyna bywa niewidoczna gołym okiem — brakujący znacznik zamykający wygląda niewinnie i psuje wszystko poniżej.

Praktyczny wniosek, jeśli idziecie tą drogą: poproście wykonawcę o dwie rzeczy przy odbiorze. Po pierwsze o kopię wszystkich plików w miejscu, do którego macie dostęp — bo strona bez kopii to strona, której jedna pomyłka kasuje. Po drugie o pół godziny pokazania, co wolno ruszać, a czego nie. To jest najtańsze szkolenie, jakie w tym modelu kupicie, a zwykle nikt o nie nie prosi.

Co zrobić, kiedy próg zostanie przekroczony

To jest pytanie, którego nie zadaje się przy budowie, a ono i tak przychodzi — więc warto znać odpowiedź wcześniej, bo wtedy kilka decyzji przy starcie wygląda inaczej.

Przeprowadzka ze statycznej strony jest jedną z łatwiejszych. Nie ma bazy danych do przeniesienia, nie ma wtyczek, które trzeba odtworzyć, nie ma kont użytkowników. Jest tekst, zdjęcia i struktura adresów. To mniej, niż przenosi się przy większości migracji — i to jest realna, rzadko wymieniana zaleta tego modelu.

Co przenosi się samo: teksty i zdjęcia. Trzeba je przepisać albo skopiować do nowego systemu, ale nic nie ginie i nic nie wymaga konwersji.

Co trzeba odtworzyć: wygląd. Szablon HTML nie przekłada się na żaden system automatycznie. Jeśli zależy Wam na tym, żeby strona wyglądała tak samo, ktoś musi ten wygląd zbudować od nowa w nowym narzędziu — i to jest zwykle największa pozycja w rachunku za przeprowadzkę.

Czego nie wolno zgubić: adresów. Każda podstrona ma adres, a jeśli strona była w wyszukiwarce, te adresy mają wartość. W nowym systemie struktura zwykle wygląda inaczej i każdy stary adres potrzebuje przekierowania na nowy odpowiednik. Przekierowanie wszystkiego na stronę główną jest rozwiązaniem pozornym — wyszukiwarka czyta to jako usunięcie treści, nie jako przeprowadzkę. Jak to rozplanować, opisujemy w tekście o migracji.

Jedna decyzja przy starcie, która później oszczędza tydzień pracy: trzymajcie style w osobnym arkuszu, a nie w znacznikach, i nazywajcie pliki tak, jak chcecie, żeby brzmiały adresy — oferta.html, nie strona2.html. Pierwsze sprawia, że zmiana wyglądu jest jedną edycją zamiast przejścia przez całą stronę. Drugie sprawia, że po przeprowadzce adresy da się odwzorować jeden do jednego, zamiast wymyślać mapowanie z pamięci.

Czego ten tekst nie rozstrzyga

Ile to kosztuje. Rachunek ma dwie części i statyczna strona zmienia proporcje między nimi, a nie sumę. Pełne rozbicie jest w dziale kosztowym.

Czy da się całkiem za darmo. Da się i opisujemy to osobno, łącznie z granicą, w której darmowe się kończy.

Czy zamiast pisać, nie lepiej kliknąć. Kreator w abonamencie rozwiązuje dokładnie ten problem, który opisuje sekcja o utrzymaniu — za cenę, którą warto znać z góry: kreator stron internetowych.

Który system, jeśli nie HTML. Wybór rodziny systemu zarządzania treścią zaczyna się od pytania, kto ma zmieniać co — i ma własny tekst.

Jak przebiega cały projekt. Niezależnie od technologii: od czterech pierwszych decyzji do uruchomienia.

Skąd te liczby

• 182 artykuły w tym serwisie — nasz własny indeks treści, stan na 14 września 2026. Użyte jako ilustracja skali mechanizmu wspólnych elementów, nie jako pomiar kosztu utrzymania strony statycznej; takiej strony nie prowadziliśmy i nie mamy z niej danych.
• Trzy progi — nasza obserwacja z wdrożeń, opisana jako obserwacja. Nie badaliśmy tego liczbowo i nie podajemy odsetków ani median.
• Statyczne generowanie w nowoczesnych systemach — nie nasze twierdzenie, tylko opis z dokumentacji narzędzia, na którym stoi ten serwis: Next.js, „Incremental Static Regeneration". Przytaczamy ją dlatego, że argument „statyczna strona jest szybsza" opiera się na założeniu, które ta dokumentacja unieważnia.
• Formularz `action="mailto:"` — ograniczenie wynika z działania samego mechanizmu: przeglądarka przekazuje treść do domyślnego programu pocztowego, a jeśli takiego nie ma, nie dzieje się nic. To nie jest kwestia przeglądarki ani dostawcy.