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 week 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 changed, what stays blocked, and what needs human proof before it goes public.

Start with health, not interpretation

Before reading the numbers, check whether the site is actually working.

A useful monthly review starts with:

• production homepage, offer pages, article pages, build log, and 404 behavior;
• canonical-domain and www redirect behavior;
• contact form presence and the configured public endpoint;
• build and deployment status;
• open pull requests, failed checks, and stale issues.

This keeps the report grounded. If the form is broken, the monthly insight is not “traffic quality is low.” The insight is “the path to a lead is broken.” Different problem. Better fix.

Separate attention from conversion

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

For GPTCrafted, the current rule is deliberately conservative:

• Cloudflare path data shows which public pages got 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 are soft intent signals only if a privacy-safe event provider is approved later.

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

Review search as questions, not keywords

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

Ask:

• Which query belongs to an existing page?
• Which page has the right topic but weak intent match?
• Which important buyer question has no page yet?
• Which query would attract the wrong buyer or a risky promise?
• Which page needs a clearer next step, not more text?

The output should be a backlog decision: improve a title, add a section, publish one article, rewrite a CTA, or leave the query alone. If the query cannot change a page or offer, it is trivia.

Audit proof before polishing copy

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

Check the site for:

• client names, logos, screenshots, testimonials, or metrics without approved source material;
• synthetic demos that are not clearly labeled as demos;
• service pages that promise outcomes they cannot substantiate;
• old copy that still describes a process, price, or integration that changed;
• public-form or analytics language that implies raw submission text is being routed into automation.

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

Convert the review into one shippable change

The review is not done when the report exists. It is done when it selects the next piece of work.

Good monthly decisions sound like:

• “The marketing-system articles are getting the only non-homepage attention; add a monthly review article and link it from the offer page.”
• “The audit-intake guide has no visits; improve internal links before writing another audit article.”
• “No thank-you views appeared; verify the form path and ask Bernd for a sanitized inbox count before changing the offer.”
• “The proof page is important but quiet; add one inspectable demo only if it answers a buyer objection.”

Bad monthly decisions sound like “improve SEO” or “publish more content.” That is not a decision. That is a content treadmill wearing a dashboard costume.

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, and metrics;
• DNS, deployment, analytics-provider, form-recipient, and credential changes;
• outbound replies to leads or customers;
• anything that stores, summarizes, or routes raw public-form submissions.

The site can be maintained by an operator loop. It cannot approve its own commercial evidence. That boundary is part of why the work is trustworthy.

A useful monthly review template

Use a short packet:

1. Health: routes, build, deploy, form, redirects, open PRs.
2. Attention: top pages and referrers, with low-volume caveats.
3. Conversion: thank-you views plus human-confirmed lead count if available.
4. Search questions: queries mapped to page jobs.
5. Proof audit: unsupported claims removed, narrowed, or blocked.
6. Backlog decision: one or two PR-sized changes for the next cycle.
7. Approval needs: anything blocked by proof, accounts, credentials, form routing, or lead data.

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

If your site needs this loop, bring GPTCrafted the current site, analytics access if available, one stale page, and the claims that must not move without approval. That is enough to start an AI-Maintained Marketing System with useful constraints instead of pretending AI content volume is a strategy.