Put a short intro above the product grid and everything long below it. That's the whole answer to Shopify collection page SEO as far as placement goes: 40 to 70 words above the grid, 250 to 400 words under it, an FAQ block under that, and a block of links to related collections at the very bottom. Anything above that budget starts pushing the first row of products off the mobile screen, and a collection page that doesn't show products in the first viewport converts worse than one that ranks two positions lower.
The rest of this post is about how to fit that in without adding weight, which collections deserve the effort at all, and the technical decisions you need to make before anyone writes a word.
The pixel budget above the grid, worked out
Take an iPhone 14 at 390 CSS pixels wide. After Safari's chrome you have roughly 740px of usable height on first paint. Now stack a typical Indian D2C collection page:
- Announcement bar: 36px
- Sticky header with logo and search: 56px
- Breadcrumb: 22px
- H1: 40px
- Intro copy, three lines at 24px line-height: 72px
- Filter and sort bar: 52px
That's 278px consumed before the grid begins. A product card with a 4:5 image on a two-column mobile grid is around 300px tall including title and price, so the first row lands fully inside the viewport with room to spare. Fine.
Now add a 240px collection banner image and stretch the intro to 120 words, which is about eight lines on mobile, or 192px. You're at 638px before the grid. The first product card's top edge appears at 638 and the viewport ends at 740. The customer sees a sliver of a saree and nothing else. We've audited stores where that exact layout was live for a year while the merchant wondered why collection pages had a 68% bounce on mobile.
So the working rule: 300px of chrome and copy above the grid on mobile, 380px if you insist on a banner, and the banner had better be doing something other than repeating the H1 in a script font.
Three lines above, everything else below
The intro above the grid has one job: confirm to a person who just clicked a search result that they're in the right place, and give the page a natural spot for the primary phrase. Three lines. Something like what the range covers, the price band, and one differentiator that isn't marketing noise.
Everything you actually want indexed for long-tail queries goes below the grid, in this order:
- The main body block — 250 to 400 words with two h2 or h3 subheadings inside it. This is where buying-guide language lives: fabric weights, sizing, care, what to pick for which occasion, what the GST-inclusive price includes.
- An FAQ block — four to six questions taken from your support inbox and your WhatsApp chats, not from a keyword tool.
- A related-collections block — 6 to 12 text links to sibling and child collections.
Google has read below-the-fold content for years, and content inside a collapsed accordion is indexed too as long as it's in the HTML rather than fetched on click. The thing you must not do is inject it with JavaScript after load through some app that appends a div to the DOM. That content arrives late, shifts the layout, and is the reason a page with a 0.02 CLS in the lab records 0.19 in the field.
Use metafields, not the collection description
The collection description field is the wrong home for 400 words of copy. It gets pulled into collection lists, sidebar snippets, sitemap-adjacent templates and whatever else your theme decided to do with it, and one merchant pasting styled HTML from Word into it will break the layout on a page nobody checks.
What we set up instead: three metafields on the collection resource.
custom.seo_intro— single line text, character limit enforced in the definition so nobody writes an essaycustom.seo_body— rich textcustom.faq— a metaobject list, one entry per question
Then a theme section renders each one, with an {% if %} guard so collections without copy render nothing rather than an empty 80px block. Merchandisers fill these in from the admin without touching Liquid. The section is added once to the collection template and it appears everywhere.
One awkward case worth naming: if you use alternate collection templates for different category types, you have to add the section to each template separately, and it's easy to ship a new template that quietly drops the copy block. We've done it. Check the rendered HTML on one collection per template after every theme deploy.
Decide what happens to filter URLs before you write anything
Copy is the last decision, not the first. Before that, settle how your filtered and paginated URLs behave, because that's where collection SEO usually goes wrong.
Look at the rendered <head> on a filtered collection URL on your own store, right now, in view-source. Not in the theme editor. Check what the canonical tag says when you apply a filter, when you change the sort order, and on page 3 of a paginated grid. Themes differ, apps override each other, and the only reliable answer is the HTML your server actually sends. If a sort parameter produces a self-referencing canonical, you have created several near-duplicate versions of every collection you own.
Then decide which facet combinations deserve to be real, indexable pages with their own copy. "Cotton kurtas" probably does. "Cotton kurtas, size XL, blue, sorted by price descending" does not. The clean pattern is a small set of hand-built collections for the combinations with real search demand, each with its own H1 and its own body copy, and everything else left as parameter-driven filtering that points its canonical back to the parent.
Which brings up the part nobody wants to hear: on a large catalogue, filtering quality affects collection performance more than the copy does. If a customer lands on a 900-product collection from search and can't narrow it in two taps, the copy block underneath is irrelevant. That's the problem FilterPro exists to solve — smart filters and AI search on the storefront, so the landing page can be broad without being useless.
Internal links do more than the paragraphs do
The related-collections block at the bottom is the highest-leverage part of the whole exercise, and it takes the least writing. Twelve keyword-relevant text links from a collection with existing authority to twelve collections without any is worth more than a thousand words on the parent page.
Build it manually for your top categories. Auto-generated "you may also like" widgets tend to link the same six collections from every page, which flattens the whole structure. What you want is genuine parent-to-child and sibling-to-sibling links: from "Silk Sarees" out to Kanjivaram, Banarasi, Tussar, and to "Sarees Under ₹5,000", each with anchor text that reads like something a person would search.
Do the same from your blog. If you publish category content, the links out of it should land on collection pages, not on other blog posts.
Only about fifteen collections deserve this treatment
Most stores have somewhere between 40 and 300 collections once you count tag-generated ones. Writing 400 words for all of them is a waste of a quarter's budget.
Open Search Console, filter Pages by /collections/, set the date range to the last three months, and sort by impressions. Then look for pages sitting at average position 8 to 20 with real impression volume. Those are the ones where copy, internal links and a better filtered experience can actually move something.
Here's the arithmetic on a typical one. A collection with 4,000 impressions a month at average position 14 might be getting a 0.8% CTR, so 32 clicks. Assume the work moves it to position 6 and CTR to 3% — those CTR figures are assumptions you should replace with your own from GSC, not gospel. Same impressions, 120 clicks. An extra 88 sessions a month from one page. At a 1.6% conversion rate and ₹2,200 AOV, that's about ₹3,100 a month, or ₹37,000 a year, from one collection. Multiply across twelve pages and the project pays for itself. Do it for 200 collections at 40 impressions each and it never will.
The bloat isn't the words
Four hundred words of HTML is roughly 2.5KB before compression, under 1KB gzipped. It has no measurable effect on LCP. When merchants tell us they're worried adding collection copy will slow the page down, the real weight is somewhere else entirely:
- The collection banner served at 2400px wide to a 390px viewport
- A review widget loading its own JS bundle to render star ratings on 24 product cards
- Three apps that each ship jQuery
- An FAQ accordion from an app when 20 lines of Liquid and a
<details>element would do it with zero JavaScript
If a collection page is at 3.4s LCP on mobile, the copy block is not why. Sort the images and the app scripts first — that's the bulk of what we do in speed work, and it's usually a bigger ranking and revenue lever than the on-page text.
Structured data: modest expectations
Add BreadcrumbList. It's cheap, it's stable, and it changes how the URL renders in results. ItemList for the products in the grid is reasonable and harmless.
FAQ schema is a different story. Google cut back FAQ rich results for most sites some time ago, so write the FAQ block for the person reading it and treat any rich result as a bonus that probably won't arrive. If you were only adding FAQs for the stars in the SERP, skip them and spend the time on the body copy instead.
How we sequence it
On a typical engagement the order is: audit the canonical and facet behaviour, build the metafield definitions and the theme section, pick the twelve to twenty collections from Search Console data, write the copy in batches of five, ship, then measure at 60 and 90 days. The build is a couple of days of front-end work. The writing takes longer, because good category copy needs someone who knows the difference between mulmul and mulberry silk.
If you want a read on which of your collection pages are close enough to page one to be worth the effort, our free audit covers exactly that, including the canonical mess most stores don't know they have.