How to run a monthly review for an AI-maintained marketing site

A monthly website review does not need a board deck. It needs one honest operating question: what did the site learn that should change the next cycle of work?

For a small marketing site, the answer may be thin. That is fine. Thin signal is still useful if it prevents fake certainty. The mistake is turning one analytics table into a strategy, or ignoring the table because it is not statistically mature.

An AI-maintained site should use the review to decide what gets shipped, repaired, escalated, held, or left alone. The review is not complete when the report exists. It is complete when the evidence supports one bounded decision.

Define the monthly review contract

Do not open five dashboards and improvise a story. Start by fixing the scope of the review.

A useful contract names:

• the review period and the exact as-of time for volatile evidence;
• one commercial path, such as homepage → service page → proof asset → contact confirmation;
• the current offer and the human who can approve a change to it;
• the production routes, form path, canonical-domain behavior, and release checks that must stay healthy;
• the available evidence sources and the job each source is allowed to do;
• the proof, privacy, account, and commercial boundaries the review cannot cross;
• the maximum release size the next cycle can safely absorb;
• the person who owns the resulting action or no-change decision.

This keeps the review from becoming a vague assessment of the whole site. One month may review the audit path. Another may review the maintained-marketing path. A site-wide rewrite is not a monthly decision merely because a dashboard looked quiet.

Build the evidence ledger before interpreting anything

The review needs an evidence ledger, not a pile of screenshots. For each source, record its authority, coverage period, availability, and limitation.

Classify every source as available, unavailable, sparse, stale, or conflicting.

• Available means the source can answer its assigned question for the review period.
• Unavailable means the review cannot make a decision that depends on it.
• Sparse means the observation can be recorded but should not carry a broad conclusion.
• Stale means the source predates a material site, offer, or tracking change.
• Conflicting means two authoritative sources disagree and the conflict must be resolved before publication or release.

Unknown is a valid evidence state. Hiding unavailable access behind a confident summary is not.

Start with health, not interpretation

Before reading traffic or search data, check whether the commercial path is actually working.

A useful health gate covers:

• production homepage, relevant service, proof or article, contact confirmation, build log, and 404 behavior;
• canonical-domain and matching www redirect behavior;
• contact form presence and the approved public endpoint;
• build, CI, deployment, and dependency status;
• open pull requests, failed checks, stale issues, and unresolved review comments;
• rendered desktop and mobile behavior for the pages changed during the period.

A health failure changes the review order. If the form is broken, the monthly insight is not “traffic quality is low.” The finding is “the path to a lead is broken.” Repair that before interpreting conversion.

Do not average a defect into a score. A critical path is either working, blocked, or unknown.

Separate attention from conversion

Page views are attention. A thank-you page view or human-confirmed inbox lead is conversion evidence. Do not blend them because the chart looks lonely.

For GPTCrafted, the current rule is deliberately conservative:

• Cloudflare path data shows which public pages received measured attention.
• /thank-you/ is the site-side proxy for successful form submission.
• Bernd’s human-sanitized inbox summary is the only lead-quality source.
• CTA clicks and calculator use remain soft intent signals unless an approved privacy-safe event provider records them.

That separation stops the site from claiming a lead because someone read an article. It also stops a low-traffic month from being padded with invented funnel language.

When attention exists without conversion evidence, inspect the path before rewriting the offer. Check whether the page has a clear next step, whether the linked proof answers the buyer’s objection, and whether the form works. Do not conclude that the market rejected the offer from page views alone.

Review search as questions with page owners

Search Console data is useful when it tells you what readers are trying to understand. The monthly review should translate queries into page jobs.

Ask:

• Which query belongs to an existing page owner?
• Is the correct owner receiving the impression or click?
• Does the page answer the reader’s decision, or merely repeat the query?
• Are several pages competing for the same job?
• Is the title accurate but the next step weak?
• Does a new question require a section on an existing owner rather than another URL?
• Would the query attract the wrong buyer or require a risky promise?

The output should be a page decision: improve a title, add a missing section, fix an internal link, consolidate ownership, or leave the query alone.

If Search Console access is unavailable, record the blocker and do not manufacture a query strategy from the sitemap or Cloudflare path data. Crawl exposure is not Google indexation. A page view is not a search query.

Inspect releases and maintenance residue

A monthly review should look backward long enough to catch the upkeep created by recent work.

For each meaningful release, check:

• the route and reader decision it changed;
• the source evidence used at the time;
• whether PR, CI, deployment, visual, and production checks passed on the final code;
• whether the release added a page owner, analytics event, integration, dependency, proof claim, or review obligation;
• whether the linked issue and build log still describe the live behavior;
• whether a promised follow-up, later query review, or account-side action remains open;
• whether the change should be kept, repaired, reverted, or simply monitored.

This is maintenance residue: work created by earlier work. A new page needs later ownership review. A new event needs a reporting purpose. A new proof claim needs source custody. If nobody owns that residue, the site is accumulating debt while calling itself maintained.

Audit proof before polishing copy

AI can make weak claims sound confident. Monthly review is where those claims get caught.

Check the site for:

• customer names, logos, screenshots, testimonials, or metrics without approved source material;
• synthetic demos that are not clearly labeled as synthetic;
• service pages that promise outcomes the team cannot substantiate;
• old copy that describes a process, price, integration, or authority boundary that changed;
• public-form or analytics language that implies raw submission text enters automation;
• precise-looking numbers, rankings, scores, or deltas that have no documented method;
• stale dates, provider names, or access claims presented as current truth.

Every material claim should end in one of four states: supported, narrowed, removed, or blocked pending approval.

Do this before headline polish. A sharper headline on an unsupported claim is just a better-looking liability.

Test representative review cases

Do not judge the monthly review only on a healthy, data-rich month. Use representative cases that force different decisions.

A useful review can distinguish these cases without smoothing them into one “site health” score.

Rank the backlog by consequence and evidence

The review should not end with twelve equal recommendations. Rank candidates using four questions:

1. Consequence: what remains broken, misleading, or commercially weak if this waits?
2. Evidence: which current source supports the proposed change?
3. Authority: can the operator act, or does the decision require a human, credential, provider, or proof approval?
4. Release size: what is the smallest change that improves the reader’s decision and can be verified safely?

Production defects, broken intake, false claims, and dangerous ambiguity outrank another article. An existing owner page with a specific missing decision usually outranks a new competing page. A blocked account-side task should stay blocked rather than being disguised as content work.

For each candidate, record:

• the route or system affected;
• the evidence and its state;
• the reader or operational decision improved;
• the smallest review surface;
• the required tests and production checks;
• the authority owner;
• the stop condition.

Choose one primary action and, at most, one contingency if the primary remains blocked. “Improve SEO” and “publish more content” are not backlog decisions. They are the absence of one.

Choose ship, repair, escalate, hold, or no change

End the review with an explicit verdict.

• Ship: current evidence supports one bounded change inside the approved operating boundary.
• Repair: a production, proof, ownership, or process defect must be corrected before optimization.
• Escalate: the useful next step requires account access, proof approval, commercial authority, or another external decision.
• Hold: evidence may become useful after a defined crawl, release, or review window; name the date or trigger.
• No change: the site is healthy and the available evidence does not justify a public release.

No change is not an empty report. Record what was checked, what remains unknown, why the backlog did not clear the evidence bar, and what would trigger another decision.

A maintained site does not need visible activity every month. Publishing unsupported filler to prove the automation is busy is a worse outcome than leaving a healthy page alone.

Keep the human approval boundary visible

The review can be assisted by AI. The approvals should not disappear into it.

Human approval is still needed for:

• customer proof, private examples, screenshots, logos, testimonials, and metrics;
• positioning, offer scope, pricing, and commercial commitments;
• DNS, deployment settings, analytics providers, form recipients, credentials, billing, and paid services;
• outbound replies to leads or customers;
• anything that stores, summarizes, or routes raw public-form submissions.

The site can be maintained through an operator loop. It cannot approve its own commercial evidence or promote untrusted intake into agent context. That boundary is part of the operating model, not a footnote.

Produce one decision packet

Keep the final artifact short enough to review and complete enough to act on:

1. Scope and as-of time: period, commercial path, current offer, and owner.
2. Health gate: routes, build, deploy, form, redirects, 404, and rendered checks.
3. Evidence ledger: source, coverage, authority, state, and limitation.
4. Attention: page paths and referrers, with sparse-data caveats.
5. Search: query-to-page ownership when access exists; explicit unknowns when it does not.
6. Conversion: thank-you views plus human-sanitized lead count when available.
7. Proof audit: supported, narrowed, removed, and blocked claims.
8. Release residue: follow-ups, ownership, and maintenance created by recent changes.
9. Ranked backlog: consequence, evidence, authority, release size, and stop condition.
10. Verdict: ship, repair, escalate, hold, or no change.
11. Verification plan: source checks, tests, build, visual review, CI, deployment, and production smoke.
12. Next trigger: owner, date or condition, and the evidence needed next time.

That is enough. The point is not to make a prettier report. The point is to stop the site becoming an abandoned brochure with newer adjectives.

For the broader release cadence around this review, read the minimum operating loop for an AI-maintained marketing site. For the complete operational path, use the AI-maintained marketing operations workflow.

If you want the packet format rather than just the method, inspect the synthetic marketing-site monthly review sample output. It shows health, signal, proof, backlog, and approval decisions without pretending synthetic data is a client result.

If your site needs this loop, bring GPTCrafted one live commercial path, the available analytics and release history, one stale or disputed page, the proof rules, and a named approval owner. That is enough to start an AI-Maintained Marketing System with an evidence-backed decision instead of a content quota.