A content audit is not a calendar check. It is a state check.
A field called publishedAt can look decisive. It contains a date, it appears in editorial views, and it often drives listing order. But in Sanity, a date is not proof that a document is published.
Dates Describe Intention
The publication date describes when content is intended to appear, or when it did appear. The actual publication state lives in the document model. A published document, a draft document and a scheduled version are different records with different visibility rules.
That distinction matters whenever teams use automation. A script that only queries normal published content may correctly report what is live, but it can miss draft-only work, scheduled versions and unpublished changes. That makes the audit look cleaner than reality.
The States That Matter
For a Standard Insight, the audit starts by confirming the document type and slug. Then it checks the published document, the draft counterpart and any Content Release version document. Those three checks answer different questions: what is live, what is waiting, and what has been locked into a scheduled release.
A draft-only document can be complete and ready, but still not scheduled. A scheduled version can be complete and future-dated, but not yet visible on the public site. A published document can have a past date and still be absent from a route if the frontend filters it out for another reason.
Normal Queries Can Mislead
Sanity perspectives are powerful because they let different clients see different slices of the dataset. They are also a common source of false confidence. A published perspective is correct for the public website, but it is not enough for editorial auditing because it intentionally excludes drafts and release versions.
When the question is operational rather than public, use authenticated raw inspection. Look for drafts, versions and release records directly. Then compare that state against the website query, so the team knows both what editors have prepared and what visitors can access.
Audit the State, Then the Schedule
A strong audit separates content readiness from release readiness. Required fields, Portable Text, references, SEO and images determine whether the article is complete. Release state determines whether it is scheduled. Public queries determine whether it is already live.
Those checks should happen before creating new content and before scheduling anything. Otherwise an automation can collide with an existing editorial slot, duplicate a slug or treat a complete draft as if it were already in the publishing queue.
Why This Protects the Workflow
Content systems are part of application architecture. They deserve the same precision as code deployment. When teams audit state properly, editors keep control of the calendar, engineers keep control of the integration, and automation can move faster without confusing readiness with publication.
