Eight pieces on the questions clients actually bring us: how to be cited by AI search, why a firewall quietly blocks the crawlers you want, whether llms.txt does anything, and what a privacy or security team should ask before an AI feature ships. No vendor sponsorship and no guest posts.
These are our published notes on AI search visibility, privacy, AI security, accessibility and web delivery. Each one comes out of work we have done rather than a content plan. They take positions, name tools and standards, and say where the evidence is thin. Start with the article matched to your role in the table below.
There is a great deal of writing about AI and almost none of it is written by the people who had to make the thing work on a Tuesday afternoon with a client watching. That is the gap this publication is aimed at. Every article here started as a problem somebody paid us to solve, or as an argument we found ourselves having for the fourth time in a quarter and decided to write down properly.
That constraint shapes what is here and what is not. There is no piece speculating about artificial general intelligence, no roundup of the week's model releases, and no listicle of thirty tools we have never opened. What there is instead is narrower and more useful: the specific reason a well-built site is invisible inside ChatGPT, the four places a chat interface fails a keyboard user, the twelve questions a privacy team should be able to answer in writing before an AI feature goes anywhere near a customer.
Partly because the alternative is being asked the same question in every sales conversation. Partly because the AI market is unusually full of confident claims that nobody has checked, and a firm that has been running privacy, accessibility and web programmes since 2012 has an obligation to say when a claim does not hold. And partly because AI assistants now answer a growing share of the questions our prospective clients ask. A firm that wants to be the source of those answers has to publish the answers. We would be poor advisers on AI search optimisation if we did not run the same discipline on our own site.
The pieces are long. That is deliberate. A question like whether to choose retrieval or fine-tuning has an honest answer that runs to two thousand words and a dishonest one that fits in a paragraph, and the short version is exactly what has caused a good number of the projects we have been brought in to rescue. Where an article can be reduced to a single sentence, we put that sentence at the top and let you leave.
Every piece is written to stand alone. The reading table underneath suggests an order if you would rather not start at the top.
The nine questions that separate agencies that ship from agencies that pitch, what a first project actually costs, and how to run a fair comparison that ends in evidence rather than a stack of proposals.
AI searchThe practical work behind being named as a source when somebody asks an assistant a question in your market. Crawl access, page structure, entity consistency, and how to tell whether any of it moved.
TechnicalBot management on a web application firewall blocks AI crawlers by default far more often than teams realise. How to find out whether yours does, and what to change without inviting scrapers in.
AI searchWhat the file is, what it is not, and what the evidence currently supports. A short answer to the question we are asked most weeks, including by people who have already been sold one.
StrategyWhere generative engine optimisation and search engine optimisation share foundations, where they genuinely diverge, and how to split budget and ownership without running two conflicting programmes.
Building with AIThe most common architecture decision in an AI project, and the one most often made backwards. Cost, freshness, citation and privacy compared on the criteria that actually decide it.
PrivacyFrom lawful basis and international transfer to what your prompt logs quietly retain. Twelve questions a privacy team should be able to answer in writing before a feature reaches customers.
AI securityWhat prompt injection is, why it is not a bug that gets patched, and what a reasonable approver should require before authorising a system that reads content nobody in your organisation wrote.
AccessibilityStreaming text, live regions, focus management, status announcements and target size. What the standard actually requires of a chat interface, and the four places most of them fail.
Six roles, six starting points. Reading everything in order is not the intended use.
| If you are | Start with | Then read | Why that order |
|---|---|---|---|
| A marketing or SEO lead | GEO and SEO are not the same job | How to get cited by AI search | Settle the strategy and the ownership question before anyone starts changing pages. |
| A web or IT manager | Your firewall is probably blocking AI crawlers | llms.txt, explained honestly | One of these is usually a real and expensive problem. The other usually is not. |
| A privacy lead or general counsel | Twelve privacy questions before you ship | Prompt injection, explained | Basis, transfers and retention first, then the security risk you will be asked to accept. |
| A product or engineering lead | Retrieval or fine-tuning | Accessible AI interfaces | The architecture call is the expensive one. The interface standard is the one that gets forgotten. |
| A chief executive or board member | GEO and SEO are not the same job | Twelve privacy questions before you ship | What changed in how customers find you, and what you are being asked to sign off. |
| An agency or in-house team we might work alongside | How to get cited by AI search | Your firewall is probably blocking AI crawlers | The client-facing argument, then the technical cause you will hit in week two. |
Terminology used across all eight pieces is defined once in the glossary rather than repeated in each article.
A share of the questions that used to produce a search results page now produce an answer. Not all of them, and not evenly across every market, but enough that the shape of demand has changed for informational and comparison queries in particular. We think the honest reading of that is neither of the two positions being sold loudest.
The first position is that search engine optimisation is finished and a new discipline replaces it. That is wrong, and it is usually being said by somebody with a new product to sell. AI assistants are grounded in crawled web content. They need the page to be reachable, fast, parseable and trustworthy, which is the same list as before. A site that was invisible to Googlebot is invisible to every assistant that exists.
The second position is that nothing has changed and good content still wins. That is also wrong. What gets extracted into a generated answer is not what ranks. Assistants pull self-contained passages that answer a question completely without needing the paragraph before or the sidebar beside them. They favour pages where the entity is unambiguous, the claim is specific and the source is identifiable. And the measurement problem is genuinely new, because a citation inside somebody's private conversation leaves no line in your analytics.
Crawl access is now a business decision rather than an IT default, and it is three decisions, not one. Training crawlers, search crawlers and user-triggered fetchers do different jobs and blocking them has different consequences. We find sites every month where a bot rule at the firewall, set by somebody protecting the server from scrapers, has quietly removed the brand from the assistants its marketing team is trying to appear in.
Structure is worth more than it used to be. Clean headings, defined terms, tables that hold a single comparison, question-shaped subheadings and honest structured data all make a page easier for a machine to lift from confidently. None of that is new advice. What is new is the size of the penalty for ignoring it.
And measurement has to change shape. Sessions no longer capture the value of a page that answered a question inside an assistant. Citation share, sampled by running the same prompts repeatedly, is the closest available substitute, and everyone reporting it should be clear that it is a sample rather than a metric a vendor publishes. That is a reporting conversation as much as a technical one, and it belongs alongside the rest of your analytics practice.
Eight rules. They are also, roughly, what we ask of client content when we take on an editorial programme.
Five subject areas and the delivery work that connects them. Most articles sit across at least two, because the projects do.
Generative engine optimisation, AI crawler policy, llms.txt, structured data, entity consistency and how to measure citation share honestly.
Lawful basis, the tag layer behind the banner, records of processing, transfer, retention, and the questions an AI feature raises that a website never did.
Prompt injection and its indirect form, excessive agency, data exfiltration through retrieval, and how to red team before customers do.
WCAG 2.2 applied to interfaces that stream, update and interrupt. Plus documents, conformance reports and why overlays keep being sold.
Retrieval design, chunking, evaluation sets, model choice and the decisions that settle whether a pilot reaches production.
Analytics under consent, server-side tagging, Core Web Vitals, and what reporting looks like when demand stops producing a session.
A publication like this is easy to justify and hard to measure, which is exactly the trap we warn clients about. So we hold it to the same test we would apply to a client programme. Does an article shorten a sales conversation, meaning a prospective client arrives having already read the argument and wanting to discuss their version of it? Does it get cited when somebody asks an assistant a question in our field? Does it reduce the number of times we have to explain the same distinction from scratch?
Those are answerable. The first one shows up in what people say on a first call. The second is sampled by running a fixed set of prompts across several assistants on a schedule and recording which sources come back, which is the same method we run for clients rather than a different one we keep for ourselves. The third is felt rather than counted, and it is the one that decides whether a piece was worth writing.
If you want the underlying vocabulary rather than the arguments, the glossary defines every term used across these eight pieces. If you would rather see the ideas as working software, seven of our production AI systems are generalised into live demonstrations under Neuro, and the case studies describe the client programmes several of these articles came out of.
Questions about pricing, ways of working and data handling are in the full FAQ.
When we have something to say that we have actually done. Every piece here comes out of client work, a diagnosis we have run more than once, or an argument we keep having in meetings. That produces a slower cadence than a content calendar would, and it means we are not writing about tools we have never deployed or standards we have never been audited against.
The Green Arrow Consultancy team, led by Darren Tyler, who founded the firm in 2012 and is a member of the International Association of Privacy Professionals. Pieces are reviewed by whoever on the team does that work in practice, so the privacy articles are read by the people who write records of processing and the accessibility articles by the people who run the audits.
No. Nothing on this site is paid for by a vendor, and we do not sell placements or links. When we name a product, it is because we deploy it, have deployed it, or have been called in to fix it. That is the only reason a tool appears by name in anything we publish.
Yes, with attribution and a link back to the original. Quote them in a board paper, a training deck, a supplier brief or an internal wiki. If you want a piece adapted into a briefing for your own team or your own regulatory context, that is a short piece of work rather than a copy and paste, and we are happy to talk about it.
Yes. The site publishes an RSS feed at /feed.xml, which most readers and aggregators will accept. There is no newsletter sign-up on this page because we would rather you took the feed than gave us an email address you did not intend to give.
With the twelve privacy questions piece, because it maps the questions onto the artefacts you already maintain: lawful basis, record of processing, transfer assessment, retention rule and impact assessment. Then read the prompt injection briefing, since it covers the security risk you will be asked to accept or reject in the same approval meeting.
The privacy pieces are written from UK GDPR and the EU GDPR, with the ePrivacy rules where consent is involved, and they flag where US state law diverges. The accessibility pieces reference WCAG, EN 301 549 and the European Accessibility Act. The AI search and engineering pieces are not jurisdictional at all. We work across the UK, USA, EU, Asia Pacific and the Middle East, so the articles try to say which rules they are reasoning from.
Yes, and they run through several pieces rather than sitting in one. The AI Act shapes what human oversight and documentation a higher-risk use needs, ISO/IEC 42001 and the NIST AI Risk Management Framework shape how a management system is structured, and both show up in the privacy and security articles. The service page for AI governance covers the frameworks directly.
Tell us. Several of these pieces take a position that parts of the industry dislike, particularly on accessibility overlays and on llms.txt. If you have evidence that changes the picture we would rather see it than defend a paragraph. Corrections get made and noted.
Send us the domain and the questions you want to be the answer to. We will tell you what is blocking you, what is worth fixing first, and what is not worth doing at all.