Back in 2015, digital marketers probing the edges of the old paradigm hit on something simple and powerful: they could optimize the product name itself. Instead of a short generic name, they started building specifications into it, gender, size, color, quantity, material. Some product names grew past ten words. It looked strange at the time. It also worked, lifting organic rankings and product-listing ads for the companies willing to try it.

The reason is the long tail. The more words a shopper uses to describe what they want, the more closely a specification-rich product name matches that query. Match the query more closely and you rank higher, earn a higher click-through rate, and convert better. The product name is doing the work most sites leave entirely to the title tag.

The T-shirt, built one specification at a time

Take the most generic product imaginable: a T-shirt. On its own, "T-shirt" competes with the entire internet and wins nothing. Now watch what happens as you add the specifications a real shopper actually searches:

Before · the generic name

T-shirt

One word. Competes with the entire internet. Ranks for nothing.

After · specification-driven

Adidas Men's Black XL Short Sleeve 100% Cotton T-shirt

Ranks for dozens of real searches. Seven specifications, each one a phrase someone types: brand, gender, color, size, type, material, category.

And do not forget the brand name. It is the specification teams leave off most often, and it is the one buyers search by most. Every chip in that second name is a piece of data already sitting in your product record, currently powering a filter and nothing else.

That single name now matches "men's black cotton t-shirt," "Adidas XL t-shirt," "short sleeve 100% cotton t-shirt," and dozens of combinations. None of those searches has the competition of the bare word "t-shirt." Each has a buyer who knows exactly what they want. The generic name captured none of them; the specification-driven name captures the lot.

It works on any product type

The technique is universal. The trick is knowing which specifications matter for each product type, because they differ. Cars, for instance, make the specifications obvious, and they double as a uniqueness engine:

Specifications make every page unique, automatically

A used-car name like "2005 Used Red Ford F150 XLT 4x4 6 cyl 125k Miles" carries new/used, brand, make, model, year, mileage, engine, drivetrain, and color. Beyond the long-tail ranking, look what it does for uniqueness: no two used cars share the same year, color, and mileage. Build names from specifications and the duplicate-content problem solves itself, because the specifications guarantee no two pages are alike. The same is true for furniture: "Besteneer 4 Chair Dark Gray Rectangle Oak Dining Table w/ Leaf 36x72" is unique by construction.

The job, then, is research per product type. Find the specifications people actually use when searching for that kind of product, then build those into the name. For T-shirts it is gender, color, size, material. For cars it is year, make, model, mileage, drivetrain. For a dining table it is seats, color, shape, material, dimensions. Every product type has its own searched specifications. Discover them first; build them into the name second.

Where the specifications already live

Here is why this is practical at scale: the specifications already exist in your database. The same attributes that power your filter sidebar, color, size, material, dimensions, are exactly the ones that belong in the product name. Nobody has to invent them. They are sitting in the product record, currently powering a filter and nothing else.

A function-driven naming instruction assembles the name from those existing attributes in a consistent order, per product type, across the whole catalog. When a product's specifications update, its name updates. You are not naming a hundred thousand products by hand. You are designing one naming instruction per product type and letting it run.

Order matters, and so does restraint

Specification-driven naming is not just cramming every attribute in. The order matters for both ranking and readability. The brand and core product type anchor the name; the most-searched specifications come next; secondary ones follow. "Adidas Men's Black XL Short Sleeve 100% Cotton T-shirt" reads naturally and front-loads the searched terms. The same attributes jumbled, "XL Cotton Black Short Sleeve Men's Adidas T-shirt," reads like keyword soup and ranks worse, because both buyers and Google can tell the difference.

The trap door

The over-application of this technique produces monstrous fifteen-specification names no human reads and Google treats as stuffing. The discipline is to include the specifications buyers actually search and stop. Three to seven, in a readable order, captures the long tail. Fifteen in a jumble captures nothing and looks like spam. Specific and readable, not exhaustive.

The internal-link bonus

There is a second payoff that compounds. When other pages link to a product, the anchor text is usually the product name. A short name produces a weak anchor ("T-shirt"). A specification-driven name produces a rich one ("Adidas Men's Black XL Short Sleeve 100% Cotton T-shirt") that tells Google far more about the destination. Across a catalog with thousands of internal links, that better anchor text accumulates into a real ranking signal, on top of the direct benefit to the page's own H1 and title tag.

So the specification-driven name helps three ways at once: it captures long-tail searches, it makes every page unique by construction, and it strengthens the anchor text of every internal link pointing at it. The raw material already sits in your database. The only thing missing is the instruction that surfaces it. The next Insight covers the hierarchical product-page structure that these names plug into.

From the book

The Specification-Driven Product Names chapter of Sizzle: An E-Commerce Revolution covers the per-product-type specification research, the T-shirt, car, and furniture examples, and how to generate readable names at catalog scale.