How We Built MediaWura.com to Be Found by AI Assistants

We built mediawura.com so that search engines and AI assistants can read it, understand exactly what MediaWura is, and describe us accurately. That came down to a handful of decisions: name every search and AI crawler in robots.txt, publish llms.txt files generated from the site itself, write one entity statement and reuse it everywhere, add structured data, give every service its own page and FAQ, and publish our process and our guides. This post explains each decision and why, so any business can copy it.

One thing first. We are not claiming rankings, traffic or AI mentions from any of this. Nobody controls what an assistant says. What we can control is how easy we are to find, read and quote.

What problem were we solving?

An AI assistant can only recommend a business it can reach, understand and trust, so we designed the site around those three needs. Reach means crawlers are allowed in. Understanding means the facts are stated plainly, in the same words, everywhere. Trust means the claims are specific, consistent and never inflated.

Three rules guided the build:

1. One source of truth. Every fact about MediaWura lives in one place in our code and flows to every page and file that uses it.
2. Let the machines in. Block only what has no business being public.
3. Answer the question first. Every page opens with the answer a buyer or an assistant is looking for.

Why does our robots.txt name AI crawlers one by one?

We name each search and AI crawler we want in robots.txt so that no blanket rule, plugin or platform default can ever shut one out by accident. The list includes Googlebot, Google-Extended, Bingbot, Applebot, DuckDuckBot, GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User, Amazonbot and others.

Each one gets the same rule as everyone else: allow the whole site, except three paths.

• Disallow: /api/ because these are the endpoints behind our contact and careers forms and our ad tracking, not pages.
• Disallow: /studio because that is where we edit content.
• Disallow: /thank-you because it's the page people see after submitting a form, and it should never appear in search results or AI answers.

Not all crawlers do the same job, and the official documentation is worth reading before you decide what to allow.

OpenAI says that if you block OAI-SearchBot, your site won't appear in ChatGPT search answers. Google says Google-Extended controls whether content is used to train future Gemini models and for grounding in Gemini Apps, and that it does not affect inclusion or ranking in Google Search.

We allow the training crawlers too. That is a business choice: we want future models to know who we are. A publisher selling its writing might reasonably choose differently.

We generate robots.txt from a short list in our code, with a pointer to our sitemap. Adding a new crawler is a one-line change. Our guide to where AI assistants get their information explains which crawler feeds which assistant.

Why do we publish llms.txt and llms-full.txt?

We publish llms.txt as a short Markdown map of the site and llms-full.txt as the full text of every service page, our process and our guides, both generated from the same data that builds the website.

The short file opens with our entity statement, then lists the essentials: founder, location, who we work with and how pricing works. Then come links to every service grouped by the job it does, the company pages, case studies and every guide on the blog, which now has more than 200. The full file adds the company facts, the seven process steps, each service's details and FAQs, and the body of every guide.

We're honest about the limits. Google's guide to optimising for generative AI search says Google Search doesn't use llms.txt files, and that having one will neither help nor harm your visibility there. Google also says it is fine to keep one for other services that use it.

So why bother? Because ours costs nothing to maintain. It's generated automatically and refreshed every hour, so it can never disagree with the pages. It gives any tool or agent that does read Markdown a clean, complete description of us without parsing menus and layouts. See what llms.txt is for the format.

Why do we reuse one entity statement everywhere?

We wrote one paragraph that says exactly what MediaWura is and reuse it word for word in our Organization structured data and at the top of both llms files. Every shorter description on the site, from the about page to page summaries, says the same things in fewer words. It reads:

MediaWura is a sales and marketing agency and AI video agency in Accra, Ghana. It helps businesses that make GH₵ 20,000 or more a month get more customers through Facebook, Instagram and TikTok ads, AI video ads, Google Ads, SEO, AI search optimisation, copywriting, content, websites, branding, event branding and sales funnels built on PayLead. It also builds custom software, web and mobile apps, AI automation and business systems, and runs recruitment ads that find qualified staff. MediaWura was founded in 2025 by Nana Asiamah and is part of Wura Group.

It answers what, where, for whom, since when, by whom, and who owns it. Every sentence can be lifted alone and still be true.

It lives in one constant in our code, so changing it once changes it everywhere. Different descriptions on different pages force an assistant to guess which one is right. Our guide to entity SEO explains why matching facts matter.

Why does our about page have a company facts table?

A two-column table is the easiest format for a person or a machine to lift a single fact from, so our about page ends with a "Company facts" table. Its rows are company name, type, founded, founder, headquarters, parent company, sister companies, services, who we work with, areas served, notable clients, pricing, contact and website.

Each row is one fact in one cell. "Founded: 2025" can't be misread. "Founder: Nana Asiamah (Asiamah Emmanuel Donkor)" gives both names people search for. The same list feeds llms-full.txt, so the table and the file always match.

Below the table, an FAQ answers the questions people ask about any company: what MediaWura is, who founded it, where it is, what it offers, who it works with and how it's connected to PayLead. Both PayLead and MediaWura are part of Wura Group.

Which structured data do we use, and why?

We use Organization, FAQPage and BreadcrumbList markup, plus Service on each service page and BlogPosting on each guide, so every page states what it is in a format machines don't have to interpret.

• Organization on the about page includes description (the entity statement), foundingDate, founder with an alternateName, parentOrganization (Wura Group), address, areaServed and contactPoint.
• A site-wide Organization block adds our logo and sameAs links to our social profiles.
• FAQPage mirrors the visible FAQs on the about page, every service page and the process page.
• BreadcrumbList shows where each page sits, such as Home, Services, AI Search Optimisation.

Two honest caveats. Google stopped showing FAQ rich results in Search from 7 May 2026, according to its documentation updates. And Google's generative AI guide says structured data isn't required for AI features. We keep the markup because it states our facts without ambiguity for any system that reads it, and because Google still uses structured data for other rich results. The visible text does the real work, and the markup always matches it. See schema markup for small businesses.

Why does every service have its own page and FAQ?

Each service has its own page so that a question like "who does AI search optimisation in Ghana?" has one clear URL that answers it. Every service page follows the same order: the headline promise, the problem, what changed in the market, how we do the work, what you get, who it suits, how it starts and the questions people ask.

The FAQs are written to be quoted, so we only write answers we would be happy to see repeated word for word. On our AI search page, the first question is "Can you guarantee ChatGPT will recommend me?" and the answer begins "No one can guarantee what an AI tool says." An over-promise in an FAQ is exactly the kind of line an assistant might repeat to a buyer, so we don't write them.

Every service page also feeds llms-full.txt automatically.

Why is our process public?

We publish our process so that "what is it like to work with MediaWura?" is answered in our own words, not pieced together by an assistant from scraps. The page walks through seven steps, from the first call to the monthly review, with an FAQ covering timelines, how the fee is set and who does the work.

We don't publish prices. We do publish how pricing works: a fixed fee, quoted in writing after a free audit, with ad budgets paid separately. An assistant that reads that can answer a pricing question accurately instead of inventing a number.

Why do we write so many guides?

Our guides answer the specific questions our buyers ask, which gives search engines and assistants something precise to cite. Each one opens with a direct answer, uses question-style headings, puts comparisons in tables and ends with common questions. Each carries BlogPosting markup naming the author, appears in our sitemap with its publish date and is included in llms-full.txt. Our guide to writing content AI answers quote covers the method.

What did we deliberately not do?

Some shortcuts would have been easy, and we skipped them on purpose.

• No separate content for bots. Crawlers and people get the same pages; the llms files are generated from those pages.
• No inflated claims. No "best agency in Ghana" lines, no guarantees, no statistics we can't back up.
• No published price list. Prices change; a stale number quoted by an assistant does more harm than none.
• No fake reviews or bought mentions. Google's guide warns that inauthentic mentions aren't as helpful as they seem.

How can you copy this for your business?

You can apply the same approach on any website in an afternoon or two.

1. Check your robots.txt. Allow the search and AI crawlers you want, by name, and block only private paths.
2. Write one entity statement: what you are, where, for whom, since when, by whom.
3. Add a company facts table to your about page, one fact per row.
4. Give every service its own page, with an FAQ answering real questions honestly.
5. Add Organization, FAQPage and BreadcrumbList structured data that matches your visible text.
6. Publish how you work and how pricing is set, even if you don't publish prices.
7. If your platform makes it easy, generate an llms.txt from your pages rather than writing it by hand.
8. Check monthly what assistants say about you. See how to measure AI search visibility.

Common questions

Does allowing AI crawlers guarantee AI assistants will mention us?

No. Allowing crawlers makes you readable, not recommended. Assistants also weigh reviews, mentions on other sites and how clearly your pages answer the question.

Should every business allow AI training crawlers?

Not necessarily. Allowing search crawlers matters for visibility in AI answers. Training crawlers are a separate choice that depends on whether you want your content used to train future models.

Is llms.txt worth it if Google ignores it?

Only if it is cheap to keep accurate. A generated file that matches your pages costs nothing. A hand-written one that goes out of date can mislead.

Do we still need FAQPage markup now that Google has stopped showing FAQ rich results?

It is optional. The visible FAQ text is what matters. We keep the markup because it is accurate, costs nothing and states our answers clearly for any system that reads it.

Can a small business do this without a developer?

Most of it, yes. The entity statement, facts table, service pages and FAQs are writing work. Robots.txt, structured data and llms files may need a developer or a plugin, depending on your platform.

If you'd like the same groundwork done on your website, see our AI search optimisation service or book a free strategy call.