Every A+ Content article I've ever read — including most of the ones I've written — answers the same question: how do I make this listing's A+ better? That's the right question when you have twelve SKUs. It becomes the wrong question somewhere around forty.
Because when I open a catalog audit on a brand running 140 ASINs, the first number I pull isn't quality. It's coverage. And it's almost always the same shape: twelve gorgeous bespoke A+ projects on the hero SKUs, another thirty or forty carrying a template that was built for a different product and pasted across the line, and sixty to ninety ASINs with nothing at all.
Then I ask who owns it, and the answer is nobody. A+ Content at scale isn't a design deliverable. It's a catalog system, and almost nobody builds it as one — which is why most brands past 20 SKUs have a catalog that's simultaneously over-designed at the top and empty at the bottom.
This is how to build the system.
Both failure modes are the same mistake
The bespoke approach and the copy-paste approach look like opposites. They aren't. They're the same error made in two directions: treating A+ Content as a per-listing design project rather than an architecture with fixed and variable parts.
Bespoke everything is what happens when a brand treats each A+ build as a creative brief. It produces genuinely good work on the SKUs that get attention, and it does not scale — not because of money, but because of throughput. Each project needs copy, layout, image production, mobile QA and a submission cycle. Multiply by 140 and you get a project nobody ever finishes. So it doesn't get finished. The top twenty get done, the middle gets done badly during a slow week, and the tail sits empty for years.
One template everywhere is the overcorrection, and it fails differently. It's fast, it looks consistent, and it produces a catalog where 60 detail pages make the same four claims with the same four icons about products that are not the same. That's not efficiency. That's the redundancy problem at catalog scale — the same claim answered repeatedly while the questions that actually decide the purchase go unanswered on every single page.
The fix isn't a middle setting on a slider. It's a structure.
The fixed layer and the variable layer
Here's the architecture, and it's the entire post in one idea: some things in your A+ are true about your brand, and some things are true about the individual product. Lock the first. Rebuild the second every time.
Run through the modules you'd normally use and sort them.
Fixed layer — true about the brand, identical everywhere:
- Brand Story (this one is literally a brand-level asset — more on it below)
- The trust/credentials module: manufacturing, testing standards, warranty, service posture
- Brand comparison chart structure — the columns and criteria stay constant across a family even when the rows change
- The visual system itself: typography, color, iconography, image treatment, module rhythm
Variable layer — true about this product, rebuilt per SKU:
- The objection-killer module. Whatever this specific product's buyers hesitate about — fit, compatibility, capacity, skill level, coverage.
- The comparison-within-family module, which tells a shopper why this SKU rather than your other three. On a real catalog this is the single highest-value module and it's the one templating destroys, because a template cannot know which siblings it sits next to.
- Specifications and dimensional detail.
- Use-case and application content.
- The FAQ module, which should carry this SKU's actual edge cases, not marketing copy.
Two consequences fall straight out of that split.
First, your production cost per SKU drops by most of what you're spending now, because the fixed layer is built once and reused. You're not producing an A+ project per ASIN; you're producing two to four variable modules per ASIN inside a chassis that already exists.
Second, and this is the part people get wrong: the fixed layer should be the smaller half. If your template is five brand modules and one product module, you've built a brochure with a product attached. The ratio I want on a mid-catalog SKU is roughly two fixed to three variable, and the variable ones go first.
Which raises sequencing. A+ is front-loaded whether you like it or not — mobile scroll depth on A+ averages around 62%, meaning roughly a third of the people who reach your A+ never see modules five through seven. So the module order is: product-specific first, brand-level last. Brand Story at the top of a mid-catalog listing is a brand talking about itself to a shopper who hasn't decided whether this product fits their cabinet yet. It reads well in a deck and converts nothing. Put the thing that resolves the purchase decision in modules one through three, and let the brand material occupy the space a committed reader will reach.
The Premium A+ gate that makes your long tail matter
Here's the argument that reorders most brands' priorities, and almost nobody makes it.
The widely reported eligibility path for Premium A+ has two components: a published Brand Story across your Brand Registry ASINs, and a track record of approved A+ projects published in the trailing twelve months (five is the number that circulates). Amazon does not publish a single definitive public checklist covering every account's situation, so treat those specifics as the working version and confirm your own status inside A+ Content Manager rather than off a blog post — mine included.
But the shape of the requirement is the point, and the shape is not in dispute: access to the best A+ surface Amazon offers is gated on catalog-wide coverage, not on how good your hero SKU is.
That flips the standard prioritization. The usual logic says the long tail doesn't earn A+ production cost — 30 slow SKUs generating four percent of contribution, why would I spend on them. Fair, if A+ were only about those 30 listings. It isn't. Those 30 uncovered ASINs are the thing standing between your top-revenue SKUs and the module set that actually moves conversion at the top of your catalog.
So the long tail's job changes. It doesn't need bespoke A+. It needs coverage — the fixed layer plus one honest product module, produced in a batch, good enough to be true and cheap enough to finish. You're not merchandising those SKUs. You're clearing a gate.
And Brand Story specifically is the cheapest work in this entire post: it's a brand-level asset that applies across eligible ASINs once it's built, it holds up to seven modules from a small set of types, and it runs on a review cycle in the same range as standard A+. Build it once, cover the catalog, stop thinking about it.
Why identical A+ across 60 ASINs is worse in 2026 than it was in 2023
This is the part that has genuinely changed, and it's the strongest technical argument against the copy-paste template.
Start with what's true and hasn't moved: A+ Content is not indexed by A9. Keyword-stuffing your modules does nothing for Amazon search rank. That's been true for years and it's why I keep telling people to stop writing A+ copy like backend search terms.
But two other readers exist now.
Google indexes your detail page, including A+ text and alt text. Sixty ASINs carrying byte-identical body copy is a duplicate-content pattern on the open web, and you're competing for the long-tail queries that bring external traffic to product pages with sixty pages that say one thing.
Rufus reads A+ as context. This is the bigger one. The AI layer is deciding whether your product belongs in a candidate set for a specific, situational, often compatibility-shaped question. It reads title, bullets, description, attributes, A+ and reviews to work out what this product is and who it's for. If sixty of your ASINs carry identical A+ copy, you have told the model — in the most explicit way available — that your sixty products are the same product.
Think about what that costs. You have a line where SKU 14 is the one that fits face-frame cabinets and SKU 19 is the one rated for outdoor use, and the only surface where you explained that in natural language is running the same paragraph on both. The differentiation exists in your head, in your ad structure, maybe in a bullet. It does not exist anywhere the model can use it to pick between your own products, so it picks somebody else's.
The template is fine. The template's copy layer is not supposed to be templated. Lock the chassis, rebuild the words.
One cheap lever while you're in there: A+ image alt text. Most brands leave it empty or paste the product title into every field. It's per-module, it costs seconds, it's the accessible description of an image whose meaning is otherwise invisible to any non-human reader, and it's the single easiest place to make two visually similar modules semantically distinct across a family of SKUs. If you do nothing else at scale, populate alt text honestly per module.
Tier the catalog by contribution, not revenue
You cannot give every ASIN the same treatment, and revenue is the wrong sort key because it ignores what the SKU costs you to run. Sort by contribution and cut into three tiers.
Tier 1 — heroes (typically 10-20% of SKUs, 70-80% of contribution). Bespoke A+ or Premium A+. Full variable layer, custom comparison chart against your own line, mobile-QA'd individually, refreshed on a real cadence. These are the pages where a module change is worth measuring, so these are the ones you A/B test through Manage Your Experiments.
Tier 2 — the working middle. Fixed chassis plus three genuinely product-specific modules written from that SKU's reviews and return reasons. Produced in batches of eight to twelve. This tier is where catalog-scale A+ either exists or doesn't, and it's the tier that gets skipped in almost every brand I audit.
Tier 3 — the tail. Fixed chassis plus one honest product module. Brand Story applied. Done in a single production block, submitted in batches, never revisited unless the product changes.
The decision rule for what tier a SKU sits in is not "how much do we like this product." It's: does a wrong expectation on this page cost us a return? Any SKU with a compatibility dimension, a sizing dimension, or a coverage/quantity dimension gets promoted a tier regardless of revenue, because those are the pages where A+ is doing return-prevention work and a return costs the contribution plus fees both directions plus, frequently, the unit.
The shared-template risk nobody prices
Here's the cost of the fixed layer, and I've watched it land on brands who thought they'd done everything right.
A shared module concentrates compliance risk. One phrase in your trust module — a warranty claim, a "guaranteed," a superlative you can't substantiate, a health claim in a category where health claims are policed hard — is a single-listing problem when it lives on one project. When that module is applied across 80 ASINs, it's a catalog event. And A+ approval is not permanent: content that passed review can be pulled in a later sweep, which means the exposure isn't only at submission time.
Three disciplines fall out of that.
Version your templates, and know which ASINs carry which version. The most common way brands discover they can't do this is when they need to change one line across the catalog and have no list of where that line currently lives. A spreadsheet mapping ASIN → template version → date published is not sophisticated. It's the difference between a two-hour fix and a two-week archaeology project.
Keep editable source files outside Seller Central. If a module is pulled, you need to fix and resubmit, not rebuild from a flattened PNG. Every brand that has been through a retroactive sweep learns this once.
Run the compliance pass on the template before it multiplies, not on the listings after. One careful read of the fixed layer against the rejection triggers — warranty and guarantee language, pricing and promo references, shipping claims, unsupported superlatives, competitor references, contact information — is worth more than eighty individual reviews, because eighty listings inheriting one clean module is exactly as efficient as eighty listings inheriting one dirty one.
The production system
The workflow that actually ships, in the order it runs.
1. Build the module library, with locked and unlocked zones. In your design files, explicitly mark which areas are brand-locked (never edited) and which are per-SKU (always edited). This one convention prevents most of the drift that turns a catalog into six visual generations of the same brand.
2. Build the driver spreadsheet. One row per ASIN. Columns for tier, template version, and the actual variable copy — the objection this SKU has to answer, the comparison rows, the spec values, the FAQ entries, the alt text. Copy gets written in the spreadsheet, not in the design file, because copy written inside a layout gets written to fit the box rather than to answer the question.
3. Write the variable copy from evidence, not from the brand deck. For each SKU: read the last fifty reviews and the return reason comments, and pull the recurring complaints. That's your module list. The brands that do this and the brands that don't are visible from across the room.
4. Produce in batches by tier, not by whichever SKU someone asked about on Tuesday.
5. Assign ASINs deliberately. A+ Content Manager lets you apply one project to a single ASIN, to many, or across a set via bulk upload of ASINs. That's the mechanism that makes the whole architecture practical — and it's also the mechanism that makes an error catalog-wide. Check the assignment list before you submit, every time.
6. Submit in clean batches against the review clock. Standard A+ review commonly runs about seven business days, sometimes faster off-peak. Two rules: don't dump 200 projects into review at once, and don't submit a batch whose approval you need before a dated event without a buffer. If a batch comes back rejected without a clear reason, isolate it — resubmit a small subset to find what's tripping the automated layer rather than resubmitting the whole batch and waiting another cycle.
7. QA on a phone. Not a phone preview on your monitor. A phone. Modules that read fine at desktop width lose their type hierarchy and their reading order at mobile width, and that's the width most of your traffic uses.
A+ has no alarm
This is the reason A+ decays quietly across a large catalog, and it's structural, not a discipline failure.
Every other line in your operation has a signal when it breaks. Inventory has a stockout that makes a phone ring. Advertising has a daily number that moves. Account health has a suppression email with a deadline. A+ Content has none of that. Nothing errors. Nothing turns red. A module can describe a formulation you stopped making in March and the page will render it perfectly for two years.
So it needs a scheduled trigger instead of an alarm. Two mechanisms.
A once-a-year read-through of the fixed layer. Twenty minutes. Is every claim in the shared modules still true, still substantiated, still compliant with the current version of the policy?
A change-triggered review list. Formulation change, pack-size or count change, packaging redesign, price-tier move, a new sibling SKU entering the family, or a policy change that touches your category. Any of those fires a review of the affected ASINs' variable layer. That list belongs in the same place your reorder triggers live, because it's the same kind of operational task — and treating it as a marketing project is why it never happens.
FAQ
Can I apply one A+ project to multiple ASINs? Yes — Content Manager supports assigning a single project to one ASIN, several, or a larger set via bulk ASIN upload. That's the backbone of the fixed layer. The caution is that shared assignment means shared risk: a claim problem, a stale spec or a wrong image propagates everywhere the project is applied, so the assignment list deserves the same scrutiny as the content.
How many ASINs can I publish A+ to at once? You'll find conflicting monthly and per-batch limits quoted around the web, and I'm not going to repeat a number I can't source to Amazon. Check the limits your own account shows in A+ Content Manager and plan batches against that, not against a figure from an article. What's consistent regardless of the cap is the review cycle: build your rollout calendar backward from approval time, not from production time.
Should long-tail SKUs get A+ at all? Yes, but not the expensive version. Fixed chassis plus one product module plus Brand Story. Even setting aside the Premium A+ coverage requirement, an uncovered ASIN is a page with no answer to the shopper's question and no context for the AI layer — and the cheap version of A+ closes both gaps for a fraction of the cost of ignoring it.
Does duplicate A+ content hurt my Amazon SEO? Not through A9 — A+ isn't indexed there, so there's no ranking penalty in the sense people usually mean. The cost is elsewhere and it's real: duplicate text weakens your pages for external search, and identical A+ across a family removes the clearest natural-language signal distinguishing your own products from each other for Rufus and the AI shopping layer. It doesn't demote you. It makes you illegible.
How often should A+ be refreshed? Tier 1 on a real cadence with measurement — and remember A+ changes read on CVR over 30-60 days, not on a two-week CTR read, so don't judge them early or change two things at once. Tiers 2 and 3 on triggers, not on a calendar. Refreshing a tail SKU's A+ because it's been a year is work with no thesis behind it.
If your catalog has more coverage gaps than quality problems, the fix isn't a better A+ design — it's an architecture that lets you finish. Related reading: A+ content module sequencing, the image stack vs A+ division of labor, and what gets A+ content rejected.