Dziennik aktualizacji: pokaż, co się zmieniło i kiedy

Dziennik aktualizacji to datowany zapis merytorycznych zmian na stronie: co się zmieniło, dlaczego i czy odpowiedź, zalecenie lub dowody uległy zmianie.

Dziennik aktualizacji

27 sierpnia 2026 — Zaktualizowano cennik i zalecenie
Zastąpiono wycofany plan Starter obecnym planem Essentials, zaktualizowano tabelę porównawczą i zmieniono zalecenie dla zespołów potrzebujących eksportu audytu. Źródła zostały ponownie zweryfikowane względem dokumentacji planów dostawcy.

12 maja 2026 — Odświeżono dowody; wniosek bez zmian
Zastąpiono dwa nieaktualne odniesienia do funkcji i zweryfikowano pozostałe limity planów. Rekomendowana opcja nie uległa zmianie.

Każda data jest powiązana z możliwym do sprawdzenia zdarzeniem. Gołe „Zaktualizowano 27 sierpnia 2026” jest niewyjaśnione; dziennik ujawnia zakres i konsekwencje pracy.

Dlaczego ten element jest ważny

Czytelnicy nie traktują każdej zmiany jednakowo. Poprawienie błędnie napisanego nagłówka nie jest równoznaczne ze zmianą zalecenia, zastąpieniem zestawu danych czy naprawieniem niebezpiecznej instrukcji. Pojedyncza data aktualizacji sprowadza wszystkie te zdarzenia do tego samego sygnału. Na stronach używanych do wydawania pieniędzy, postępowania zgodnie z procedurą, interpretowania badań lub rozumienia polityki czytelnicy muszą wiedzieć, czy zmieniła się sekcja, na której polegają.

Dziennik aktualizacji przechowuje historię bez zmuszania czytelników do porównywania buforowanych kopii. Odpowiada na cztery pytania: Czy strona była utrzymywana? Czy zmiana mnie dotyczy? Czy błąd został otwarcie poprawiony? Czy wniosek jest nadal aktualny? Jasne odpowiedzi tworzą odpowiedzialność i zapobiegają pozornej świeżości wynikającej z przesunięcia daty bez wykonania znaczącej pracy.

Opisuj konsekwencje, nie czynności. „Zaktualizowano linki” opisuje działanie. „Zastąpiono wycofane źródło dla całkowitej wartości rynku z 2024 r.; wartość i wniosek pozostają bez zmian” mówi czytelnikom, co wciąż jest godne zaufania. Jeśli wniosek się zmienił, powiedz to wprost.

Możliwość ekstrakcji maszynowej oznacza, że oprogramowanie może podzielić każde zdarzenie na datę, typ, podsumowanie, szczegóły, zmienioną sekcję i odniesienie do źródła. Stałe pola pozwalają audytom znaleźć korekty, agentom wyjaśnić zmienione rekomendacje, a migracjom zachować historię. Niespójna proza zmusza oprogramowanie do zgadywania, gdzie zdarzenia się zaczynają i kończą.

Typowany cel elementu ma zatem pierwszeństwo przed wizualnie podobną osią czasu czy listą punktowaną. Postępuj zgodnie z zasadami pisania elementów : gdy treść rejestruje rewizje bieżącej strony, zakoduj ją jako dziennik aktualizacji. Renderer może użyć listy, kart lub rozwijanego archiwum, ale kanoniczne pola zdarzeń muszą przetrwać każdą prezentację.

Kiedy go używać

Użyj dziennika aktualizacji, gdy czytelnicy mogą potrzebować porównać bieżącą i wcześniejszą wersję strony. Przesłanki obejmują zmienione zalecenie, poprawiony fakt, zmienioną metodę, zastąpiony zestaw danych, zmienione obliczenia, nową wersję, zmienione kryteria kwalifikowalności, zaktualizowany model cenowy, zmodyfikowane instrukcje lub zarchiwizowaną opcję.

Element jest najbardziej wartościowy, gdy autorytet narasta z czasem. Badanie może otrzymać poprawiony mianownik; dokumentacja może obsługiwać nowy interfejs; objaśnienie regulacyjne może odróżnić poprawkę od redakcyjnego wyjaśnienia. Ciche przepisywanie zniszczyłoby historię, której potrzebuje powracający czytelnik.

Używaj wpisu przeglądowego oszczędnie, gdy zakresowy przegląd nie wykazał zmian. Oznacz go etykietą „Przejrzane”, podaj, co sprawdzono, i stwierdź, że wniosek pozostaje bez zmian. To odpowiednie dla zmiennych statystyk, cen, możliwości produktów lub przepisów; nie jest to pozwolenie na generowanie pozornej aktywności.

Przypadki graniczne wymagają innego podejścia:

• Data publikacji lub modyfikacji: użyj znacznika świeżości , aby ujawnić kanoniczne daty strony. Znacznik i dziennik mogą działać razem, ale jeden nie może zastąpić drugiego.
• Historia wydań produktu lub harmonogram projektu: opisują one zmiany w przedmiocie. Dziennik aktualizacji rejestruje zmiany redakcyjne bieżącej strony.
• Wynik systemu kontroli wersji: komunikaty commit zawierają szum implementacyjny, identyfikatory wewnętrzne i szczegóły wrażliwe pod względem bezpieczeństwa. Nie są to redakcyjne rejestry dla czytelników.
• Lista źródeł: blok źródeł dowodzi, skąd pochodzą twierdzenia. Dziennik aktualizacji mówi, kiedy i dlaczego te źródła lub twierdzenia się zmieniły.
• Drobne utrzymanie: nie rejestruj zmian pisowni, interpunkcji, formatowania, kompresji obrazów, analityki, parametrów śledzenia ani migracji szablonu, chyba że zmiana wpłynęła na znaczenie lub dostępność.

Strona bez merytorycznej rewizji potrzebuje daty publikacji, a nie pustego panelu czy fikcyjnej historii.

Gdzie go umieścić

Umieść pełny dziennik po odpowiedzi, dowodach, wnioskach i źródłach, ale przed powiązanymi treściami, formularzem zapisu do newslettera lub zamykającym wezwaniem do działania. Czytelnicy najpierw potrzebują bieżącej strony, a potem jej historii. Na stronach z badaniami, statystykami i polityką dziennik zwykle znajduje się po źródłach lub metodologii.

Jeśli najnowsza zmiana wpływa na sposób, w jaki strona powinna być czytana, dodaj „Zobacz, co się zmieniło” obok daty bohatera i prowadź do pełnego dziennika. Nie powielaj tam wpisu. Korekta dotycząca bezpieczeństwa, pieniędzy, kwalifikowalności lub wniosku wymaga również powiadomienia obok poprawionego twierdzenia.

Dziennik może współdzielić obszar utrzymania z autorstwem, gdy oba pozostają odrębne. Nie może znajdować się obok przycisku zakupu, oferty limitowanej czasowo, licznika odliczającego, oceny, opinii klienta ani odznaki promocyjnej; to zmienia historię w pilność lub dorozumiane poparcie. Nie łącz go z blokiem źródeł: powód zmiany źródła to historia redakcyjna, a nie cytowanie.

Prowadź jeden kanoniczny dziennik. Pasek boczny może linkować do niego, ale go nie powielać. Po pięciu wpisach pokaż trzy do pięciu najnowszych i udostępnij resztę przez „Zobacz wcześniejsze aktualizacje.” Zachowaj pełną historię na stronie lub w stabilnym, zarządzanym archiwum.

Anatomia

1. Tytuł elementu: Używa „Dziennik aktualizacji”, „Historia rewizji” lub węższej zatwierdzonej etykiety, która pozostaje zrozumiała poza projektem strony.
2. Data zdarzenia: Pokazuje bezwzględną datę kalendarzową i udostępnia tę samą wartość jako maszynowy znacznik czasu zgodny z ISO 8601.
3. Typ zdarzenia: Rozróżnia updated (zaktualizowane), corrected (poprawione), reviewed (przejrzane), method-changed (zmieniona metoda) i archived (zarchiwizowane) bez polegania na kolorze.
4. Podsumowanie: Nazywa zmieniony obiekt i wynik w jednej zwięzłej linii.
5. Szczegóły: Wyjaśnia stary stan, nowy stan i powód, gdy te fakty pomagają czytelnikowi interpretować stronę.
6. Zmieniona sekcja: Opcjonalnie linkuje do stabilnego nagłówka lub rysunku, który uległ zmianie, używając fragmentu identyfikatora, który nie zostanie przeznaczony do innego celu.
7. Konsekwencja: Określa, czy odpowiedź, wniosek, zalecenie, kwalifikowalność lub instrukcje uległy zmianie.
8. Odniesienie do źródła: Opcjonalnie wskazuje identyfikator źródła już zdefiniowany w bloku źródeł strony.
9. Kontrola archiwum: Ujawnia wcześniejsze wpisy bez usuwania ich z dokumentu ani drzewa dostępności.

Wpisy muszą pozostać zrozumiałe bez stylizacji. Ikony, linie i kolory nigdy nie niosą same w sobie informacji o typie lub konsekwencji.

Przykłady projektowe

Warianty odzwierciedlają gęstość informacji i ryzyko redakcyjne.

Kompaktowy wiersz ostatniej zmiany

Użyj jednego kompaktowego wiersza dla pojedynczej prostej rewizji. Zawiera datę, typ, podsumowanie i konsekwencję. Użyj standardowej listy, gdy wyjaśnienie przekracza dwa zdania.

Standardowa lista rewizji

Użyj listy od najnowszych dla dwóch do pięciu wpisów, z zachowaniem tej samej kolejności pól.

Wariant z korektą

W przypadku istotnego błędu oznacz etykietą „Korekta”, pokaż nieprawidłowy i poprawiony stan, określ wpływ i linkuj do zmienionej sekcji. Podkreśl go bez alarmistycznego języka.

Zmiana metody lub wersji

Gdy zmienia się zestaw danych, formuła, wersja produktu, jurysdykcja lub metoda, pokaż stare i nowe wersje. Określ, kiedy wcześniejsze wyniki nie są już porównywalne.

Rozwijane archiwum

Po pięciu wpisach oznacz archiwum liczbą wpisów i zakresem dat. Zachowaj nagłówki i strukturę listy; nie sprawiaj, by JavaScript był jedynym sposobem dostępu do rejestru.

Wąski widok

Układaj datę, typ, podsumowanie i szczegóły pionowo. Nigdy nie obcinaj dat ani nie ukrywaj tekstu konsekwencji na urządzeniach mobilnych.

Parametry

Pola nadrzędne kontrolują kolekcję; powtarzane pola elementów opisują każde zdarzenie.

Wpisy są powtarzanymi elementami, a nie jednym polem HTML. Pierwszy nagłówek elementu nadrzędnego mapuje się na title; pierwszy nagłówek każdego elementu mapuje się na summary, a pozostała treść na detail. Daty, typy, wpływ, odniesienia i wersje pozostają atrybutami.

impact jest wymagane, aby czytelnicy nie musieli wnioskować, czy odpowiedź się zmieniła. Użyj not-applicable tylko wtedy, gdy materiał nie ma wniosku. Przegląd bez edycji używa type=reviewed i impact=unchanged.

Składnia i przykłady kodu

Wszystkie reprezentacje zachowują te same pola. Identyfikatory źródeł odnoszą się do kanonicznego bloku źródeł.

Przenośna dyrektywa Markdown

:::update-log{order=newest-first visibleItems=3}
## Update log

::item{date="2026-08-27" type=updated impact=changed affectedSection="plans" evidenceRef="vendor-plans"}
### Pricing and recommendation updated

Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.
::

:::

Kontrakt shortcode Hugo

{{< update-log title="Update log" order="newest-first" visibleItems="3" >}}
  {{< update-log-item date="2026-08-27" type="updated" impact="changed" affectedSection="plans" evidenceRef="vendor-plans" >}}
  ## Pricing and recommendation updated
  Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.
  {{< /update-log-item >}}
{{< /update-log >}}

To jest kontrakt adaptera, a nie istniejący shortcode. Każdy parametr jest nazwany.

Bloki WordPress

<!-- wp:amicited/update-log {"title":"Update log","order":"newest-first","visibleItems":3} -->
<!-- wp:amicited/update-log-item {"date":"2026-08-27","type":"updated","impact":"changed","affectedSection":"plans","evidenceRef":["vendor-plans"]} -->
<h3>Pricing and recommendation updated</h3>
<p>Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.</p>
<!-- /wp:amicited/update-log-item -->
<!-- /wp:amicited/update-log -->

WordPress powinien udostępniać strukturalne kontrolki dla daty, typu, wpływu, sekcji i źródła.

Przykłady

Dobry wpis aktualizacji

18 lipca 2026 — Poprawiono obliczenia
Poprawiono mianownik współczynnika konwersji ze wszystkich sesji na kwalifikowane sesje produktowe w tabeli „Skuteczność kanałów”. Wartości dla wyszukiwania organicznego zmieniły się z 3,1% na 2,4%; ranking kanałów i wniosek artykułu nie uległy zmianie. Podstawowe liczby sesji nie zostały naruszone.

To działa, ponieważ nazywa błąd, stare i nowe definicje, zmienioną sekcję, konsekwencje liczbowe i status wniosku. Czytelnicy mogą ocenić, czy wcześniejsza praca wymaga przeglądu.

Zły wpis aktualizacji

Lato 2026 — Całkowicie odświeżone!
Przejrzeliśmy tę stronę i wprowadziliśmy kilka ulepszeń, abyś mógł zaufać, że wszystko jest aktualne.

To zawodzi, ponieważ data jest nieprecyzyjna, „całkowicie” zawyża zakres, „kilka ulepszeń” ukrywa fakty, a „zaufać” wymaga niezasłużonego wniosku. Jeśli praca była kosmetyczna, usuń wpis. Jeśli merytoryczna, nazwij każdą zmianę istotną dla decyzji.

Znaczniki schematu i dostępność

Dziennik aktualizacji nie ma samodzielnego typu Schema.org. Pozostaje treścią w obrębie nadrzędnego Article, TechArticle lub Report. Najnowsze merytoryczne zdarzenie może wspierać dateModified; przegląd bez zmian nie może. Nigdy nie zastępuj datePublished.

Nie koduj wpisów jako CreativeWork, Event, HowToStep ani ItemList; te typy implikują znaczenia, których dziennik nie ma. Użyj przewidywalnego HTML: oznaczonej sekcji, elementów listy, nagłówków, <time datetime="2026-08-27">27 sierpnia 2026</time> i stabilnych fragmentów.

Użyj jednego elementu listy na zdarzenie; CSS może narysować oś czasu bez zmiany kolejności. Określ, że wpisy są w kolejności od najnowszych. Pokaż typ w tekście, nie tylko w kolorze lub ikonach, i używaj opisowych linków.

Archiwum potrzebuje natywnego mechanizmu ujawniania oznaczonego liczbą lub zakresem wpisów. Wszystkie wpisy muszą być osiągalne za pomocą klawiatury i czytnika ekranu. Nie używaj regionu ARIA live. Zachowaj kolejność nagłówków i zlokalizowane daty.

Umieść notę korygującą przy zmienionym twierdzeniu i zapisz ją w dzienniku. Pierwsze chroni bezpośrednich czytelników; drugie przechowuje historię.

Zasady pisania

Rozpoczynaj od zmienionego obiektu i precyzyjnego czasownika: „Zasada kwalifikowalności wyjaśniona”, „Zestaw danych zastąpiony” lub „Formuła poprawiona.” Utrzymuj podsumowania w granicach 4–14 słów, a szczegóły w zakresie 25–90 słów. Użyj jednego zdania na zmianę i powód, a drugiego na wpływ. Używaj zlokalizowanych bezwzględnych dat i wyświetlania od najnowszych.

Wyjaśnij powód przed rezultatem. „Dostawca wycofał Starter, więc zastąpiliśmy go Essentials i ponownie oceniliśmy zalecenie” rejestruje przyczynę; „Ulepszyliśmy nasze porównanie” rejestruje opinię. Używaj neutralnego czasu przeszłego.

Każdy istotny wpis powinien odpowiadać na te pytania:

• Jaki konkretny fakt, instrukcja, metoda, źródło, zakres lub wniosek uległ zmianie?
• Dlaczego zmiana była potrzebna?
• Gdzie na stronie nastąpiła?
• Czy główna odpowiedź, zalecenie lub wniosek uległy zmianie?
• Czy czytelnik musi ponownie podjąć decyzję lub działanie na podstawie wcześniejszej wersji?

Utwórz jeden wpis na zdarzenie redakcyjne, a nie na każde naciśnięcie klawisza. Grupuj powiązane zmiany z jednego przeglądu; rozdzielaj niezwiązane prace, różne skutki lub różne daty. Pokaż trzy do pięciu i zachowaj merytoryczną historię.

Nigdy nie umieszczaj poufnych notatek, szczegółów bezpieczeństwa, luk w zabezpieczeniach, danych osobowych, obwiniania, nieprzetworzonych skrótów commitów, niewyjaśnionych zgłoszeń, marketingu, pilności ani bibliografii. Nigdy nie obiecuj „100% aktualności”, nie usuwaj korekt, nie przepisuj wpisów po cichu ani nie zmieniaj dat kosmetycznych poprawek.

Jeśli wpis wymaga korekty, zachowaj jego datę i dodaj zdarzenie korekty. Prywatność, bezpieczeństwo lub obowiązki prawne mogą uzasadniać redakcję; określ, że zapis został zmieniony i dlaczego, na odpowiednim poziomie szczegółowości.

Typy wpisów, które go używają

Tablica postTypes w metadanych jest źródłem tej tabeli. „Wymagane” oznacza, że historia istotnych rewizji jest częścią kontraktu zaufania danego formatu; „warunkowe” oznacza, że dziennik pojawia się po wystąpieniu kwalifikującej zmiany.

Nowa strona nie potrzebuje pustego dziennika. Po kwalifikującej zmianie zachowaj element.

Lista kontrolna QA

• Każdy widoczny wpis reprezentuje merytoryczne zdarzenie redakcyjne, a nie kosmetyczną lub automatyczną zmianę.
• Data zdarzenia jest dokładna, prawidłowa, nieprzyszła i zgodna z zatwierdzonym zapisem redakcyjnym.
• Podsumowanie nazywa zmieniony obiekt i mieści się w granicach 4–14 słów.
• Szczegóły określają, co się zmieniło i dlaczego, przed opisaniem korzyści.
• Wpis identyfikuje, czy odpowiedź, wniosek, zalecenie, kwalifikowalność lub instrukcje uległy zmianie.
• Istotna korekta pojawia się również obok zmienionego twierdzenia.
• Fragmenty sekcji i identyfikatory źródeł odnoszą się do stabilnych celów na tej samej kanonicznej stronie.
• Dziennik pojawia się po głównej treści i źródłach, ale przed promocyjnymi modułami zamykającymi.
• Dziennik nie jest wizualnie połączony z CTA, ofertą, oceną, opinią klienta ani blokiem źródeł.
• Daty używają semantycznych wartości <time>; typy zdarzeń i wpływ nie polegają na kolorze lub ikonach.
• Kontrolka archiwum jest obsługiwana klawiaturą, wyraźnie oznaczona etykietą i udostępnia całą swoją zawartość technologiom asystującym.
• Wpis tylko z przeglądem nie zmienia dateModified; najnowsze merytoryczne zdarzenie jest zgodne z kanoniczną datą aktualizacji.
• Poufne notatki, dane osobowe, szczegóły bezpieczeństwa, nieprzetworzona historia implementacji i język marketingowy są nieobecne.
• Typ wpisu strony i ryzyko czytelnika uzasadniają użycie elementu.

FAQ

Czy każda edycja treści powinna znaleźć się w dzienniku aktualizacji?

Nie. Rejestruj zmiany, które modyfikują fakty, instrukcje, dowody, zakres, interpretację, zalecenia lub decyzję czytelnika. Pomiń zmiany pisowni, odstępów, śledzenia, szablonu i inne niemerytoryczne.

Czym różni się dziennik aktualizacji od daty ostatniej aktualizacji?

Data ostatniej aktualizacji informuje, że nastąpiła merytoryczna zmiana. Dziennik aktualizacji określa, co się zmieniło, dlaczego się zmieniło i czy odpowiedź lub wniosek uległy zmianie, dzięki czemu deklaracja o utrzymaniu treści może być zweryfikowana.

Czy najnowsza czy najstarsza aktualizacja powinna być pierwsza?

Pokaż najnowszy wpis jako pierwszy na stronie utrzymywanej, ponieważ czytelnicy zwykle potrzebują bieżącej zmiany. Zachowaj porządek chronologiczny w danych maszynowych i udostępnij wyraźnie oznaczony archiwum, gdy widoczna lista jest skrócona.

Czy dziennik aktualizacji może zastąpić noty korygujące?

Nie. Istotny błąd wymaga widocznej korekty przy danym twierdzeniu oraz stałego wpisu w dzienniku. Dziennik przechowuje historię; nie może ukrywać korekty na dole strony.

Czy przeglądy bez zmian powinny pojawiać się w dzienniku?

Tylko wtedy, gdy status przeglądu ma znaczenie dla czytelników, a wpis jest oznaczony jako „Przejrzane”, a nie „Zaktualizowane.” Podaj zakres sprawdzonych informacji i stwierdź, że nie wymagały merytorycznej zmiany; nie zmieniaj dateModified.