Broo Café Case: SEO and GEO for an Online Coffee Brand

Where did Broo Café start as an online coffee brand?

A store with a real product and a site that promised things the operation didn't do.

Broo sells specialty coffee from Sonsón, Andes and Caicedo in Antioquia, plus a cold brew concentrate and coffee cocktail sachets: seven products in three categories, paid through Mercado Pago and shipped within Colombia. It also exports green coffee by quote. The store ran on WordPress with WooCommerce, Elementor and a commercial theme whose demo is a beauty store.

Step one was a crawl of the entire site with our own scripts, before changing anything. That baseline report is what lets you say later what improved without guessing. Here's what it found:

• Five broken internal links, four of them in the footer of 21 URLs, pointing to “face”, “body” and “hair” categories inherited from the demo.
• No product page with an H1, and eleven pages with two H1s because Elementor split each title across two widgets.
• Schema declaring a coffee shop with opening hours for a store that only sells online, and articles with authors on pages that weren't articles.
• A FAQPage marking up 10 questions where the page showed 15.
• Promises the store didn't keep: subscriptions with an inactive plugin, international shipping and a payment gateway other than the real one.
• Merchant Center with mistranslated shipping rates, no return policy and the cold brew flagged as an alcoholic beverage.

How did we organize the store and its schema in WooCommerce?

No redesign and no platform switch: each page with a clear job and schema that tells the truth.

We didn't build the store or redesign it. The design is the one Broo already had, and the rule was that no fix could change how it looks. Split H1s were solved by keeping the first fragment as the heading and appending the rest for screen readers, while the second widget kept the same typography as an element with no heading semantics. A visitor doesn't notice the difference; a crawler does.

On that base we organized the catalog. Six product slugs were normalized so name, weight and URL said the same thing, with 13 301 redirects from the old addresses. Each product page got a unique title of up to 60 characters and a 140 to 160-character description, and categories got their own copy instead of an empty variable. System pages, like the order thank-you page, came out of the sitemap.

All of our code lives in a seven-module must-use plugin, with no edits to the theme or the plugins. The schema module builds a single graph: an OnlineStore with a Medellín address and a return policy, a Product with brand and SKU, and an Offer in Colombian pesos. Shipping details weren't written by hand: they're generated from WooCommerce's real shipping zones, so if a rate changes, the schema changes with it.

The English version followed the same principle. Instead of duplicating products and splitting inventory and the Merchant Center feed in two, the English product page is purchasable, but on add-to-cart it's swapped for its Spanish twin. Stock, orders and reports still live on a single product, and the customer sees the cart and checkout in English.

How did we plan the blog for search and AI?

Every article opens with the answer and backs it with a primary source.

The blog was planned in two batches totaling 32 articles. The first, twelve pieces the owner approved along with their keywords, was scheduled for Mondays and Wednesdays from 29 September to 5 November 2026: brewing methods, cold brew, French press, processing, whole bean or ground, V60, Chemex, AeroPress, moka pot and cocktails. The second, twenty articles, came out of a Q4 trend research pass and publishes between 26 October and 9 November.

All of them follow the same template: a 40 to 60-word quick answer with its source, a table of contents, H2s written as questions, five FAQs and a FAQPage with the same visible text. The twelve in the first batch cite 38 primary sources, such as the SCA, the National Coffee Association, Cenicafé or the Hario and Chemex manuals, and every link was checked as returning 200 before publishing.

The author is “Equipo Broo Café”, with no invented credentials. Each article links to its pillar, its sibling articles and products by SKU, and each product page lists the articles that mention it. A link to an article that isn't out yet renders as plain text until the target is published.

What did we do so Google and AI can cite the brand?

Structured data that matches the page and a machine-readable catalog, both generated from the store.

An answer engine cites what it can read without ambiguity, and Google says as much in its documentation: there's no special schema for AI Overviews, but structured data has to match the visible text and Merchant Center has to be up to date. So the priority was to stop the schema contradicting the page, not to add markup for its own sake.

The store's FAQPage is built by reading the accordions in the Elementor document, so the 15 visible questions and the 15 marked up are always the same, even when someone edits one. In Merchant Center, with the owner's approval, we fixed the national shipping rate, handling and transit times and the return policy, and hid the duplicate products the automatic sync had created.

For engines other than Google we publish an llms.txt generated live from WooCommerce: each product with its price in pesos, availability, origin, process, roast, weight and altitude, plus shipping, returns, payment methods, key pages and an English section. It's served as plain text and kept out of the index. Google is clear that its AI features don't need a file like this; we built it because, generated from the catalog, it costs nothing to maintain and it serves the other assistants.

None of these pieces is a result. They're the infrastructure that makes the brand citable; whether it gets cited is measured later.

What results did we measure (and which ones didn't we)?

We measured technical health before and after. Traffic and sales don't have a long enough window yet.

Every phase closed with the same crawler it opened with, on 28 September 2026. These are the numbers from those reports, along with the ones we can't give yet:

What would we do differently?

We'd start sooner on category pages, brand entity and reviews.

On 24 October we ran a read-only audit with Search Console data, live SERP checks, backlinks and AI answer mentions. Its conclusion was clear: the bottleneck is no longer technical. The site crawls clean, the schema validates and Google already shows the product pages with prices in results. What's missing is authority and demand.

With what we learned, we'd do three things earlier. First, category pages built for queries like “café en grano” (whole bean coffee) and “café molido” (ground coffee), which have far more demand than most of the blog topics. Second, entity work from day one: “Broo” shares its name with cafés in other countries, and that confuses search engines and models alike. Third, a system to ask verified buyers for reviews, because a product page with no reviews has nothing to mark up.

We'd also own what went wrong: the blog links to the shop too little, and the automation that replaces old articles left one URL undrafted. Both are on the list. If your store's technical base is already in order, you may not need an audit like this one, but content and authority. And if you aren't selling online yet, start with the store, not the schema.