What AI agents can and cannot do on a corporate website: an honest list for web, marketing and legal teams

Yes, for a large share of the work, and no, not on their own. An AI agent is a model that can use tools: read your pages, open a pull request or CMS draft, run a test, take a screenshot, file a report. That is enough to handle most of the maintenance and production backlog a web team carries. It is not enough to make the calls a company is accountable for.

The useful question for a director of web is not whether agents can manage the site. It is which tasks they own, which tasks they draft for a person, and which tasks they never touch. The rest of this article answers that, task by task, and then covers what IT and legal reviewers will ask before they sign off.

We run our own site this way and build the same setup for clients. If you want the full roster of agents and how their work flows through review, read our AI agent web team operating model. This article is the shorter, buyer-side view: the boundary.

Agents do best where the task has a clear input, a written rule and a check that can pass or fail. These are the tasks we hand to agents first.

• Content updates from a brief: a product name change across 40 pages, a new event block, a refreshed FAQ, drafted to your brand voice and approved claims.
• Technical SEO fixes: missing or duplicate titles, wrong canonicals, redirect chains, orphan pages, sitemap gaps and noindex mistakes.
• Broken links: scheduled crawls that find internal and outbound links that fail, with a proposed fix or redirect for each.
• Schema: Organization, Article, FAQ and Breadcrumb markup generated from the page and validated before review.
• Accessibility checks: contrast, form labels, heading order, alt text presence and target size, run on every changed page.
• Performance budgets: lab runs on key templates against agreed limits for page weight, JavaScript and Largest Contentful Paint.
• Translation drafts: first drafts of French, German or Italian pages from the approved English version, queued for a native reviewer.
• A/B test setup: variant builds, the test plan, the tracking events and the readout template, once a person has chosen the hypothesis.
• QA screenshots: every changed page captured at phone and desktop widths and compared with the live version.
• Reporting: weekly digests on site health, indexing, Core Web Vitals and conversions, with the exceptions on top.

Two of these deserve a caveat. Accessibility tools help, but the W3C is clear that tools cannot check every accessibility requirement and can produce misleading results, so a person still reviews keyboard flows and screen reader behaviour. Translation drafts save time, but a native speaker approves anything that publishes.

Some work depends on judgment, accountability or facts that only your company holds. Agents can prepare it. People decide it.

• Brand and positioning decisions: what you say you are, who you are for and what you will not claim.
• Legal and regulatory claims: compliance statements, certifications, security claims, environmental claims and anything a regulator could read.
• Final approval on every change that goes live.
• Customer quotes, logos, case study figures and other proof: an agent cannot confirm a customer agreed to be named.
• Pricing and commercial terms, including discounts and what a plan includes.
• Design direction: the look, the hierarchy and the trade-offs between brand and conversion.
• Crisis communications: outages, incidents, recalls, layoffs and anything the press is asking about.
• Anything that publishes without review. If a workflow lets an agent push straight to production, the workflow is the problem.

Google's guidance on generative AI content makes the same point for search: it asks site owners to fact-check and review AI-generated content for accuracy before publishing, including titles, meta descriptions, structured data and alt text, and it warns that generating many pages without adding value can break its scaled content abuse policy.

Use this table as the starting point for your own approval matrix. The last column is the one to show legal and IT.

Security reviewers will recognise two risks from the OWASP Top 10 for LLM Applications. The first is prompt injection: OWASP notes that indirect prompt injection happens when a model takes input from external sources such as websites or files. A website agent reads web pages all day, so treat everything it reads as untrusted. The second is excessive agency, which OWASP traces to excessive functionality, excessive permissions and excessive autonomy. OWASP's mitigations for both include least privilege and human approval for high-impact actions. In December 2025 OWASP also published a separate Top 10 for Agentic Applications for 2026, which is worth handing to your security team.

Legal reviewers will ask about claims and accessibility. Claims are covered by the rule that agents only use an approved claims file and every number carries a source. On accessibility, the current W3C Recommendation is WCAG 2.2, dated 12 December 2024, which adds nine success criteria, including 2.5.8 Target Size (Minimum) at 24 by 24 CSS pixels. Agents can check that criterion on every change. Conformance statements are still a person's call.

Marketing leaders will ask whether the project will last. Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls, and estimated that only about 130 of the thousands of agentic AI vendors are real. Risk controls are the part you can design in from day one.

Governance for website agents is mostly configuration, not policy documents. These five controls are the minimum we set up.

• Approval: every change that goes live passes a named approver. We use the same human-in-the-loop approval workflow we describe for marketing agents: draft, automatic checks, queue, decision, execution, log.
• Permissions, read vs write: agents get read access to the site, analytics and search data by default. Write access is granted per task, to a branch or a CMS draft state, never to publish, never to DNS, never to production secrets or CRM admin.
• Audit trail: every agent action records what changed, why, which rule or brief it followed and who approved it. Version control or CMS history does this if you turn it on.
• Rollback: any change can be reverted in one step, and someone has tested that before the first agent change ships.
• Accountability: a named person owns each part of the site. The agent is never the accountable party; the approver is.

This is easier on some stacks than others. A statically generated site where every change is a reviewed commit gives you the audit trail and rollback for free, which is one reason we argue for enterprise headless without a DXP. On a traditional CMS, the same controls come from roles, draft states and workflow settings.

Do not start with the whole site. Start with one section, a few tasks and a written approval matrix, then widen scope as the evidence comes in.

1. Week 1, pick scope: choose one site section, such as the blog or the product pages, and three or four agent tasks from the table above, usually broken links, technical SEO, accessibility checks and reporting.
2. Week 1, write the rules: brand voice, an approved claims file, the performance budget (for example Core Web Vitals targets of 2.5 seconds LCP, 200 milliseconds INP and 0.1 CLS at the 75th percentile) and the approval matrix.
3. Week 2, set permissions: read access everywhere the agents need it; write access only to drafts or branches; branch protection or publish rights held by people.
4. Week 2, turn on the audit trail and test a rollback on a staging change before anything goes live.
5. Week 3, run the agents in proposal mode: every output goes to the approval queue, and approvers record edits and rejections with a reason.
6. Week 3, invite IT and legal to review a sample of real proposals, not a slide deck.
7. Week 4, review the numbers you collected: items proposed, approved unchanged, edited and rejected, and time to approve.
8. Week 4, decide the next scope: add tasks where edits are rare, tighten rules where they are frequent, and keep legal, pricing and proof with people.

At the end of 30 days you will have your own evidence on quality and review time, which is worth more than any benchmark we could quote.

The honest answer to "can AI manage my website" is that agents can do the work and people must own the decisions. Teams that get this right do not ask agents to be careful. They make it impossible for an agent to publish, price, claim or redesign without a person saying yes, and then they let agents do everything else quickly.

Our website development service builds this setup on your stack, with the approval matrix, permissions and audit trail in place from the first week. If you want to see what it would look like for your site, talk to our team.