Start with a crawl, not with the import. Before anyone touches Shopify, run the live site through Screaming Frog and export every URL that returns a 200 — posts, category archives, tag archives, author archives, date archives, paginated archives, feeds, attachment pages. On a WordPress blog with 400 posts, that export is rarely 400 rows. It is usually closer to 900. The posts themselves migrate cleanly with any decent importer. The 404s come from everything around them, and that is the part of a Shopify blog migration most people discover three weeks after launch when Search Console starts filling up.
Here is the arithmetic that catches teams out. 400 posts at 12 per page is 34 paginated archive URLs. A blog that has been running for six years with eight categories, forty tags, six authors and monthly date archives adds another 130 or so. Plus a feed for the blog and one for each category. None of those paths exist on Shopify. Not one.
What Shopify does not have, stated plainly
Shopify's blog is deliberately thin. Articles live at /blogs/{blog-handle}/{article-handle}. That is the whole URL model.
- No categories. Tags are the only taxonomy. Tag views live at /blogs/news/tagged/{tag}.
- No author archives. The author field on an article is a string. There is no URL that lists a person's posts.
- No date archives. Nothing at /2022/, nothing at /2022/07/.
- No nesting. A tag cannot have a parent.
- No attachment pages, and no per-category RSS. You get /blogs/news.atom.
You can create multiple blogs, and people reach for that as a category substitute. Resist it for a while. The blog handle sits inside the article URL, so an article can belong to exactly one blog, and moving it later changes its URL and costs you another redirect. Multiple blogs earn their keep when you genuinely have separate publications — press releases and recipes, say, with different templates and different audiences. They are a bad tool for topic taxonomy.
Taxonomy loss is a content decision, not a technical one
Eight WordPress categories become eight tags. Fine. The problem is that your category pages probably ranked. They had an intro paragraph, a hand-picked featured post, a custom title tag and a meta description. Shopify's tag view has none of that. It renders a list of articles with the tag name in an H1 if the theme bothers, and the title tag defaults to something forgettable.
So decide, per category, whether the archive was earning traffic. Pull twelve months of organic landing pages from GA4 and filter to the category paths. In our experience two or three of the eight will have real sessions and the rest will have almost none.
For the ones that matter, build a proper page. Either a Shopify page with a custom template and a curated list, or a metaobject-driven hub if you want the editors to manage it without a developer. Then redirect the old category URL to that hub. For the ones that do not matter, redirect them to the tag view and move on. It costs nothing and it stops the 404.
One more thing about tag views: they multiply. Shopify lets visitors combine tags in the URL, and crawlers will find those combinations through your filter links. Add a noindex to any view where current_tags is set, unless you have deliberately made that view worth indexing. In the blog template, gate the robots meta on that condition and you are done in one line.
Author pages: rebuild them or retire them, but pick one
The author field on a Shopify article is free text when you set it through the API or a CSV import, even though the admin UI nudges you toward staff accounts. That means bylines survive a migration. Author pages do not.
If your content is advice — skincare, supplements, finance, anything where a reader reasonably asks who wrote this — rebuild them. An author metaobject with name, photo, credentials, bio and a link field, a page template that filters articles by author, and the byline in the article template linking to it. Half a day of work, and it maps your old /author/{slug}/ URLs one-to-one so the redirects are trivial.
If your blog is written by two marketers and a freelancer, don't bother. Redirect the author archives to an About page and spend the half day on something with revenue attached. We say this to clients more often than they expect. Rebuilding author archives for a blog nobody reads for the byline is busywork dressed up as SEO.
The redirect map is the migration
Shopify's redirect tool takes a two-column CSV and handles thousands of rows in one import. Rules that matter in practice:
- No wildcards, no regex. One row per URL. This is why the crawl export is the foundation of the whole job — you cannot pattern-match your way out of a missing archive structure.
- Existing resources win. If something already resolves at a path, Shopify serves it and ignores your redirect. So you cannot redirect /blogs/news to somewhere else while that blog exists.
- Shopify serves paths without trailing slashes. WordPress usually adds them. Import the old paths exactly as your crawl found them and let Shopify normalise.
- Keep it to one hop. If you are also changing domain, make sure the domain-level redirect and the path-level redirect resolve in a single 301, not old-domain → old-path → new-path.
Then there is the group nobody plans for: posts you have decided not to migrate. Out of 400, a fair number will be dated announcements, duplicate takes on the same keyword, or 200-word filler from 2018. Kill them, yes. But do not redirect eighty dead posts to the homepage. Google reads a mass of unrelated redirects as soft 404s and you get the worst of both outcomes — no page and no signal. Redirect each one to the closest surviving article on the same topic, and where there is no close match, let it 410. A clean gone is better than a dishonest 301.
Internal link rewrites, which are where the real mess lives
Every one of those 400 posts contains links written as absolute URLs to old permalinks. Assume five per post and you have 2,000 internal links pointing into a URL structure that no longer exists. The redirect table will catch them, so nothing visibly breaks. That is exactly the problem: it looks fine, and you are quietly serving readers a 301 on every internal click for the next four years.
Rewrite them in the import file, before upload, not after. The mapping is mechanical if you built the redirect CSV first — old path to new path, find and replace across the article body column in a spreadsheet or a short script. Two categories need human eyes:
- Links to old category and author archives inside body copy. "See all our ingredient guides" pointing at a category that no longer exists as a real page. These need a judgement call, not a substitution.
- Links to products. If the products are also moving in the same migration, the product handles may change, and product redirects live in the same table. Do the product mapping first so the blog rewrite can reference the final handles.
We get roughly a third of the body-copy anchor decisions wrong on the first pass and fix them in review. Budget for that rather than pretending it is a clean find-and-replace.
Images, embeds and the hosting you forgot you were paying for
Most importers copy the image reference, not the image. Your article bodies keep pointing at /wp-content/uploads/2019/03/whatever.jpg on the old host. Everything renders beautifully in staging. Then someone cancels the WordPress hosting and 400 posts go blank.
Rehost every image to Shopify's CDN and rewrite the src attributes in the same pass as the internal links. While you are in there, drop the width and height attributes back in and add loading="lazy" below the fold — old WordPress exports often lose the dimensions, which hands you a layout-shift problem across the entire blog. If the images are heavy 2400px JPEGs from 2019, resize them now. It is the cheapest speed win in the project and it never happens later.
Comments are the other casualty. Most WordPress-to-Shopify importers do not bring comment threads across, and Shopify's native comments are basic. If a handful of posts have genuinely useful discussion under them, paste the best few into the body as a curated section. Otherwise accept the loss.
Launch day and the thirty days after
Shopify gives you no server logs, so you cannot grep for 404s the way you would on a VPS. Two things to set up before launch:
- A GA4 event on the 404 template that captures the requested path and the referrer. Fifteen minutes of work in the theme, and it is the only real-time 404 feed you will have.
- Search Console verified on the new property with /sitemap.xml submitted on day one. Shopify generates /sitemap_blogs_1.xml automatically; check it lists what you expect before you request indexing.
Then re-crawl your own old URL list against the live site, ideally the morning after cutover. Every row should return a 301 to a 200. Anything returning 404 goes into a second redirect CSV that afternoon. Do this again at day seven and day thirty, because Google will surface old URLs you never knew existed — syndicated feed paths, tracking-parameter variants, a category page linked from a 2020 press mention.
Rankings wobble for two to four weeks on a blog this size even when the redirect map is complete. That is normal. What is not normal is a slow bleed over three months, and when we see that it is almost always thin taxonomy pages, orphaned articles with no internal links pointing at them, or redirect chains from a domain change layered on top of a platform change.
What we would sequence differently on a repeat
Migrate the blog in its own release, separate from the storefront. Two moving parts on the same day means you cannot tell which one caused the traffic dip. If the store is already on Shopify and only the blog is coming across, that is straightforward. If both are moving, put the catalogue live first, let it settle for a fortnight, then bring the content.
And do the content audit before the export, not after the import. Deciding what to keep while you are staring at 400 rows in a CSV is the right time. Deciding it once everything is live in Shopify means every change costs you another redirect row.
If you want a second pair of eyes on the mapping before you commit, send us the crawl export and the current sitemap and we will tell you where the gaps are. Our Shopify migration work usually starts there, and we go into how we handle content structure and search performance on the SEO and content side. A free audit is enough to establish whether your redirect plan has holes in it.