DydlakCloud Blog

Author: dydlakcloud

  • Ile kosztuje strona internetowa w 2026 i od czego zależy cena

    Wycena strony bywa tak samo myląca jak cena mieszkania podana bez metrażu. Rozkładam ją na sześć pozycji, pokazuję, gdzie powstaje różnica między ofertami, i liczę, ile kosztuje utrzymanie strony przez trzy lata.

    Wycena nie jest ceną produktu

    Kiedy prosisz trzy firmy o wycenę strony wizytówki, dostajesz trzy liczby i zwykle ani jednego zdania o tym, co jest w środku. Wybierasz tę ze środka widełek, bo skrajne wyglądają podejrzanie. Ten wybór jest loterią, dopóki nie wiesz, co porównujesz.

    Strona internetowa nie jest produktem, który leży na półce w jednym rozmiarze. Jest usługą, a wycena jest planem pracy przeliczonym na pieniądze. Plan ma godziny, stawkę, materiały i zakres. Oferta, która pokazuje tylko sumę, zaprasza do zaufania.

    Dlatego różnica między dwiema wycenami rzadko dotyczy tej samej rzeczy. Jedna firma liczy dwanaście podstron, druga trzy. Jedna pisze teksty, druga czeka na gotowe. Jedna robi projekt od zera, druga bierze szablon i zmienia kolory. Porównujesz liczby, a powinieneś porównywać zakresy.

    Z czego składa się każda wycena

    W ofertach, które widziałem, powtarza się ten sam zestaw pozycji, choć nazwy bywają różne.

    Projekt i układ: struktura podstron, kolejność sekcji, wygląd. Treści: teksty, zdjęcia, opisy usług, odpowiedzi na pytania klientów. Wdrożenie: złożenie strony, konfiguracja, podłączenie formularza, testy na telefonie, publikacja. Te trzy pozycje są jednorazowe i odpowiadają za większość ceny.

    Pozostałe trzy wracają co roku: domena, hosting i utrzymanie. W pierwszym rachunku są małe i łatwe do przeoczenia. W trzecim roku rozstrzygają o tym, ile strona naprawdę kosztuje.

    Z tego podziału wynika jedna praktyczna rzecz. Każdą ofertę da się sprawdzić, pytając o godziny: ile na projekt, ile na teksty, ile na wdrożenie. Firma, która pracuje uczciwie, te godziny zna. Firma, która ich nie zna, wycenia na wyczucie i w połowie projektu wraca z dopłatą.

    Godziny razy stawka

    Do takiej rozmowy potrzebny jest punkt odniesienia. Zacznę od najprostszego, jaki jest publicznie dostępny.

    GUS podał 20 października 2026 roku, że przeciętne miesięczne wynagrodzenie brutto w sektorze przedsiębiorstw wyniosło we wrześniu 2026 roku 9266,48 zł (informacja sygnalna GUS, dane dla firm zatrudniających dziesięć i więcej osób, z premiami w środku). Podzielone przez 168 godzin, czyli przeciętny miesiąc pracy, daje 55,16 zł brutto za godzinę. To moje przeliczenie na danych GUS, nie stawka z żadnego cennika.

    Ta liczba nie jest stawką na fakturze. Faktura pokrywa też składki, biuro, księgowość, czas na rozmowy i poprawki, których nikt nie wpisał w plan. Działa jako podłoga: jeśli wycena zakłada czterdzieści godzin pracy, te godziny gdzieś kosztują.

    Drugi punkt odniesienia jest twardszy, bo ustawowy. Od 1 stycznia 2026 roku minimalna stawka godzinowa przy umowie zlecenia wynosi 31,40 zł (rozporządzenie Rady Ministrów z 11 września 2025 roku, Dz.U. 2025 poz. 1242, paragraf 2). Oferta, w której godzina pracy człowieka wychodzi taniej, opiera się na pracy, której ktoś nie wykonał, albo na kosztach przeniesionych w miejsce, którego nie widzisz.

    Rachunek na przykładzie, nie na badaniu rynku. Strona wizytówki z sześcioma podstronami, teksty po stronie wykonawcy, jedno spotkanie, publikacja: dwanaście godzin projektu, dziesięć godzin tekstów, szesnaście godzin wdrożenia i cztery godziny testów dają czterdzieści dwie godziny. Przy 55,16 zł za godzinę to 2316,72 zł samej pracy, przed domeną, hostingiem i marżą. Jeśli oferta na taki zakres jest o połowę niższa, albo zakres jest mniejszy, niż myślisz, albo godziny policzono po stawce, przy której nikt nie wyżyje.

    Treści, czyli pozycja, której nie ma w ofercie

    Największa różnica między tanimi i drogimi stronami nie siedzi w kodzie. Siedzi w tekście.

    Strona wizytówki ma kilka podstron, a każda z nich potrzebuje tekstu długości kilkuset słów. Ktoś musi je napisać, a potem ktoś musi sprawdzić, czy odpowiadają na pytania, które klient naprawdę zadaje. W taniej ofercie teksty prawie zawsze są po Twojej stronie, w rubryce, której nie czytasz do dnia, w którym trzeba zacząć. Wtedy okazuje się, że masz napisać osiem stron o własnej pracy, więc ląduje tam to, co było w starej ulotce.

    Wycena z tekstami jest droższa o kilkanaście godzin pracy i ta różnica jest realna. Ktoś siada, wypytuje Cię o usługi, spisuje odpowiedzi, układa je w kolejności, w której klient czyta, i pilnuje, żeby na stronie była odpowiedź o cenę, termin i obszar działania.

    Pytanie do wykonawcy jest więc proste: kto pisze teksty i ile ich jest w tej cenie. Odpowiedź powinna być w umowie, nie w prezentacji.

    Domena i hosting: koszt, który wraca co roku

    Domena .pl nie jest kupowana raz na zawsze, choć tak wygląda w pierwszym rachunku. W cenniku HitMe z października 2026 roku rejestracja kosztuje 18,45 zł brutto, a odnowienie 67,00 zł brutto za rok. Pierwszy rok jest tani, drugi i trzeci już nie.

    Hosting wygląda podobnie. cyber_Folks w cenniku usług hostingowych podaje dla pakietu cyber_START! 279 zł netto za rok odnowienia, czyli 343,17 zł brutto, i zastrzega, że są to ceny regularne, bez promocji. Rachunek na trzy lata: domena 18,45 plus 67 plus 67 daje 152,45 zł, hosting trzy razy 343,17 daje 1029,51 zł. Razem 1181,96 zł brutto, czyli 32,83 zł miesięcznie i równowartość 21,4 godziny pracy przy stawce 55,16 zł.

    Koszty stałe strony są małe w porównaniu z jednorazowym kosztem jej zrobienia. Kłopot zaczyna się gdzie indziej: liczba w pierwszym roku bywa inna niż w drugim, a decyzję podejmujesz na trzy lata, nie na dwanaście miesięcy.

    Ten sam cennik pokazuje to bez owijania. cyber_SPRINT! kosztuje 9 zł netto za pierwsze trzy miesiące, czyli 11,07 zł brutto, a odnowienie roczne to 449 zł netto, czyli 552,27 zł brutto. Oba warianty są w cenniku obok siebie i oba są prawdziwe. Strona, która ma przetrwać trzy lata, płaci po pierwszym okresie pełną stawkę, więc porównuj cenę odnowienia, a nie cenę wejścia.

    Osobna sprawa, którą łatwo przegapić: abonentem domeny powinna być Twoja firma, a nie wykonawca. Wpisanie nazwy domeny w whois zajmuje chwilę i od razu pokazuje, kto tam stoi. Jeśli nie Ty, masz problem do rozwiązania przed podpisaniem umowy, a nie po zakończeniu współpracy.

    Utrzymanie: abonament, godziny albo nic

    Trzecia pozycja cykliczna to utrzymanie. Tu oferty różnią się najbardziej, bo to samo słowo oznacza trzy różne rzeczy.

    W modelu abonamentowym płacisz stałą kwotę miesięcznie i ktoś pilnuje aktualizacji, kopii zapasowych, certyfikatu i tego, czy strona odpowiada. W modelu godzinowym dzwonisz, gdy coś się dzieje, i płacisz za wykonaną pracę. W trzecim nie płacisz nic, dopóki strona działa, a potem płacisz za naprawę.

    Każdy z tych modeli ma sens w innym przypadku. Strona wizytówki, która nie zmienia się od miesięcy, nie potrzebuje miesięcznego abonamentu tylko dlatego, że ktoś go oferuje. WordPress z wtyczkami i formularzami potrzebuje kogoś, kto raz w miesiącu sprawdzi wersje, bo wtyczka porzucona dwa lata temu jest dziurą, a nie ozdobą.

    Koszt braku utrzymania nie pojawia się w cenniku, bo jest rozłożony w czasie. Wersja PHP na serwerze rośnie sama, certyfikat wygasa, kopia zapasowa okazuje się nie działać w dniu, w którym jest potrzebna. Wniosek jest skromniejszy niż abonament u każdego: trzeba wiedzieć, kto ma tę robotę wpisaną w obowiązki.

    Czego cena nie obejmuje

    Nawet dobra wycena nie obejmuje kilku rzeczy, które doliczasz po swojej stronie.

    Budżetu na reklamę i dystrybucję. Strona bez ruchu nie przynosi zapytań, a nowa domena zbiera zaufanie w wyszukiwarce miesiącami. Zdjęć, jeśli potrzebujesz sesji, a nie fotografii z telefonu. Integracji, jeśli formularz ma wpadać do CRM-a albo kalendarz ma pokazywać wolne terminy. Poprawek po publikacji, bo pierwsza wersja zawsze coś odsłania. Twojego czasu na zebranie informacji, zatwierdzenie tekstów i decyzję o zdjęciach.

    Do tego dochodzi rzecz, której nie kupisz za żadne pieniądze: witryna nie zamknie sprzedaży za Ciebie. Klient kupuje to, co stoi w ofercie i w cenie, a domyka zakup dopiero wtedy, gdy ktoś odbierze telefon. Strona może ten kontakt ułatwić albo go zepsuć, chowając numer za pięcioma przewinięciami.

    Jak porównać dwie oferty w piętnaście minut

    Poniżej sześć pytań, które zadawałem w obie strony, jako wykonawca i jako klient. Za każdym razem wychodziło coś, czego nie było w prezentacji.

    1. Ile godzin jest w tej wycenie i na co. Poproś o podział na projekt, teksty i wdrożenie.
    2. Co wchodzi w zakres: ile podstron, ile tekstów, czyje zdjęcia, jakie integracje.
    3. Kto pisze teksty i kto je poprawia po Twoich uwagach.
    4. Na kogo jest zarejestrowana domena i kto ma dostęp do panelu.
    5. Co się dzieje po pierwszym roku: ile kosztuje odnowienie hostingu i czy opieka jest w cenie.
    6. Ile kosztuje zmiana po publikacji: stawka godzinowa, abonament czy „drobna zmiana gratis”.

    Szóste pytanie najczęściej nie pada, bo wydaje się nieuprzejme. Rozstrzyga o tym, czy za rok zmienisz numer telefonu na stronie bez trzech maili.

    Po tych pytaniach widać, czy masz do czynienia z innym zakresem, czy z inną ceną za ten sam zakres. W pierwszym przypadku wybierasz zakres, w drugim wykonawcę. To dwie różne decyzje i mieszanie ich kończy się rozczarowaniem.

    Jeśli po tym rachunku wychodzi, że stronę trzeba zrobić od zera, a nie poprawiać, w Sitehero nie musisz liczyć godzin po swojej stronie: podajesz adres obecnej witryny albo odpowiadasz na kilka pytań w formularzu, a układ, teksty i publikację bierzemy na siebie. Gotowa strona wychodzi w ciągu jednego do dwóch dni roboczych, domena jest rejestrowana na Twoją firmę i zostaje u Ciebie, a zmiany po starcie wprowadzamy po jednej wiadomości.

  • PHP2Shell: dziura siedzi w PHP, nie w twojej stronie

    21 października 2026 roku PHP dostało poprawkę na dwie luki, które pozwalają uruchomić dowolny kod na serwerze bez logowania. Nie ma ich w WordPressie, w motywie ani w żadnej wtyczce. Siedzą w samym PHP, czyli w warstwie pod stroną, a to zmienia charakter zadania: to nie decyzja o rozwoju serwisu, tylko konserwacja z terminem.

    Co ogłoszono 21 października

    Dwie luki, CVE-2026-109618 i CVE-2026-109619, nazwane razem PHP2Shell. Obie mają 9,2 w CVSS w wersji 4.0. Tyle nadało im PHP w biuletynie, nie marketing producenta zabezpieczeń. Poprawki wyszły w czterech wydaniach: 8.5.12, 8.4.27, 8.3.36 i 8.2.35.

    CERT-EU opisało sprawę jako Security Advisory 2026-018 i podało godzinę wydania, 13:30 UTC. CISA wydała alert tego samego dnia i napisała wprost, że do momentu publikacji nie zaobserwowała wykorzystania. Cloudflare w swoim wpisie z 21 października pisze coś innego: że widział ruch atakujący jego klientów i że atakujący modyfikowali payload, żeby obejść reguły. Jedno i drugie może być prawdą naraz, bo „nie zaobserwowała” znaczy tyle, co „nie mamy potwierdzonego przypadku”, a nie „nikt nie próbował”. Fundacja PHP dokłada trzeci fakt: w chwili wydania nie znała działającego exploita, natomiast koncepcje ataku krążyły już publicznie.

    Numery CVE wyciekły 20 października po południu, a PHP przyspieszyło wydanie o dobę. Od wycieku do łatki minęło mniej niż dwadzieścia cztery godziny.

    Biuletyn wymienia PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Najwyższe ryzyko dotyczy mod_php, bo tam udało się pokazać atak dziejący się przed uruchomieniem kodu aplikacji.

    Na czym polega błąd

    PHP ogranicza pamięć żądania przez memory_limit. Kiedy limit zostaje przekroczony, PHP nie wraca z błędem po stosie wywołań, tylko przerywa wszystko mechanizmem longjmp(), czyli skokiem poza bieżący kontekst. To szybkie i sprawdzone rozwiązanie, dopóki nie trafi w moment, w którym jakaś struktura danych jest zbudowana do połowy. Wtedy PHP porzuca pracę bez sprzątania, a chwilę później uruchamia zwykłą procedurę zamykania żądania, która zakłada, że wszystko jest spójne.

    CVE-2026-109618 to właśnie ta sytuacja: dane, których nikt nie zainicjalizował, są czytane jak poprawne. CVE-2026-109619 idzie o krok dalej. Stan należący do jednego żądania zostaje w pamięci workera po zwolnieniu tej pamięci, a kolejne żądanie obsłużone przez ten sam proces sięga po te bajty, zanim normalna inicjalizacja je nadpisze. Biuletyn wymienia konkretne ścieżki: stan błędów, sesji, obiektów i rozszerzeń. Jedna z nich to obsługa postępu uploadu (session.upload_progress), włączona domyślnie, bez potrzeby wywołania session_start() w kodzie.

    Do pierwszego błędu wystarczy żądanie multipart, które na papierze mieści się w limitach. Biuletyn podaje trzy sposoby: żądanie bez użytego Content-Length przechodzi wstępne sprawdzenie post_max_size i dalej dosyła treść; część multipart może mieć nieograniczoną liczbę nagłówków, których reprezentacja w pamięci jest większa niż na łączu; puste pola plikowe nie liczą się do max_file_uploads, ale i tak tworzą tablice metadanych, a zagnieżdżone nazwy pól mnożą tę pracę.

    Dlaczego wtyczka tego nie załata

    I tu jest sedno: PHP parsuje żądanie przed inicjalizacją rozszerzeń i przed skompilowaniem pierwszej linii kodu aplikacji. Kiedy atak się dzieje, WordPress jeszcze nie istnieje w pamięci procesu. Nie ma wtyczki, nie ma motywu, nie ma functions.php. Jest interpreter, który przetwarza dane wejściowe.

    Dlatego strona pisana przez bardzo dobrego programistę jest narażona dokładnie tak samo jak strona zaniedbana. Aktualizacja WordPressa, wtyczek i motywu, choć zawsze sensowna, w tym przypadku nic nie zmienia.

    Jest jednak różnica między konfiguracjami, bo wpływa na to, co zobaczysz w logach. Apache z mod_php wywołuje procedurę zamykania żądania nawet wtedy, gdy start żądania się nie powiódł, i to otwiera drogę opisaną w biuletynie jako potwierdzoną. FPM kończy proces potomny, gdy start żądania zawiedzie, więc ta konkretna ścieżka nie przechodzi. Nie znaczy to, że FPM jest bezpieczny: biuletyn opisuje potwierdzoną ścieżkę na FPM, w której stan publikowany jest w trakcie działania aplikacji, a konsumentem jest obsługa postępu uploadu przy kolejnym żądaniu. FrankenPHP i LSAPI są prawdopodobnie podatne, choć bez potwierdzonego ataku.

    Gdzie w tym jest twoja strona

    W3Techs, w odczycie z 22 października 2026, podaje, że PHP używa 69,3% stron, których język po stronie serwera da się rozpoznać. Podział na wersje wśród stron na PHP wygląda tak: 8.x to 65,3%, 7.x to 26,9%, 5.x to 7,7%, 4.x to 0,1%.

    Arytmetyka, którą możesz powtórzyć: 26,9 + 7,7 + 0,1 = 34,7. Ponad jedna trzecia stron na PHP działa na gałęzi, dla której projekt nie wyda już łatki. Dla 7.4, 8.0 i 8.1 zespół bezpieczeństwa opublikował minimalne backporty źródeł, ale to kod do samodzielnego zbudowania, nie pakiet od hostingu.

    Druga rzecz, której właściciele stron często nie widzą: PHP siedzi też w sklepach, w panelach hostingowych, w interfejsach urządzeń sieciowych i w oprogramowaniu, które dostarcza firma zewnętrzna razem ze sprzętem. CERT-EU odsyła w tym miejscu do repozytorium NCSC-NL, które zbiera produkty z wbudowanym PHP. Jeśli w firmie jest kamerka z panelem albo stare urządzenie do backupu, to też jest PHP i też ma wersję.

    Jak wygląda łatka od strony serwera

    Najczęstszy błąd przy sprawdzaniu: php -v w SSH pokazuje wersję interpretera linii poleceń, a strona odpowiada przez inny pakiet, zwykle php-fpm albo moduł Apache. Sprawdzać trzeba to, co realnie obsługuje żądania HTTP: przez phpinfo(), panel hostingu albo polecenie, które pyta usługę, a nie powłokę.

    Sama podmiana pakietu nie wystarczy bez restartu. Działające procesy robocze trzymają w pamięci stary kod i będą go wykonywać do końca życia procesu, więc po aktualizacji restartuje się FPM albo Apache. W kontenerach podmiana pakietu wewnątrz działającego kontenera jest obejściem, poprawna droga to nowy obraz bazowy i nowe kontenery.

    Ile to zajmuje i ile kosztuje

    Liczby w tym akapicie są przykładem, nie benchmarkiem. Jedna strona: sprawdzenie wersji, zrzut, aktualizacja pakietu, restart, test formularza kontaktowego. Przy wprawie dwadzieścia pięć minut. Osiemnaście stron, czyli portfel małej agencji: 18 × 25 = 450 minut, czyli 7,5 godziny. Jeden dzień pracy jednej osoby, którą trzeba mieć.

    Koszt zaniechania trudniej policzyć, więc policzmy jedną jego część. Sklep, osiem godzin niedostępności, trzy zamówienia na godzinę, średnia wartość zamówienia 240 złotych: 8 × 3 × 240 = 5760 złotych. To strata widoczna w raporcie. Niewidoczna jest inna: jeśli atakujący dostanie powłokę z uprawnieniami użytkownika serwera WWW, ma dostęp do pliku konfiguracyjnego z danymi bazy, do katalogu z kopiami zapasowymi, jeśli ktoś je tam zostawił, i do wszystkiego, co aplikacja może przeczytać.

    Nie napiszę, że twoje dane wyciekły, bo tego nie wiem i nie wiem tego bez twoich logów. Wiem, co się robi po takim zdarzeniu i w jakiej kolejności, a to część, którą można zaplanować zawczasu: odcięcie serwera od sieci z zachowaniem kopii, zabezpieczenie logów serwera WWW i PHP, przegląd katalogu pod kątem nowych plików, przegląd zadań cron i kont, zmiana wszystkich poświadczeń, które leżały na tej maszynie.

    Co zrobić, jeśli nie możesz załatać dziś

    Zacznij od tego, co biuletyn nazywa środkami tymczasowymi, i przyjmij do wiadomości, że żaden z nich nie jest rozwiązaniem. Dla CVE-2026-109618 pierwszy krok to memory_limit=-1 ustawione tak, żeby aplikacja nie mogła go nadpisać, przez php_admin_value w puli FPM albo w konfiguracji Apache, z restartem workerów i sprawdzeniem, że żadna pula ani katalog nie przywraca skończonego limitu. Do tego post_max_size 8M, jeśli nie ma uploadów, 32M, jeśli są, z upload_max_filesize ustawionym niżej. Na froncie dorzuć limity liczby pól, części multipart, nagłówków i głębokości zagnieżdżenia, także dla żądań bez Content-Length. Kontener albo cgroup jako granica dostępności, ale nie RLIMIT_AS ani RLIMIT_DATA, bo te wywołują dokładnie ten błąd alokacji, którego szukasz.

    Dla CVE-2026-109619 wyłącz session.upload_progress.enabled w php.ini, w puli FPM albo w konfiguracji serwera, czyli tam, gdzie zadziała przed parsowaniem żądania, a nie przez ini_set(). Na PHP 8.5 dołóż fatal_error_backtraces=0. Biuletyn mówi wprost, że dla tej luki nie ma kompletnego środka konfiguracyjnego, bo stan może publikować aplikacja, rozszerzenie albo serwer, i nie zostawi po tym przewidywalnego wpisu w logu.

    Jest też koszt, o którym trzeba powiedzieć głośno: memory_limit=-1 przenosi problem z bezpieczeństwa na dostępność. Skrypt, który wcześniej padał po wyczerpaniu limitu, teraz zje pamięć maszyny. To trade-off, nie magiczne rozwiązanie.

    Czego to nie rozwiązuje

    Firewall aplikacyjny nie łata PHP. Cloudflare wdrożył ochronę 21 października od 03:02 UTC, dla wszystkich planów z WAF, także darmowego, i przyznaje, że dane żądania nie wystarczały do odróżnienia ataku od normalnego ruchu, dlatego powstała funkcja łącząca sygnały z żądania i z odpowiedzi serwera źródłowego. Kto ma domenę za Cloudflarem, z regułami w trybie blokowania, ten ma ochronę. Kto trzyma tam tylko DNS, bez proxy, ten nie ma nic, bo ruch nie przechodzi przez ich sieć.

    Monitoring nie cofa włamania. Łatka nie usuwa tego, co już leży na dysku. Backport na gałąź po końcu wsparcia jest obejściem, które trzeba będzie powtórzyć przy następnej luce, a przy okazji zwykle okazuje się, że nikt nie pamięta, jak się go budowało.

    Jest jeszcze kwestia, którą Fundacja PHP opisała sama, bez wygładzania. Pierwsze oznaki problemu z pamięcią znalazł programista PHP w 2024 roku, przy naprawianiu innego zgłoszenia z audytu Quarkslab. Zespół bezpieczeństwa przez wiele miesięcy nie umiał wybrać między rozwiązaniami, bo każde łamało coś innego, a decyzje podejmowano konsensusem. Fundacja nazywa to porażką strukturalną. Wersja, którą masz na serwerze, powstała w projekcie, w którym naprawa poważnego błędu potrafi czekać dwa lata. Argumentem za zmianą technologii to nie jest. Argumentem za własnym terminem reakcji jest.

    Lista kontrolna na dziś

    1. Sprawdź wersję PHP, którą widzi serwer WWW, nie tę z SSH.
    2. Jeśli twoja gałąź to 8.2, 8.3, 8.4 albo 8.5 i wersja jest niższa niż 8.2.35, 8.3.36, 8.4.27 albo 8.5.12, załatuj.
    3. Zrestartuj workery FPM albo Apache po aktualizacji.
    4. Kontenery przebuduj z nowego obrazu bazowego, nie restartuj starych.
    5. Na 8.1 i starszych podejmij decyzję: migracja albo izolacja od internetu, plus backport, jeśli budujesz ze źródeł.
    6. Sprawdź, czy domena jest proxowana przez WAF i czy reguły są w trybie blokowania, a nie tylko logowania.
    7. Zapisz, kto to zrobił, kiedy i na jakiej wersji skończył, bo następny biuletyn przyjdzie i ta kartka będzie jedyną odpowiedzią na pytanie „jak było ostatnio”.

    Siódma pozycja jest zwykle tą, której nikt nie robi, bo po restarcie wszystko działa i temat znika z głowy do następnego razu. Cała reszta zależy od osoby, która ma w obowiązkach czytanie biuletynu, sprawdzenie wersji na każdym serwerze i wykonanie tego w oknie doby, a nie wtedy, gdy znajdzie się chwila. W dydlak.cloud robię dokładnie to: monitoring wersji na stronach, których pilnuję, wdrożenie łatki w ciągu doby od publikacji biuletynu i raport dla właściciela firmy napisany tak, żeby dał się przeczytać bez słownika. Jeśli u ciebie ta osoba nie ma imienia, mogę nią być.

  • Strona internetowa w 2026: dlaczego Instagram jej nie zastąpi

    Kilka razy w tym roku usłyszałem to samo zdanie: sprzedaż i marketing przeniosły się do social mediów, więc strona internetowa jest już niepotrzebna. Ta opinia ma sensowną podstawę, ale prowadzi do złego wniosku. Profil i strona robią dwie różne rzeczy, a w 2026 roku doszła trzecia: asystenci AI, którzy odpowiadają na pytania klientów i biorą treść z tych samych stron.

    W czym ta opinia ma rację

    Salon kosmetyczny w mieście powiatowym potrafi zrobić pełny grafik z Instagrama. Zdjęcia efektów, relacje z pracy, rezerwacje w wiadomościach. Właścicielka, która mówi „mam komplet klientek z Instagrama”, nie opowiada historii marketingowej, tylko opisuje swój tydzień.

    Kłopot zaczyna się wtedy, gdy z jednego działającego przypadku robi się regułę dla wszystkich branż. Instagram działa tam, gdzie usługa jest wizualna, a klient już wie, kogo szuka, albo przynajmniej chce obejrzeć kilka kont i wybrać. Nie działa tam, gdzie klient ma problem i nie zna nazwy firmy, która go rozwiąże: cieknący zawór, rozliczenie najmu, balustrada na wymiar, sala na wesele na sto dwadzieścia osób. W tych kategoriach zapytanie nie zaczyna się od przeglądania rolek.

    Jest jeszcze drugi powód, dla którego ta opinia brzmi przekonująco. Właściciel firmy widzi na własne oczy, że post z Instagrama przyniósł trzy zapytania, a strona przez miesiąc nie przyniosła żadnego. To prawda, tylko dotyczy strony, której nikt nie aktualizował od 2019 roku i która nie odpowiada na żadne pytanie wpisywane w wyszukiwarkę. Zepsuta strona jest gorsza od braku strony, bo przekonuje właściciela, że wszystkie strony są zepsute.

    Najem czy własność

    Mechanika feedu wyjaśnia więcej niż jakiekolwiek porównanie zasięgów. Post nie trafia do wszystkich obserwujących. Trafia do tej części, którą system uzna za najbardziej zainteresowaną, a reszta go nie zobaczy, dopóki nie zapłacisz za wyświetlenia. Konto firmowe nie jest kanałem, w którym wysyłasz wiadomość do swojej listy. Jest licytacją, w której platforma decyduje, kto zobaczy treść, a budżet reklamowy jest stałą częścią kosztu dotarcia do klienta.

    Do tego dochodzi kwestia własności, o której łatwo zapomnieć, dopóki coś się nie stanie. Konto może zostać ograniczone po błędzie w weryfikacji, zablokowane po fałszywym zgłoszeniu albo zamknięte bez wyjaśnienia. Jeśli cała komunikacja firmy stoi na profilu, tego dnia firma traci kanał sprzedaży i nie ma kopii treści ani rozmów z klientami. Strona na własnej domenie zachowuje się inaczej: domena jest zarejestrowana na firmę, pliki są na hostingu, a kopię można przenieść do innego dostawcy w jeden dzień.

    Dane GUS mówią to samo. W 2025 roku własną stronę internetową miało 67,5% przedsiębiorstw, a konto w mediach społecznościowych 47,8%. To dane dla firm zatrudniających co najmniej dziesięć osób, więc mikroprzedsiębiorcy nie są w nich ujęci. Kierunek jest jednak wyraźny: firm ze stroną jest więcej niż firm z profilem, więc teza o social mediach, które zastąpiły strony, nie trzyma się danych. Social doszedł obok strony, a nie w jej miejsce.

    Czego na profilu nie zrobisz

    Zostać znalezionym przez kogoś, kto nie zna nazwy firmy. Wyszukiwarka w Instagramie dopasowuje konta po nazwie, opisie i hashtagach. Wyszukiwarka internetowa przyjmuje zapytanie „hydraulik Rybnik cena” i zwraca strony, które na to pytanie odpowiadają. To dwie różne funkcje i dwie różne intencje.

    Pokazać ofertę z warunkami. Zakres usług, widełki cenowe, czas realizacji, obszar działania, sposób płatności, odpowiedzi na pytania, które klient zadaje przez telefon. Na profilu to wszystko ląduje w opisie i przypiętych relacjach, gdzie mało kto to czyta, a robot wyszukiwarki nie ma czego zaindeksować.

    Zebrać zapytanie w formie, którą da się obrobić. Formularz daje komplet danych w jednej wiadomości: czego klient potrzebuje, na kiedy i jak się z nim skontaktować. Rozmowa w wiadomościach prywatnych rozjeżdża się na dziesięć wiadomości i często kończy się bez odpowiedzi, bo klient w międzyczasie napisał do dwóch innych firm.

    Do tego dochodzi coś, czego profil nie ma: stały adres, który można komuś wysłać. Posty znikają z zasięgu po dwóch dniach, a odpowiedź na pytanie „czy dojeżdżacie do Gliwic” chce się mieć w jednym miejscu, do którego prowadzi wizytówka Google, mail i SMS od klienta.

    Zapytanie trafia do Google i do asystenta AI

    Google podaje, że w ciągu roku obsługuje biliony zapytań. To liczba z ich własnej strony opisującej, jak działa wyszukiwarka, i przez ostatnie lata się nie zmieniła. Obok klasycznych wyników doszły AI Overviews i tryb AI Mode, a poza Google zapytania dostają ChatGPT, Copilot, Gemini i Perplexity.

    Wszystkie te odpowiedzi powstają w podobny sposób, a Google opisuje go wprost w poradniku dla właścicieli stron. System pobiera z indeksu pasujące, aktualne strony (retrieval-augmented generation, w skrócie RAG, nazywane też ugruntowaniem), a następnie układa na ich podstawie odpowiedź i pokazuje klikalne linki do źródeł. Z tego wynikają dwa wnioski, których nie da się obejść. Strona, której nie ma w indeksie, nie może być źródłem odpowiedzi. Strona, która jest w indeksie, ale nie odpowiada na pytanie, też nie zostanie wybrana, bo model nie wymyśli Twojej oferty. Weźmie ją z tekstu, który ktoś napisał.

    Praktyczna konsekwencja jest taka, że w miejscu, gdzie klient wysyła zapytanie, coraz częściej widać odpowiedź, a nie dziesięć niebieskich linków. Ta odpowiedź ma źródła, a źródła to strony. Jeśli chcesz być w niej wymieniony, musisz być jedną z tych stron.

    ChatGPT działa według tej samej logiki, z własnym botem. OpenAI utrzymuje OAI-SearchBot, który pobiera strony pokazywane w wynikach wyszukiwania w ChatGPT, i zaznacza w dokumentacji, że strona blokująca tego bota w robots.txt nie pojawi się w odpowiedziach, choć może zostać pokazana jako link nawigacyjny. Blokowanie botów AI bywa odruchem, ale w praktyce jest wypisaniem się z kanału, który rośnie. Jeśli celem jest zablokowanie treningu, a nie wyszukiwania, to dwie osobne decyzje: GPTBot i OAI-SearchBot.

    Skala jest na razie mała i lepiej powiedzieć to od razu. W Polsce asystenci AI to jeszcze margines ruchu. W 2025 roku z narzędzi generatywnej AI korzystało w ciągu ostatnich trzech miesięcy 22,7% osób w wieku 16-74 lat, przy 32,7% średnio w Unii Europejskiej (Eurostat, zbiór isoc_ai_iaiu). W grupie 16-24 lata w Polsce było to 49,3%. Nikt nie zbuduje na tym dzisiejszej sprzedaży. Sens jest inny: asystenci czytają dokładnie te treści, które już pozycjonujesz w Google. Jedna praca obsługuje dwa kanały, a młodsza część rynku wchodzi w ten kanał szybciej niż reszta.

    Mitów wokół AI jest więcej niż faktów. Google w tym samym poradniku pisze, że poza indeksacją i standardowym SEO nie ma osobnych wymagań technicznych dla funkcji AI, a krążące po sieci sztuczki (dzielenie tekstu na fragmenty, plik llms.txt, zabieganie o wzmianki w przypadkowych miejscach) można pominąć. Jest za to jedno ustawienie w Search Console, które decyduje o tym, czy treści w ogóle kwalifikują się do pokazania w funkcjach AI. Skrótu nie ma. Jest strona, która odpowiada na pytania lepiej niż konkurencja.

    Jak wygląda strona, która pracuje

    Wersja mobilna jest wersją główną, bo Google indeksuje i pozycjonuje stronę na podstawie wersji pobranej telefonem. Wersja desktopowa może być piękna, ale to nie ona decyduje o wyniku.

    Szybkość ma publiczne progi, więc nie trzeba wierzyć nikomu na słowo: LCP poniżej 2,5 sekundy, INP poniżej 200 milisekund, CLS poniżej 0,1, liczone dla 75. percentyla odwiedzin. Jeśli strona się w nich nie mieści, traci ruch i część zapytań, niezależnie od tego, jak wygląda na zdjęciach w portfolio.

    Treść odpowiada na konkretne pytania. Osobna sekcja dla każdej usługi, miasto w tekście, widełki cenowe, czas realizacji, FAQ z pytaniami, które klient naprawdę zadaje przez telefon. Z tego materiału korzysta wyszukiwarka i z tego samego asystent AI.

    Wezwanie do działania jest widoczne od razu: telefon klikalny, przycisk z rezerwacją terminu, formularz na dwie minuty. Na telefonie w zasięgu pierwszego ekranu, nie po pięciu przewinięciach.

    Strona jest połączona z wizytówką Google. Profil firmy w Mapach prowadzi do strony, a strona do profilu. Bez tego wyniki lokalne pokazują firmę, ale po kliknięciu nie mają czego pokazać.

    Ile to kosztuje i czego strona nie zrobi

    Rachunek na jednej liczbie. Jeśli na reklamy w social mediach wydajesz 600 złotych miesięcznie, rocznie jest to 7200 złotych, a przez trzy lata 21 600 złotych, i po trzech latach nie zostaje z tego nic poza historią kampanii. Strona kosztuje raz, a potem domena i hosting, więc koszt zdobycia kontaktu spada z każdym miesiącem, w którym działa. Reklama nie jest zła i bez płatnego zasięgu nowa strona długo nie zbierze ruchu. Chodzi o proporcję: płatny zasięg powinien prowadzić na stronę, która zamienia odwiedziny w zapytania, a nie być jedynym miejscem, w którym firma istnieje.

    Lista rzeczy, których strona nie zrobi, jest krótka. Znać ją trzeba przed rozmową z kimkolwiek, kto sprzedaje strony.

    • Nie sprzeda sama. Sprzedaje oferta, cena i rozmowa z człowiekiem.
    • Nie zastąpi social mediów. Dystrybucja treści nadal dzieje się tam, gdzie są ludzie.
    • Nie naprawi złej oferty ani ceny oderwanej od rynku.
    • Nie przyniesie ruchu bez treści i bez czasu. Nowa domena zbiera zaufanie miesiącami, nie w tygodniach.
    • Nie zagwarantuje pierwszej pozycji. Nikt tego nie może, a kto obiecuje, ten albo nie rozumie, jak działa wyszukiwarka, albo liczy na to, że klient nie sprawdzi.

    Pięć rzeczy do sprawdzenia w piętnaście minut

    1. Otwórz stronę na telefonie z wyłączonym Wi-Fi i zmierz, ile trwa, zanim zobaczysz treść.
    2. Sprawdź, czy numer telefonu i przycisk z rezerwacją widać bez przewijania.
    3. Wpisz w Google nazwę usługi i miasto. Zobacz, czy jesteś w trójce wyników lokalnych i czy Twoja strona pojawia się w linkach.
    4. Zapytaj ChatGPT albo Gemini o trzy firmy z Twojej branży w Twoim mieście i sprawdź, czy Cię wymienia.
    5. Wejdź w Search Console i sprawdź, czy strona jest zaindeksowana i czy na najważniejszych podstronach nie ma błędów.

    Jeśli po tych pięciu krokach wychodzi, że strona istnieje, ale od trzech lat nikt jej nie ruszał, albo że jej w ogóle nie ma, to jest ten moment, w którym nowa strona kosztuje mniej nerwów niż poprawianie starej. W Sitehero wygląda to tak: wklejasz adres obecnej strony albo odpowiadasz na kilka pytań w krótkim formularzu, my przygotowujemy układ, teksty i projekt, a Ty dostajesz gotową stronę w ciągu jednego do dwóch dni roboczych. Domenę rejestrujemy na Twoją firmę, więc zostaje u Ciebie, a zmiany na stronie wprowadzamy po wiadomości. Pierwszy krok to jedna wklejona linijka.

  • Degoog 1.0.0: Reclaiming Search Sovereignty with a Privacy First Aggregator

    Degoog 1.0.0: Reclaiming Search Sovereignty with a Privacy First Aggregator

    The digital landscape is defined by a handful of dominant search platforms, each acting as a gatekeeper to information. For too long, users have been forced to accept a business model built on data harvesting and algorithmic suggestion rather than truthful information retrieval. Degoog, the open-source search aggregator, is here to change that.

    The News: Degoog’s First Stable Release

    Degoog has finally reached its first stable version. This maturity is a direct result of the work by fccview and the dedicated community contributors overseeing the project at degoog-org/degoog. This release transforms Degoog from an ambitious project into a reliable, production ready utility.

    What is Degoog?

    Degoog is a meta search engine, a tool you self host, designed to operate outside the control of any single corporation. Instead of relying on one monolithic search provider, Degoog simultaneously sends the same query to multiple real search engines: Google, Brave, DuckDuckGo, and others. It then collects, cross references, and intelligently aggregates all the responses into one unified, clutter free interface.

    Liberation from the Aggregator Trap

    The core value of Degoog is its commitment to user sovereignty.

    • Privacy Guarantee: By running Degoog on your own hardware, you are in control. The platform adheres to a zero logging policy, ensuring that your searches do not become personal data points for tracking or profiling.
    • Comprehensive Sourcing: No longer are you stuck with the curated, narrow view of a single engine. Degoog’s parallel querying capability ensures maximum result diversity.
    • Uncluttered Experience: The results are presented cleanly, free of aggressive sponsored links, AI overviews that may contain inaccuracies, or attempts to funnel you into specific platforms.

    A Search Experience That Adapts to You

    Degoog is far more than a simple results aggregator. Its modular architecture empowers users to build a search engine perfectly tailored to their workflow.

    The entire system is open for extension. Users can integrate custom search engines, “bang” commands, or powerful “slot” plugins. These tools allow you to customize the search experience, perhaps routing queries directly to specific industry forums or Github repositories.

    Degoog is a powerful example of open source technology solving real world problems. It is a tool that empowers the individual, offering a decentralized, private, and reliable alternative in an increasingly surveilled digital world.

  • Your Phone Deserves a Real Backup Too: Meet Resticopia

    We back up servers.

    We back up databases.

    We back up laptops, virtual machines, configuration files, Kubernetes clusters, and probably a few things that really do not need their own backup strategy.

    But what about the device we carry around every single day?

    Our phones contain photos, documents, downloads, exported files, authenticator backups, recordings, project files, and countless other bits of data accumulated over the years.

    And yet, for many people, the backup strategy for all of that data is essentially:

    “I think Google is syncing it somewhere.”

    That is not quite the same thing as having a backup.

    So I built Resticopia.

    Resticopia is an open-source Android application for creating and managing backups using Restic.

    It brings a proper backup tool, with repositories, snapshots, encryption, scheduling, and retention, to Android without requiring you to manage everything from a terminal.

    Synchronization is not a backup

    This distinction is worth making first.

    Cloud synchronization is extremely useful. I use it too.

    But synchronization and backup solve different problems.

    If you delete a synchronized file, that deletion may eventually be synchronized too. If something corrupts your data, the corrupted version can replace the good version. If you lose access to an account, your ability to access that data may disappear with it.

    A backup gives you something different:

    a historical copy of your data that you can restore later.

    Ideally, backups also live independently from the device they protect.

    Keeping a second copy of /Pictures somewhere else on the same phone is not particularly useful when the phone ends up at the bottom of a lake.

    The same applies to hardware failure, accidental deletion, filesystem corruption, theft, or simply replacing a device.

    The question is not really:

    “Will I ever lose data?”

    The better question is:

    “When something disappears, how difficult will it be to get it back?”

    The boring backup rule that actually works

    A commonly used guideline is the 3-2-1 backup strategy:

    • keep 3 copies of important data,
    • on 2 different types of storage,
    • with at least 1 copy somewhere else.

    You do not have to follow that formula religiously.

    The important idea is separation.

    Your phone should not be the only place where irreplaceable data exists.

    And your backup should not depend entirely on the continued existence of your phone either.

    For example:

    Android phone
     |
     +-- local data
     |
     +-- Resticopia
             |
             +-- encrypted Restic repository
                     |
                     +-- NAS
                     +-- S3-compatible storage
                     +-- Backblaze B2
                     +-- rest-server
                     +-- other storage via Rclone

    Now losing the phone does not necessarily mean losing the data.

    Why Restic?

    I did not want to invent another backup format.

    Restic already solves the difficult parts of backup very well.

    It is designed around a few principles that I think a backup system should have: backups should be secure, efficient, verifiable, and easy enough that people actually run them.

    Restic stores backups inside a repository.

    Each backup creates a snapshot, giving you a view of your files at a particular moment in time.

    It also encrypts repository contents, performs deduplication, and only needs to store new data instead of creating another complete copy of everything every time a backup runs.

    That makes it very well suited to regular, automated backups.

    There was just one problem.

    Restic is primarily a command-line tool.

    On a server, that is perfect.

    On a phone, not so much.

    Enter Resticopia

    Resticopia provides an Android interface around Restic and Rclone.

    Under the hood, it runs the native Linux tools in a custom PRoot environment on Android.

    From the application, you can:

    • create and configure Restic repositories,
    • select directories to back up,
    • run backups,
    • browse snapshots,
    • configure scheduled backups,
    • define retention and cleanup policies,
    • monitor backup progress through notifications,
    • use local repositories,
    • connect to S3, Backblaze B2, and REST repositories,
    • and use Rclone for many additional storage providers.

    The goal is not to hide Restic.

    It is to make using Restic on a phone practical.

    I still want the repository to be a normal Restic repository.

    Resticopia is simply the tool that makes managing it from Android comfortable.

    Set it and forget it, almost

    One of the most important features of any backup solution is automation.

    A backup procedure that relies on remembering to press a button every Sunday eventually becomes a backup procedure that has not run for six months.

    Resticopia lets you schedule backups.

    That changes the workflow from:

    I should probably back up my phone.

    to:

    My phone was backed up last night.

    That is a much better state to be in.

    You can also configure retention policies so that keeping historical snapshots does not mean keeping every snapshot forever.

    Automation does not mean backups should never be checked, though.

    A scheduled job can fail.

    Credentials can expire.

    Storage can fill up.

    Android can change permissions.

    A backup that has not successfully completed for six months is not much better than no backup at all.

    The ideal backup system therefore needs to be both automatic and observable.

    Android makes this surprisingly complicated

    Running a traditional backup tool on Android is more complicated than it sounds.

    Desktop Linux normally gives applications fairly predictable filesystem access.

    Android intentionally does not.

    Its storage model has become increasingly restrictive over time, particularly around removable storage and application-specific directories.

    A good example appeared almost immediately in the Resticopia issue tracker.

    Someone wanted to create a Restic repository on an external USB or SD card.

    Sounds simple:

    1. connect storage,
    2. give the application file permissions,
    3. create a repository,
    4. done.

    Except Android had other ideas.

    Even with “All files access” enabled, attempts to create the repository resulted in permission errors under locations such as /mnt/media_rw and /storage/....

    The issue is still a useful illustration of something I discovered repeatedly while developing Resticopia:

    making backup software is not only about implementing backup software.

    You also have to work around the operating system’s storage model, background execution rules, permissions, power management, and increasingly isolated application environments.

    Android is very good at reminding you that applications do not own the filesystem.

    Issue #1 is here for anyone interested in the details:

    Backup to external USB/SD Card, Resticopia #1

    It is exactly the kind of problem that motivates me to keep improving the application.

    A user should not have to understand Android mount points just because they want a second copy of their photos.

    Local backups are useful, but do not stop there

    Resticopia supports local repositories, and they can be useful.

    For example, backing up to removable storage gives you a copy that can physically leave the phone.

    But keeping a backup permanently attached to the same device has obvious limitations.

    If both disappear together, the backup does not help much.

    This is where Restic’s remote backends become particularly interesting.

    You can keep your repository on infrastructure you control:

    Phone
  |
  +--> Resticopia
          |
          +--> Restic repository
                  |
                  +--> your server / NAS / object storage

    Or use an object-storage provider.

    Or use Rclone to connect to another supported remote.

    Resticopia does not try to decide where your data should live.

    That is deliberate.

    I want users to be able to choose their storage rather than making the application dependent on a specific cloud service.

    Own the backup, not just the application

    This is also why using Restic underneath matters to me.

    I do not want your backup to become useless because one Android application disappears.

    The important thing is the repository.

    Your data is stored using Restic’s format and can be accessed with Restic independently of Resticopia.

    That separation is important.

    Applications come and go.

    Phones definitely come and go.

    Your backups should survive both.

    A backup is only useful if you can restore it

    There is one last point that is easy to overlook.

    Creating backups is not the actual objective.

    Restoring data is.

    A backup that has never been tested is partly an assumption.

    Every once in a while, pick a file from an older snapshot and restore it.

    Check that you know where your repository password is stored.

    Make sure the repository is reachable.

    Make sure you actually understand the recovery process before you urgently need it.

    Because the worst possible moment to learn how your backup system works is ten minutes after losing your data.

    Try Resticopia

    Resticopia is open source and still evolving.

    You can find the application here:

    resticopia.dydlak.cloud

    The source code and issue tracker are available on GitHub:

    github.com/dawiddyd/resticopia

    It is also available through F-Droid.

    If you find a bug, have an idea for improving the application, or discover another interesting Android storage edge case, open an issue.

    Backup software gets better when it meets real devices, real storage, and real-world failure modes.

    And if you do not use Resticopia, that is fine too.

    Use Restic directly.

    Use another backup application.

    Use your NAS.

    Use external storage.

    Use a cloud provider.

    Use several of them.

    Just make sure that the only copy of something important is not sitting on a tiny device you carry around every day.

    Because backups are boring.

    Right up until the moment they become the most important thing you have.

    Buy Me a Coffee

    If you find Resticopia useful and want to support its development, you can buy me a coffee.

    It helps me keep working on the app, fixing bugs, and adding new features.

    Buy me a coffee