A beauty store goes from two articles a month to one guide a day

Who the client was and what was getting in the way

An online cosmetics store selling skincare, makeup, and perfume. It is a typical e-commerce business where winning is not only about price, but also about whether a customer finds the store while looking for an answer to a question such as “how do I choose a moisturizer for combination skin?” The blog existed, but was updated only occasionally.

The numbers did not add up. Copywriters charged one hundred to three hundred dollars per article. At a reasonable pace of ten to twenty articles a month, that comes to one thousand to six thousand dollars a month for content alone. In practice, the store published two or three articles a month, when time and budget allowed — a pace that gives search engines little reason to take the blog seriously.

The articles were also written without checking what people actually search for. Topics came from ideas, not data. The result was predictable: polished articles, low rankings, and no traffic. Basic optimization was missing too: a structure search engines could understand and a question section marked up to qualify for enhanced search results.

What we built

We built a system that handles the entire path from a topic idea to a finished post in the store’s dashboard. Keyword research and publishing run in Python, Claude writes the content, finished articles are stored in Supabase, and the whole process runs on a schedule on the client’s own server.

The starting point is the store’s sitemap. The system reads it, identifies product categories, and uses them to generate seed queries, such as how to choose a particular product or which cosmetics in a category are best. It sends those queries to search suggestions and extracts specific long-tail phrases — the kind with less competition and clearer intent. Before moving on, the system checks whether it has already written about that phrase.

Writing follows a fixed template: an introduction, headed sections, lists, a comparison table, six to eight questions with answers, and a conclusion with a call to action. We keep keyword density within a reasonable range, add internal links matched to URLs from the sitemap, and link to reputable industry sources. The question section gets structured data to give it a chance of appearing in enhanced results. Images are selected automatically.

The finished text is converted into a format the store accepts and sent to its dashboard. The client approves publication, so a person has the final say.

How it works today

The build took ten days across four stages: analyzing the store and designing the content template; building the keyword-research module; building the writing module; and, finally, integrating with the store and deploying on the server.

The system now runs once a day, overnight. In the morning, the dashboard has a new guide of three to five thousand words, with a table, a question section, and links to categories and products. Someone at the store reviews and publishes it. Other than approval, no manual work is needed: no topic brainstorming, commissioning, deadline tracking, or pasting in the content.

The outcome

The system runs continuously, around the clock. Articles are three to five thousand words long — enough to answer a question in depth rather than just touch on the topic. The question section is automatically marked up with structured data, giving every article a chance to appear as an enhanced result. There are no recurring content-production fees after implementation.

What we would do differently

The weakest link turned out to be the quality of keyword sources. Search suggestions are free and fast but say nothing about how many people actually search for a phrase. During the first few days, the system wrote well-researched articles on topics almost no one asked about. On the next project like this, we will combine suggestions with reliable search-volume data before anything enters the queue.

We also started checking for topical duplicates too late. We checked for exact keyword matches, but in cosmetics two different queries can mean the same article. Comparing topics by meaning rather than by the wording of a search phrase should be part of the first version.