Shopify’s Collection Sources API replaces the smart-versus-custom collection split with a single, flexible, source-based model. For a store with a few dozen collections this is a welcome simplification. For a store with hundreds of collections built up over years — some smart, some custom, some hand-edited exceptions layered on top of automated rules — this is a structural migration with real SEO exposure if collection URLs, canonical relationships, or indexed product sets shift underneath existing rankings.
What’s Changing
The old model forced a binary choice per collection: smart collections used automated conditions to include products, custom collections were manually curated lists, and moving a collection from one type to the other meant rebuilding it. The Collection Sources API treats a collection as pulling from one or more defined “sources” — which can mix rule-based conditions and manually pinned products in the same collection — and exposes this through the GraphQL Admin API instead of forcing the smart/custom split at the data model level.
The SEO risk isn’t the new model itself — it’s more capable than the old one. The risk is in the migration path: automated tooling and third-party apps that assumed the smart/custom distinction may not map cleanly onto the new source model, and a naive migration can silently change which products a collection includes, which changes what that collection page is actually about from a topical and indexing standpoint.
Pre-Migration Inventory
| What to Capture | Why It Matters After Migration |
|---|---|
| Current collection URL and handle | Confirms whether the URL survives migration unchanged — a changed handle is a redirect problem, not just a data problem |
| Collection type (smart or custom) and its exact rule set | The baseline you’re checking the new source configuration against |
| Current product count and product ID list | The single most reliable check that migration preserved intent — a collection that gains or loses products unexpectedly changed meaning |
| Ranking and indexing status (Search Console) | Baseline to compare against post-migration, so a ranking drop can be tied to a specific migration date rather than guessed at later |
| Meta title, meta description, and any custom collection description | Confirms this content isn’t lost or reset to a default during the API migration |
Migration Sequence
- Export the full inventory above for every collection before running any migration tooling — this is the only way to verify parity afterward instead of assuming it.
- Migrate a small batch first — five to ten collections that are not your highest-traffic pages — and diff the product list, URL, and metadata against the pre-migration export.
- Check canonical behavior specifically. If the new source model changes how paginated or filtered views of a collection resolve, confirm canonical tags still point where they should rather than assuming the theme’s existing canonical logic still applies unchanged.
- Re-submit affected collection URLs through Search Console’s URL Inspection after migration if the product set changed meaningfully, since a materially different page is worth a fresh crawl signal instead of waiting for the next scheduled one.
- Hold a rollback window. Keep the pre-migration configuration exported and available to manually rebuild a collection if a migrated one shows an unexpected ranking or indexing change within the first two to three weeks.
- Migrate the remaining collections in batches, prioritizing lower-traffic ones before your highest-value category pages, so any tooling bug surfaces on a page where it costs less.
A Case Worth Watching Closely
Collections with manually pinned exceptions layered on top of an otherwise rule-based smart collection are the highest-risk case, since the old model handled this awkwardly (often through app workarounds) and the new source model may resolve the same intent differently by default. Don’t assume the migration tool inferred your manual exceptions correctly — check the actual product list against your pre-migration export for exactly these collections first.
