A local business AI stack built around PHP pages and agent files

A local business does not need a complicated web app to make its services and locations easier for people and automated systems to understand. A small, deliberate stack can do the job: server-rendered PHP pages, accurate structured business data, files intended for agent discovery, and an audit loop.

Consider a two-location plumbing company as a working example. This is a build pattern, not a report of a BuiltToWinWeb customer or a guarantee of search results. BuiltToWinWeb offers custom PHP websites hand-coded from scratch, and its WebAgentScan service evaluates site readiness for AI agents with a score out of 100. Its AI Indexing Pack is a separate set of files and endpoints for agent discovery.

Start with pages that answer local questions

Give each location a stable, useful URL, such as /locations/northside/. Keep the service area, phone number, opening hours, address and available services on the page where a visitor can see them. Do not create a near-identical page for every neighborhood just to multiply URLs. A page earns its keep when it gives a customer specific, verified information.

For a modest site, PHP templates can share the header, footer and page structure while keeping each location’s text and details distinct. That makes updates more manageable than copying whole pages, but it still requires someone to maintain the templates and check the content. Hand-coded PHP is a way to control the implementation; it is not an automatic speed or SEO guarantee. Keep the page focused, avoid shipping unnecessary assets, and test the actual page on a phone and a slow connection.

Store location details in one maintained source where practical, then use it to render both the visible page and its structured data. This reduces the chance that a phone number changes in one place but not another. If the business moves or changes hours, update the source and verify every affected page.

Describe the business, then publish agent context

Add JSON-LD structured data that describes the business at that location. Choose an appropriate LocalBusiness type and include only details that are accurate and supported by the page, such as the business name, address, telephone, opening hours and URL. The structured data should agree with the visible content. It is not a substitute for clear page copy, and adding it does not make location information correct or guarantee that an AI system will find or cite the business.

For a closer look at the separate jobs involved, the distinction between local business schema and llms.txt is useful: structured fields describe an entity, while a text file can add readable context. Neither replaces accurate pages.

The BuiltToWinWeb AI Indexing Pack can add agent-facing material such as llms.txt, agents.txt, agent cards and other discovery files. Its published description also includes a working MCP server and bot access control. Treat these as an additional interface, not a second copy of the whole site. Put concise, current information in the files, point readers toward authoritative pages, and avoid publishing private data or claims the business cannot substantiate.

There is a real maintenance cost here. Files can become stale when locations, service areas or hours change. Build a simple release checklist: update the source information, render the pages, check the structured data and confirm that the agent-facing routes still return the intended content. Discovery files do not force a crawler to visit or quote a site.

Use readiness scans as a debugging loop

Once the pages and files are live, run WebAgentScan against the domain. BuiltToWinWeb describes it as a hosted SaaS tool that checks multiple readiness metrics and returns a score out of 100 across seven graded areas. Use the result to prioritize investigation, then inspect the affected pages and endpoints yourself. A score is a diagnostic signal, not proof of factual accuracy, security, rankings or citations.

Keep a short record of what changed between scans. If a score moves, identify which change plausibly explains it rather than treating the number as an outcome by itself. Recheck after material edits to navigation, location data, access rules or agent-facing files. Do not expose private application routes just to improve an audit result.

Where this stack fits—and where it does not

This approach fits a service business with a manageable set of locations and a developer available to maintain its PHP templates and content. It offers control over page structure and avoids dependence on a site template, but that control brings responsibility: there is no platform doing all updates for you. A larger operation with frequent inventory or location changes may need a content workflow and data validation beyond a handful of templates.

The useful target is not a perfect score. It is a site whose location details agree across visible pages, structured data and agent-facing files, with each route tested after changes. That is a practical local business AI tech stack: clear PHP pages, truthful local SEO data and a measured readiness check, with no promise that any one file will make the business discoverable everywhere.