AI agents no longer read only the prompt typed by a user. They can browse pages, retrieve documents, inspect email, follow links and call business tools. That broader context makes them more useful, but it also creates a new website risk: an instruction embedded in external content can be mistaken for a command.
This is indirect prompt injection. A malicious or compromised page may contain text intended to change an agent’s behaviour, bias a recommendation, expose data or trigger an action the user did not request. The instruction may be visible, hidden with styling, placed in metadata or delivered through user-generated content. The important distinction is not whether a human notices it. It is whether an AI system processes untrusted content as both information and authority.
For SEO and digital teams, this is not an invitation to hide instructions for crawlers. It is a governance problem spanning content, web security, analytics and AI operations. Google’s current spam policies explicitly cover attempts to manipulate generative AI responses in Search, while its long-standing rules prohibit hidden text used to manipulate search systems. A durable response therefore protects people and agents while keeping the site transparent, useful and indexable.
What prompt injection means for a website
NIST defines prompt injection as an attack that exploits the combination of untrusted input with a prompt created by a higher-trust party. On a website, the risky material does not have to look like a conventional software exploit. It can be ordinary language inside a page, product review, document, comment, data feed or linked resource.
A direct injection is entered by the person using the AI. An indirect injection arrives through content the system retrieves. The second form matters to website owners because the page becomes part of somebody else’s agent workflow. The site may be the attack source, an unwitting carrier after a compromise, or simply one untrusted input among many.
The likely consequences depend on the agent’s permissions. A read-only research tool might produce a distorted summary or an inappropriate recommendation. An agent connected to email, customer records, publishing systems or purchasing tools may have a much larger impact. OWASP’s prompt-injection guidance identifies risks including unauthorised actions, data exposure, system-prompt leakage and persistent manipulation.
Why this is not simply another metadata tactic
Search optimisation helps machines understand content that is also useful to people: clear titles, descriptive headings, crawlable links, structured data and accurate entity information. Prompt injection tries to establish a new instruction hierarchy inside content. It is closer to social engineering than to legitimate optimisation.
That difference should guide editorial decisions. A sentence written for a customer may also help an AI system understand the page. A hidden command written only to force an AI to recommend the brand has no comparable user purpose. Even if it appears to work in one experiment, it creates policy, security and reputation exposure without producing a stable visibility asset.
How website content becomes an attack surface
The risk is broader than the page copy maintained by a marketing team. Modern sites assemble content from content-management systems, reviews, forms, support platforms, embedded widgets, product feeds, partner data, PDFs and JavaScript. Any surface that an agent can retrieve should be classified according to its source, edit permissions and downstream use.
A practical inventory should include at least:
- public HTML, including content hidden by CSS or positioned off-screen;
- user reviews, comments, forum posts and public profile fields;
- uploaded PDFs, office documents and image metadata;
- product specifications and marketplace feeds supplied by third parties;
- support knowledge bases, tickets and public status messages;
- embedded tools, widgets and remotely loaded scripts;
- URLs, redirects and query parameters that an agent may follow;
- private repositories or documents included in retrieval systems.
The inventory is useful even when no attack is found. It reveals who can publish machine-readable content, where moderation is weak, which data crosses trust boundaries and which sources can influence an automated decision.
Visible, hidden and compromised instructions
An injection can be visible in a comment or product description. It can also be obscured through zero-opacity text, off-screen positioning, HTML comments, non-printing characters or content that only appears to a particular client. OWASP also treats documents, email, images and retrieved knowledge as potential delivery channels. Teams should therefore inspect rendered output and source data rather than relying on a visual page review alone.
Compromise creates another route. Google’s spam documentation notes that attackers may inject pages, code, hidden links or hidden text into an existing site. A website that has not intentionally published manipulative instructions can still distribute them after a vulnerable plugin, stolen account or weak moderation path is abused.
The SEO boundary: clarity is legitimate, manipulation is not
Google’s spam policies for web search now state that manipulation includes attempts to influence generative AI responses in Google Search. The same document defines hidden-text abuse as content placed to manipulate search systems while remaining difficult for human visitors to see. Examples include white text on a white background, zero opacity and off-screen positioning.
There are legitimate reasons to hide and reveal content. Tabs, accordions, slideshows, tooltips and text intended for assistive technology can improve usability. The deciding issue is purpose and accessibility, not the presence of a CSS rule. Content designed for people and exposed through a meaningful interaction is different from an invisible command designed only for a machine.
For businesses pursuing AI visibility, the safer route remains strong evidence: accurate service information, verifiable claims, clear ownership, useful original analysis, consistent brand entities and credible external references. An AI visibility and source-readiness assessment can evaluate whether agents can access and interpret that evidence without adding manipulative instructions to the page.
Do not treat prompt injection as a shortcut to citation. An agent’s response is generated within a particular product, model, session and source set. A hidden command may be ignored, filtered, exposed to the user or treated as evidence of abuse. It can also conflict with search policies even when it targets an AI system rather than a conventional ranking algorithm.
A seven-step prompt-injection audit for web teams
The objective of an audit is not to prove that every future attack can be stopped. It is to reduce exposure, constrain consequences and create evidence that suspicious behaviour can be investigated.
1. Define the agent and its permitted outcome
Start with the business workflow, not a list of suspicious phrases. Record what the agent reads, what it is allowed to decide, which tools it can call and what would count as an unacceptable result. A research assistant that only produces a draft has a different risk profile from an agent that can send messages, modify a catalogue or access customer information.
State the intended task narrowly. Broad instructions give external content more room to redirect the workflow. NIST’s 2026 agent-security analysis describes agent hijacking as malicious instructions inserted into external data such as websites, email or code repositories. The operational response should therefore constrain what the agent can do when detection is imperfect.
2. Map trust boundaries and content owners
Classify each input as trusted operational instruction, controlled business data or untrusted external content. Name the owner of each publishing route and document how changes are approved. Pay particular attention to content that moves from public submissions into a retrieval index without moderation.
A complete technical SEO and website audit can extend this map across rendered HTML, templates, canonical pages, scripts, status codes and indexable files. The security review should add permissions, ingestion paths and agent-tool connections rather than treating the public page as the whole system.
3. Compare rendered pages with source output
Crawl representative templates and save both the rendered text and underlying markup. Look for zero-opacity content, off-screen positioning, unexpected comments, encoded strings, newly injected links and large differences between what users see and what automated clients receive. Check mobile and desktop variants, because conditional content can hide in breakpoint-specific components.
Do not automatically remove all visually hidden text. Screen-reader labels and accessible descriptions may be legitimate. Review intent, placement and ownership before changing them.
4. Audit user-generated and third-party surfaces
Test the moderation path for reviews, forms, public profiles, uploaded documents and partner feeds. Determine whether markup is sanitised, whether links are rewritten safely, whether files are scanned and whether suspicious content can be quarantined before it enters an agent’s retrieval system.
Third-party data should keep its provenance. If a product description came from a supplier, the agent and the monitoring system should be able to distinguish it from an internal policy. Flattening every source into one undifferentiated text block removes a useful security signal.
5. Separate instructions from retrieved data
The application layer should label external material as data, not authority. OWASP recommends structured separation between system instructions and user or retrieved content, plus input controls, output validation and monitoring. This is a defense layer, not a guarantee: natural language remains difficult to classify perfectly.
Preserve source boundaries during retrieval. Pass the URL, owner, timestamp and trust classification alongside the text. Avoid concatenating raw pages directly into the same field as operational instructions. Where practical, extract the minimum information needed for the task rather than providing an entire page or document.
6. Limit tools, credentials and irreversible actions
Assume some malicious inputs will evade detection. Microsoft’s defense guidance recommends layered controls, isolation of untrusted content, continuous monitoring and least privilege. In practice, give an agent only the tools and data required for the current task, prefer short-lived permissions and separate read access from write access.
Require a person to approve external messages, payments, account changes, publishing, deletion and the transfer of sensitive information. The approval view should show the actual action, destination and data involved. A vague confirmation such as “continue” is not meaningful oversight.
7. Monitor for drift and rehearse response
Log the source content used, tool calls proposed, approvals requested and final outcome. Alert on unexpected destinations, unusual data access, changes in tool sequence, repeated instruction-like strings and actions outside the original task. Retain enough context to explain what the agent saw without storing sensitive data longer than necessary.
Create a response procedure: suspend the affected connector or tool, preserve logs, remove malicious content, review credentials, check other pages from the same publishing path and retest the workflow. If the site was compromised, treat the prompt injection as a security incident rather than only an SEO cleanup.
Why external actions deserve separate controls
A page can attempt to push an agent towards a malicious link, hidden request or unexpected tool call. OWASP includes disguised links, hidden image requests, tool manipulation and data exfiltration among relevant attack patterns. A control that only scans visible prose will miss the downstream action the content is trying to cause.
Web teams should validate the final destination, restrict which data can be inserted into URLs, block unexpected schemes and require approval before an agent sends confidential values or crosses into a new system. Analytics teams should also review whether sensitive query parameters are being retained in logs, dashboards or third-party tracking systems.
This control benefits ordinary users as well as agents. Clean redirect policies, disciplined URL design and reduced exposure of personal data are sound web practices independent of AI.
A practical operating model for marketing and security
Prompt injection crosses team boundaries, so ownership should be explicit. Marketing controls claims, templates and publishing quality. SEO checks crawlability, rendering and search-policy alignment. Engineering enforces sanitisation, provenance and permissions. Security owns threat modelling, monitoring and incident response. Legal and privacy specialists review high-risk data use where necessary.
A useful monthly review can track four evidence-based measures: the proportion of agent inputs with recorded provenance; the number of public publishing routes with moderation controls; the share of high-impact agent actions requiring approval; and the time taken to investigate a simulated injection. These are control measures, not promises that a system is secure.
Red-team tests should be authorised, isolated and designed around the real workflow. Include visible instructions, hidden markup, uploaded documents, redirect chains and compromised third-party content. Confirm not only whether the agent rejects the text, but whether a failed detector can still lead to an unauthorised tool call. NIST recommends a continuous monitor-and-update security model built around recurring red-team work, updated defenses, impact limitation and recovery rather than a one-time claim of protection.
Conclusion
Prompt injection turns web content into part of an AI system’s security boundary. A website can be manipulated, compromised or used as an untrusted source even when its conventional search performance looks healthy. The correct response is neither panic nor a single blacklist.
Build a content inventory, preserve provenance, separate instructions from data, minimise permissions, validate links, require meaningful approval and monitor agent behaviour. At the same time, keep public content visible, accurate and written for people. That combination supports search and AI discoverability without relying on hidden commands that create policy and security risk.
Frequently asked questions
What is indirect prompt injection on a website?
It is an instruction embedded in web content or another external source that an AI system mistakenly treats as a command. It may try to change a recommendation, reveal information or trigger an action outside the user’s request.
Can hidden prompts improve AI search visibility safely?
No reliable or policy-safe outcome can be assumed. Google prohibits hidden text used to manipulate search systems and its spam policies include attempts to manipulate generative AI responses. Useful, visible and verifiable content is the safer long-term approach.
Is a prompt-injection scanner enough protection?
No. Detection can reduce exposure, but sophisticated attacks may look like ordinary persuasive content. Use layered controls including provenance, content isolation, limited permissions, output checks, monitoring and human approval for consequential actions.
Which website areas should be audited first?
Start with user-generated content, document uploads, third-party feeds, remotely loaded widgets, hidden HTML, redirects and any source that feeds an AI retrieval system without human moderation.
Does legitimate visually hidden accessibility text create a violation?
Not by itself. Google distinguishes manipulative hidden text from content used for legitimate user experience, including text intended for screen readers. Review purpose, implementation and ownership before removing accessible content.
Sources and references
- NIST CSRC: Prompt injection definition
- NIST CAISI: Insights into AI agent security
- OWASP: LLM Prompt Injection Prevention Cheat Sheet
- Microsoft Learn: Defend against indirect prompt injection attacks
- Google Search Central: Spam policies for Google web search
- NIST: Continuous monitor-and-update security model for AI systems
