Page Lifecycle: every published post checked at day 30, 60 and 90, then improved
Example data for Cedar Grove Animal Hospital, a fictional vet clinic whose site runs on the theStacc website builder. 33 screens; 19 are tagged Needs backend work. The whole feature is new; the tag marks only scheduled jobs, outside APIs and AI work. Linear THE-297. Updated 6 Nov after a design review: owner tasks, a monthly summary, phone views, no-data and failed-sync states, a title-fix proposal, a declining post, the SEO lead's view, and one site version per change.
What this shows
- Publish at about 80% quality, then let Search Console data decide what each post needs.
- Every post gets a job (bring a call, feed a service page, build authority), a target query with real demand and a format copied from the top results, before it is written. Links, sitemap, indexing and IndexNow happen at publish.
- The first 30 days are not silent: day 3 crawled, day 7 indexed, day 14 what Google thinks the post is about.
- Each post gets a state at day 30, 60 and 90, and the causes behind it, ranked: format, missing topics, internal links, authority. Off-target queries are split into worth chasing and not.
- Every change is a diff the owner approves, with a protect list the rewrite may not remove. Merging always asks again. One change per post per 28 days.
- Every change is judged 28 days later against the rest of the site and against the post's job, and can be rolled back. Healthy posts are left alone except for fact refreshes and snippets.
- The whole site is checked too: hub pages, orphans, overlaps and off-topic posts, with link changes shipped per cluster.
- Owner tasks (links from other sites, photos, reviews, facts for a rewrite) sit beside the proposals. A rollback offer joins the queue until acted on.
- Each approval ships as its own site version. A verdict is clicks against the rest of the site: +20 points worked, -20 worse.
- The owner gets one page a month in their own numbers, sent with the invoice. When data is missing the screen says unknown, never zero.
1Before publishing and the first 30 days
A new post gets a job, a target query and a format before it is written. In the first 30 days we show crawling, indexing and the first queries, so the silent phase is not silent.
NP01New post: job, target and format before writingNeeds backend workDemand lookup (DataForSEO keywords) and a search results format scan at write time
PG03Page: too new to judge
PG05Page: day 14, what Google thinks it is about
PG01Pages: every post with its stateNeeds backend workScheduled checkpoint job: a Search Console snapshot for each post at day 30, 60 and 90, then every 90 days2Checks, states and causes
The day-90 check of one post with its causes ranked, an off-target post where one query is worth chasing and one is not, a post Google has not indexed, and a healthy post that started declining because the site competes with itself.
PG02Page: day-90 check for the dog nails postNeeds backend workSearch results format scan for the target query (DataForSEO SERP): video carousel, image pack, what the top 3 pages contain
PG06Page: off target, which query to chaseNeeds backend workIntent match check between each query and the post's topic (classifier)
PG04Page: not indexed at day 60Needs backend workSearch Console URL Inspection API: index status, last crawl and request indexing
PG07Page: declining, and why we waitNeeds backend workWeek-by-week query overlap between two posts3Review and approve proposals
Seven proposals and a rollback, each a diff with its evidence. Prices are confirmed on the proposal. Merging asks for confirmation and gets its own shipped screen. Each approval ships as its own site version.
RV01To review: 7 proposals and 1 rollback
RV02Proposal: match the intent (video and steps)Needs backend workAI rewrite of the post, step diagram and nail chart generation, 90-second video from the video module
RV03Proposal: add a section for an unplanned query
RV04Proposal: retarget a page nobody searchesNeeds backend workDataForSEO keyword volumes (US) to find a nearby query with real demand
RV09Proposal: title and meta only for a low click rate
RV05Proposal: merge a page with no demand
RV06Confirm merge and redirect
RV08Merged: v39 is liveNeeds backend workWebsite builder publish with redirect; URL inspection of the old URL after 7 days
RV07Approved: how it shipsNeeds backend workWebsite builder publish of a new site version, plus a Search Console indexing request for the changed URL4What only the owner can do
Links from other sites, photos, reviews and facts for a rewrite become tasks next to the proposals, each saying what it unblocks.
5Did it work
Every change with before and after numbers 28 days later, compared with the rest of the site as a control and judged on the post's job. A rollback for a change that made things worse. One page a month, in the owner's numbers, sent with the invoice.
HS01Change historyNeeds backend work28-day before and after measurement job: a Search Console snapshot for each changed post 28 days before and 28 days after it ships
HS02One change: it worked
HS03Roll back a change that made things worse
RP01This month: what the engine did, in your numbersNeeds backend workMonthly summary job and email6The whole site
Clusters, hub pages, orphans, overlaps and off-topic posts. Link changes ship per cluster as one change and do not count against a post's 28 days.
7Where it meets what customers already have
The Analytics insight cards say what to do now and hand over to Pages. Keyword suggestions feed new posts and sections.
8When the data is missing
No Search Console: every state is unknown, never zero. A failed sync pauses checks and marks every number with its date.
9Two users
The SEO lead's queue on a managed site, and the settings that say who decides what and where changes ship.
10On the phone
The checkpoint email, the queue on the phone and a title fix approved from it.
