Agent dodaje artykuł, uzupełnia obraz, metadane i linki. Kliknięcie „publikuj” wysyła go na stronę. Dopiero potem redaktor widzi stary termin, link do szkicu i nagłówek, którego nikt by nie napisał dla człowieka. Workflow był szybki, tylko odbiór nastąpił po fakcie.
CMS dla ludzi i agentów powinien rozdzielać przygotowanie, odbiór i publikację. Ta sama wygoda nie oznacza tych samych praw. Automatyzacja ma skracać pracę redakcyjną, nie usuwać odpowiedzialności z ostatniego kroku.
Statusy opisują rzeczywistą pracę
Ustal niewielki zestaw: szkic, do odbioru, poprawki, zatwierdzony, opublikowany, wycofany. Nie dodawaj „prawie gotowe” bez właściciela i reguły. Każdy status powinien odpowiadać na pytanie, kto działa następnie.
Agent może tworzyć szkic i zgłaszać go do odbioru. Nie powinien oznaczać własnej pracy jako zatwierdzonej, chyba że proces wyraźnie dopuszcza ograniczony typ zmian. Wysoka pewność modelu nie jest statusem redakcyjnym.
Zapisz datę i autora zmiany statusu. Przy błędzie trzeba wiedzieć, czy treść była jeszcze szkicem, kiedy powstała. Publiczny URL nie jest dowodem odbioru.
Uprawnienia rozdzielają zapis i publikację
Konto agenta powinno mieć minimalny zakres: tworzenie szkicu, edycja własnych wersji, odczyt wymaganych źródeł. Publikacja wymaga osobnej roli lub reguły. Nie używaj jednego tokenu administracyjnego dla wszystkich automatyzacji.
Człowiek zatwierdzający widzi diff, źródła i skutek. Nie powinien odbierać całego artykułu od zera, jeśli zmiana dotyczyła jednego akapitu. System ma pokazywać zmienione pola oraz powiązane testy.
Przy integracji zewnętrznej ogranicz dostęp do sekretów i innych sekcji CMS. Agent treści nie musi zmieniać użytkowników, ustawień analityki ani przekierowań. To zmniejsza skutek błędnego polecenia.
Wersja jest adresem odbioru
Zachowaj treść, metadane, obrazy, linki i konfigurację publikacji jako jedną wersję. Jeżeli odbierasz tekst sprzed tygodnia, a obraz zmienił się wczoraj, trudno powiedzieć, co zostało zatwierdzone.
Nie nadpisuj wersji po zgłoszeniu do odbioru. Nowe poprawki tworzą kolejny szkic i mogą wymagać ponownego odbioru zależnego. Redaktor powinien widzieć różnicę od wersji zaakceptowanej.
Przy publikacji zapisz identyfikator wersji. Rollback wraca do konkretnego stanu, nie do ogólnego „poprzedniego artykułu”, który w międzyczasie mógł zostać poprawiony przez inną osobę.
Odbiór obejmuje treść i skutek SEO
Sprawdź tytuł, opis, canonical, H1, linki, obraz, tekst alternatywny, źródła i dane strukturalne. Sama poprawność językowa nie wystarcza. Artykuł może być ładny i prowadzić do niewłaściwej usługi lub starego dokumentu.
Testuj adres publiczny po publikacji. Sitemap powinna zawierać kanoniczny URL, a strona zwracać 200 bez noindex. Dane strukturalne muszą odpowiadać widocznej treści. Google opisuje mapę jako sposób informowania o stronach, nie gwarancję indeksacji.
Przy nowym tekście sprawdź powiązania z kategorią i naturalne linki do innych artykułów. Cross-linking ma pomagać w następnym kroku, a nie być listą losowych fraz. Zasady opisuje przewodnik o linkowaniu artykułu i usługi.
Obraz wymaga prawa i właściwego opisu
Agent powinien wybierać tylko zatwierdzoną bibliotekę lub przesyłać materiał do odbioru. Sprawdź licencję, źródło, rozmiar, format i powiązanie z tematem. Obraz nie może sugerować funkcji lub wyniku, którego nie ma.
Tekst alternatywny opisuje rolę obrazu, nie listę słów kluczowych. Przy ilustracji dekoracyjnej zastosuj właściwe reguły dostępności. Nie zgaduj obiektów na zdjęciu dla lepszego SEO.
Przed publikacją otwórz obraz na telefonie i desktopie. Plik może działać, a kadrowanie ucinać istotny fragment. Sprawdź także wagę i cache. Szybkość jest częścią odbioru, nie osobnym projektem po publikacji.
Przypadki blokujące publikację
Zatrzymaj przy braku źródła dla istotnego faktu, niedziałającym linku, konflikcie canonical, niezatwierdzonym obrazie, błędzie metadanych i nieznanym statusie prawa. Reguły powinny być twarde, nie tylko ostrzeżeniem w logu.
Nie blokuj za każdą kosmetyczną uwagę modelu. Zbyt wiele fałszywych alarmów sprawia, że redakcja klika „publikuj mimo to” z odruchu. Kryteria muszą odpowiadać rzeczywistemu ryzyku.
Przy zmianie starego artykułu oceń, czy aktualizacja zmienia adres, datę lub intencję. Nie przepisuj historii dla pozoru świeżości. Jeżeli treść wymaga nowego materiału, zaplanuj przekierowanie i aktualizację linków.
Przykład: poprawka jednego akapitu
Agent zmienia limit i dodaje źródło. System pokazuje diff tylko tej sekcji, metadane bez zmian i wynik testu źródła. Redaktor sprawdza kontekst oraz powiązane zdania, po czym zatwierdza.
Nie trzeba generować całego artykułu od nowa ani odbierać każdego obrazu ponownie. Testy zależne obejmują zmieniony fakt, linki w tej sekcji i publiczną wersję. Wersja zapisuje autora oraz zakres.
Po publikacji sprawdź cache i HTML. W CMS poprawka może być widoczna, ale strona nadal serwować starą wersję. Dopiero publiczny wynik zamyka pracę.
Publikacja wsadowa wymaga osobnych reguł
Nie uruchamiaj setki artykułów z jednym odbiorem „wygląda dobrze”. Najpierw mała partia i pełne testy. Potem zwiększaj zakres, jeżeli typ błędu nie powtarza się. Każda strona ma własny adres i skutek.
Zapisz wyniki dla każdego elementu: opublikowany, zatrzymany, błąd, do poprawy. Jedna nieudana strona nie powinna automatycznie zatrzymywać wszystkich, chyba że błąd dotyczy wspólnej reguły lub szablonu.
Przy błędzie systemowym wstrzymaj kolejkę. Nie generuj kolejnych wariantów tych samych metadanych dla pozoru postępu. Właściciel powinien zobaczyć przyczynę i możliwość bezpiecznego wznowienia.
Rollback nie kasuje śladu
Wycofanie powinno przywrócić poprzednią wersję treści i metadanych oraz zaktualizować sitemap, cache i przekierowania. Nie usuwaj historii błędnej publikacji. Zapisz powód i właściciela decyzji.
Sprawdź publiczny URL po wycofaniu. Może zwracać poprzednią treść, przekierowanie albo 410 zgodnie z procesem. Nie zostawiaj wersji, której nikt nie chce indeksować, tylko dlatego że technicznie strona działa.
Przy zmianie adresu przywróć także właściwe linki wewnętrzne. Rollback artykułu bez testu odwołań może zostawić dziesiątki błędów 404. Zasady pokrewne opisuje przewodnik o wersjach dokumentów w CMS.
Test praw agenta i człowieka
Spróbuj opublikować jako agent bez roli i oczekuj odmowy. Jako redaktor przygotuj szkic, popraw i zatwierdź. Sprawdź CSRF, autoryzację API, zakres pól i brak możliwości zmiany innych ustawień.
Dodaj konflikt dwóch wersji. System nie powinien nadpisać cudzej poprawki bez informacji. Odbiór powinien pokazać różnicę i wymagać decyzji. Automatyczne „ostatni zapis wygrywa” kasuje pracę bez ostrzeżenia.
Po każdej zmianie workflow wykonaj test zależny i jeden poprawny kontrolny. Zapisz skutek publiczny, nie tylko status API. CMS ma chronić treść i cudze zmiany.
Informacja dla wyszukiwarek po publikacji
Zaktualizuj sitemap i zgłoś ją zgodnie z procesem. IndexNow może przekazać listę nowych i zmienionych adresów. Nie wysyłaj szkiców ani adresów z noindex. Zgłoszenie jest informacją, nie obietnicą pozycji ani natychmiastowej indeksacji.
Zapisz odpowiedź systemu zgłoszenia i datę. Błąd nie powinien cofać poprawnej publikacji automatycznie, ale wymaga właściciela i ponowienia zgodnie z zasadami. Nie generuj pętli tysięcy żądań przy awarii API.
Przy wycofaniu również zaktualizuj mapę i przekazuj właściwy adres. Proces ma być spójny dla publikacji i zmian, nie tylko dodawania nowych tekstów.
Mały rytm redakcyjny
Agent przygotowuje wersję z kartą źródeł i testów. Redaktor odbiera diff, poprawia i zatwierdza. System publikuje konkretną wersję, sprawdza publiczny wynik i aktualizuje mapę. Każdy krok ma właściciela.
Po tygodniu przeglądaj błędy i czas odbioru. Jeżeli redaktor przepisuje całość, popraw zakres pracy agenta zamiast zwiększać liczbę publikacji. Automatyzacja ma zmniejszać pracę, nie produkować nową redakcję po fakcie.
Szybki kanał drobnych poprawek
Nie każda zmiana wymaga pełnego procesu nowego artykułu. Dla literówki lub aktualizacji jednego linku przygotuj ograniczony zakres edycji i test zależny. System nadal zapisuje wersję oraz autora. „Drobna poprawka” nie może oznaczać prawa do przepisania całego tekstu przez agenta.
Zdefiniuj, jakie pola wolno zmieniać tym kanałem. Jeżeli agent modyfikuje tytuł SEO lub canonical, przechodzi do pełniejszego odbioru. Granica powinna być techniczna, nie tylko opisana w instrukcji. To chroni przed rozszerzaniem zakresu przy okazji prostej edycji.
Po publikacji sprawdź publiczną wersję i brak wpływu na pozostałe pola. Szybki kanał ma ograniczać biurokrację, nie kontrolę skutku.
Konflikt przy pracy kilku autorów
Gdy człowiek i agent edytują równolegle, zapisz wersję bazową każdej zmiany. Przy zapisie porównaj ją z aktualną. Jeżeli są różnice, pokaż je zamiast nadpisywać. Automatyczne scalanie tekstu może zmienić sens nawet przy braku konfliktu w tej samej linii.
Osoba odbierająca powinna zobaczyć obie wersje i wybrać lub połączyć je świadomie. Model może pomóc opisać różnice, ale nie rozstrzyga, która decyzja redakcyjna jest właściwa. Zachowaj autorów i czas każdej zmiany.
Test obejmuje edycję tego samego pola i dwóch różnych. Pierwsza wymaga decyzji. Drugą też trzeba ocenić pod kątem znaczenia: na przykład nowy tytuł może nie pasować do równocześnie zmienionej treści. Łącz zmiany automatycznie tylko wtedy, gdy reguły i kontrola spójności uzasadniają taki wybór. Nie blokuj całej redakcji przy każdej niezależnej poprawce.
Dowody gotowości wersji w CMS
Przy wersji zapisz listę sprawdzonych punktów z wynikiem i dowodem. Brak testu oznacza brak gotowości, a nie domyślne „prawdopodobnie działa”. Jeżeli źródło jest bot-protected, oznacz sposób ręcznej weryfikacji zamiast fałszywego zielonego statusu.
Redaktor zatwierdza konkretny zestaw odpowiedzi i wersję. Po nowej edycji zależne punkty wracają do odbioru. Nie trzeba powtarzać całej listy przy zmianie jednego słowa, ale każdy skutek musi być nadal pokryty.
Przy zmianie właściciela publikacji przekaż nie tylko konto, ale także listę otwartych wersji i zależności. Nowa osoba powinna zobaczyć, które teksty czekają na decyzję i jakie automatyzacje mogą działać dalej. Wygaszenie starego tokenu wykonaj po potwierdzeniu dostępu zastępcy, nie jako pierwszy krok blokujący całą redakcję.
Raz na jakiś czas sprawdź, czy role nie rozszerzyły się przy kolejnych integracjach. Agent dodany do prostego zadania może z czasem dostać prawa do wszystkich sekcji. Ogranicz je ponownie i uruchom test odmowy. Minimalne uprawnienia są procesem utrzymywanym, nie jednorazową konfiguracją.
Przy zakończeniu kanału publikacji zapisz ostatnią wersję, zamknij otwarte szkice i wyłącz tokeny. Nie zostawiaj automatycznych zadań, które będą publikować po zakończeniu współpracy. Sprawdź ostatni skutek w docelowym serwisie oraz brak nowych operacji po odwołaniu.
Jeżeli treść przechodzi do nowego systemu, zachowaj identyfikatory i autorów. Test migracji obejmuje adresy, metadane, obrazy i uprawnienia, nie tylko sam tekst. Publiczny wynik po przełączeniu powinien być porównany z wersją źródłową.
Aeneia Audit pomaga zmapować prawa i proces. Przy strukturze publikacji pomocny jest proces CMS Aeneia Signal.
Przed przekazaniem treści do nowego CMS porównaj adres, autora, ilustrację i prawa do publikacji z wersją źródłową. Wersję po imporcie odbierz w docelowym serwisie, zanim uznasz migrację za zakończoną.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
