Getting Your Website and Guides Ready for AI

Your website, your guides, your training decks, and your referral lists are the raw material for every AI tool in this collection. This is the cohort's playbook for turning that backlog into a knowledge base an AI can use safely, without losing control.

Common Legal Help AI. Working draft for comment. Margaret Hagan, Stanford Legal Design Lab.

Every tool in this part of the collection runs on your content. The Q&A bot, the issue classifier, and the citation verifier are only as good as the guides, forms, and referral data behind them. So before any of them helps a person, your content has to be gathered, structured, tagged, and made safe to serve. This guide is the cohort's playbook for that work, drawn from a working group of state teams building AI-ready knowledge bases from real legal aid content. It is a journey through stages, not a one-time export, and you do not have to reach the end to get value.

Tag your content against the Legal Help Knowledge Standard: the shared issue, jurisdiction, content-type, and audience vocabularies the rest of the field uses →

The journey, in six stages

Step 0: Build the relationships first

Most of the useful content lives in other organizations, so the first work is human, not technical: agreeing on who shares what. State teams have taken different coordination approaches, from a light touch to full federation, and all of them are valid starting points. The right level depends on how many organizations you are working with and how much trust is already in place. Start with the minimal viable contribution and do not overwhelm partners.

Stage 1: Index and tag your content (weeks 1 to 4)

The goal of this stage is to know what you have, where it lives, and what it is about. The tasks: audit your content sources (the website CMS, document management like SharePoint or Google Drive, referral and case-management databases, and expert knowledge in training decks and internal guides); define scope by deciding what is in for phase one, what is authoritative rather than legacy, and what needs legal review before inclusion; choose a gathering method; apply the taxonomy at ingestion; and export everything to a standard schema.

On the gathering method, there is a real choice, and the cohort has a recommendation.

The cohort built its index from a content management system export, from Drupal, WordPress, or similar, and recommends that route. An export gives you the metadata, the revision history, and the internal relationships that a scrape cannot see, and it keeps you in control of exactly what enters the knowledge base. The technique is straightforward: export from the CMS, map the fields to a standard schema, and normalize the jurisdiction and issue codes as you go. Scraping is a reasonable fallback for public content you do not control, and AI-assisted ingestion helps at large volume, but the export is the cleaner foundation.

Much of the most valuable knowledge is not on any public page: service referral data in backend databases, case-acceptance criteria in case-management systems, advocate training in SharePoint and Google Drive, and expertise in people's heads. That content comes in through structured contribution templates, exports, and partnerships. Keep the ask small. A URL, a subject, and the languages a resource is offered in is enough to start, and a light ask is what gets a cautious partner to say yes.

Apply the taxonomy at ingestion, not later: LIST codes for the legal issue, FIPS codes for jurisdiction, a content-type label, language codes, and an authority tier. These vocabularies, the issue codes, the jurisdiction codes, the content types, and the audience categories, are all published as the Legal Help Knowledge Standard, so tag against that rather than inventing your own. Export to a schema where Title, URL, Jurisdiction, Issue, and Content Type are required, Description, Language, Audience, and Last Review Date are preferred, and a unique ID and ingestion date are generated automatically.

Not all content deserves equal trust, and the system should know the difference. Tag every item with an authority tier.

For large volumes, some teams are testing an AI "digitizer layer" that tags and structures incoming content before it enters the knowledge base, with human review and governance on top, so content managers are not tagging every item by hand. The output of this stage is a tagged index of all your content, a clear scope document, authority-tier assignments, and your taxonomy mapping.

Stage 2: Chunk and embed (weeks 5 to 8)

The goal here is to transform content into AI-usable pieces with safety metadata. You define a chunking strategy, add chunk-level safety metadata, create embeddings, populate a vector database, and test retrieval quality. How you split content depends on what it is.

There are three broad strategies: fixed-size chunks of 400 to 500 words with overlap, which work when the source content is well-written; semantic chunking by heading or section, which preserves structure for complex documents; and a hybrid that retrieves many chunks and re-ranks to the best few. People's Law School's Beagle+ bot is a working example of the fixed-size approach: it parses pages into 200 to 600 word chunks with overlap, tags each with source URL, title, topic, and date, embeds them, and stores them in a vector database, re-running the pipeline nightly so the index stays current. It works because the source content is structured consistently, so each paragraph stands on its own.

The most important lesson in this stage is about safety. Disclaimers in a system prompt are not enough, because the model cannot be trusted to surface a warning at the right moment and people often ignore warnings anyway. The stronger pattern, developed for vulnerable users of legal and financial information, is a deterministic set of rules that sits on top of the content and decides how each chunk is displayed.

The safety framework has five parts: deterministic rules on top of the content rather than trusting the model to know what is dangerous; chunk-level metadata tagging each chunk with warnings, scope, and dependencies; linked warnings so a warning travels with every chunk from a page that has one; retrieval rules so some chunks must appear together; and an evaluation process that tests for harm before going live. One team working under an insurance standard put it plainly: before going live, they had to get past the probabilistic behavior of the model and show a deterministic design that limited harm. The output of this stage is a populated vector database, a chunk-level safety metadata schema, and documented safety rules.

Stage 3: Store and connect (weeks 9 to 12)

The goal is to enable filtering, navigation, and cross-references. You set up the storage infrastructure, which is a vector database for semantic search plus a metadata store like PostgreSQL, Airtable, or Sanity for filtering and facets. You define parent-child relationships, like the issue hierarchy from Housing to Eviction to Eviction Defenses, and document-to-section and guide-to-form links. You build cross-references and "see also" connections, and you enable filtering by jurisdiction, issue, content type, and authority tier. Expose all of it through a single interface so any bot, tool, or partner queries the same content the same way; the working group converged on an MCP server as that standard interface. The output is a populated vector database, a metadata store with relationships, and a working search and filter layer.

Stage 4: Test and evaluate (weeks 13 to 16)

The goal is to ensure quality, accuracy, and safety before launch. Define evaluation criteria across retrieval accuracy, answer correctness, safety compliance, and citation coverage. Build a test set of representative queries, edge cases like multi-jurisdiction and complex eligibility, and known-tricky scenarios with conflicting guidance. Run the evaluations with automated metrics, expert spot-checks, and user testing, then iterate: fix gaps in content, improve chunking where retrieval fails, and add guardrails where safety issues show up. The methods for this are the ones in Guide 3, and the grounding and classification findings in Guide 2 and Guide 16. The output is an evaluation framework, test results, and an improvement backlog.

Stage 5: Deploy and maintain (weeks 17 to 20)

The goal is to put it into production and keep it current. Choose initial use cases, like website search, a chatbot, service matching, or advocate tools. Build the interfaces, user-facing and admin, with monitoring dashboards. Then establish maintenance workflows: content update triggers when a law or form changes, a re-indexing schedule, quality monitoring with alerts, and an expert review cadence. This last part is the one every team named as the hardest, because stale content is universal. An AI surfaces an out-of-date form or a repealed rule faster and more confidently than a website ever did, so the knowledge base is a living system, not a delivered project.

Stage 6: Knowledge graph (optional, when ready)

A vector database with good metadata covers search and retrieval, which is what most teams need first. Add a knowledge graph only when you need to answer "given these facts, what applies," when eligibility rules are genuinely complex, or when you want guided exploration rather than search. Define the node and relationship types, populate the graph from your existing content, and build a query interface. Do this only after stages 1 through 5 are working well. The graph is the last step, not the first. One state is planning a graph on the order of two million nodes, connecting organizations, services, eligibility, and issues, and it is building the simpler layers first.

The decisions to make

A few choices shape everything else. How to gather content: CMS export is recommended, with scraping, contribution templates, and AI-assisted ingestion as alternatives. How to chunk: by content type, as above. How to prevent harm: chunk-level rules for high-stakes content, guardrails for emergent risks, and an evaluation framework to catch the gaps. How to handle authority: the four tiers above. When to add a knowledge graph: only when you need rule-based reasoning over facts. How to serve multiple audiences: the same underlying knowledge with different views, tagged by audience level, for the self-help public, brief-advice attorneys, full-representation advocates, and hotline staff. And how to coordinate across organizations:

Production systems to learn from

These patterns are running in real legal aid today. Beagle+ at People's Law School is a public Q&A bot built on the 400 to 500 word chunking approach. Ask ILAO in Illinois is a live bot expanding toward a knowledge graph. The Louisiana Legal Navigator runs on strict content standards and the LIST taxonomy. And several state networks are coordinating multi-organization contribution. The frameworks underneath them are shared: the LIST taxonomy for legal issues and FIPS codes for jurisdiction, both published in the Legal Help Knowledge Standard, and chunk-level safety for harm prevention.

Where to start

You do not need the whole journey to get value. Index and tag one high-traffic issue, tier it, chunk it, put a safety layer in front of it, and serve it through one interface. Grow from there. The standards to tag against are the Legal Help Knowledge Standard, explained in Guide 9, and the shared vocabularies and datasets you can build on are in the inventory, Guide 5.