Flower e-commerce — title, meta, and schema structure cleanup

A flower brand that grew from a local shop into online retail. The products and photography were strong, but search engines weren't reading the site's information hierarchy, so visibility had plateaued.

In the first meeting, when I started looking through the site, the first thing that stood out wasn't a design or product photography issue. The content and the day-to-day operations were solid. The problem was a different question: how is the search engine seeing this site?

After flipping through five or six pages, it was clear the meta descriptions were inconsistent from page to page. Some pages had the company introduction copy verbatim, others were blank, and some had a 100-plus character chunk of body text awkwardly truncated. The first line that shows up in search results was doing something different on every page.

Opening up the HTML source on a product page surfaced a bigger problem. There was no Product structured data (JSON-LD) at all. In other words, the search engine had no explicit way to know these were even product pages. Without that, there's no eligibility for rich results — no chance of star ratings, prices, or availability appearing in search.

There was one more finding. The same product listings were showing up at both /category/bouquet and /tag/bouquet. From the search engine's point of view, that creates a "which one should I index?" problem. This is what people call duplicate content conflict, and both URLs end up losing in search.

The original scope was just an "SEO audit." But if we cleaned up only the meta and left the rest, the gains would leak out elsewhere. So I walked the client through the diagnosis, explained the priorities and the reasoning for the additional work. The work itself is one-time, but the effect compounds — it's more rational to fix the whole structure in one pass than to revisit it piecemeal later.

We started with consolidating the meta templates. All product page titles were normalised to a single format: '{product name} | {category} | {brand}', and meta descriptions were auto-generated by combining the product short description, price, and free shipping flag. The point was to build a structure where future pages can't easily drop the meta by accident.

Next we applied three JSON-LD schemas: Product, BreadcrumbList, and Organization. Product included SKU, brand, price, and availability, plus aggregateRating on products that had reviews — enough to make the pages eligible for star ratings and prices in search results. BreadcrumbList made the category-to-product path readable for search engines, and Organization reinforced the brand entity signal across the whole site.

The category/tag indexing conflict was resolved with canonical and robots meta. Every /tag page got a canonical pointing to the corresponding /category, plus noindex, so all signals consolidated on the /category side. OG tags and Twitter cards were unified around 1200×630 images, and the sitemap was rewritten as a dynamic handler so admin and draft pages are excluded automatically.

For about two to four weeks after launch we let the index settle, then checked indexing status and rich result eligibility in Search Console. The directly measurable changes were clear: every product page passed the schema validator as "eligible for rich results," pages with missing meta dropped to zero, and the duplicate /tag URLs were cleaned up. These are things we can verify directly, independent of external variables — which is exactly why we're comfortable putting them in a case study.

Finally, we handed off an operations guide so SEO would carry forward automatically when the client adds new products. It walks through which fields drive which output, how to submit index requests in Search Console for new releases — written at a level a non-specialist can follow. Leaving behind a structure the client can keep running on their own was the last step of the engagement.