Substack to WordPress: importing the export ZIP and keeping /p/ links alive

What the export ZIP contains

Substack's export is a single ZIP with three useful parts. posts.csv lists every post with its ID, title, date, type and whether it was paywalled. The posts folder holds one HTML file per published post, named after the post ID and slug, plus small per-post CSVs of email opens. The subscriber CSV lists every email address on your list with its plan.

Missing from the ZIP: Notes, drafts and comment threads. The Substack Importer plugin can pull comments from publicly accessible posts on the live site during import, which is one reason to run the import before you shut anything down.

Running the Substack Importer

Install the Substack Importer from WordPress.org along with the WordPress Importer it depends on, then upload the ZIP. Recent versions let you force every post to draft, set featured images, apply a category to all imported posts and choose which date to use. Importing as drafts is the safer choice: you can review formatting and paywall notes before anything goes live.

Known rough edges, worth planning around:

• Large archives can time out. Split the run or raise your host's PHP time limit.
• Images may stay remote. Check imported posts for image URLs on Substack's CDN and upload any that did not copy.
• Paid posts arrive as ordinary posts. Decide whether each one should be public on WordPress, restricted by a membership plugin, or left out.
• Podcast episodes come across with their audio, but your podcast feed URL changes, so update it in Apple Podcasts and Spotify separately.

Do not assume any SEO title or description you set in a post's settings came through with the import. Each post's subtitle usually makes a decent starting meta description; paste it into the SEO Settings sheet for your most visited posts.

Keeping /p/ URLs and moving the domain

Set Settings → Permalinks to the custom structure /p/%postname%/. Imported posts keep their Substack slugs, so example.com/p/why-we-left-the-city still resolves, with WordPress adding the trailing slash itself. Other Substack paths need a few redirects: /archive to your blog page, /about to your about page, and section pages under /s/ to the matching categories. Hydrogen SEO's Redirection Manager handles these as individual 301s, and the redirect rule generator is quicker if you are moving to nginx or Apache rules anyway.

The sequence on a custom domain: import and review on a staging address, add the redirects, disable the custom domain in Substack's publication settings so it stops claiming the domain, then change the DNS records to your WordPress host. Your publication falls back to its substack.com subdomain, which is fine; the traffic that matters arrives on your domain.

On a substack.com subdomain there is no equivalent. Substack does not offer a redirect to an outside domain, so links to name.substack.com/p/... keep landing on Substack.

Subscribers, rankings and the checklist

Import the subscriber CSV into whatever sends your newsletter from WordPress, and send a short note explaining the move so the change of sender does not look like spam. Paid subscriptions are billed through the Stripe account you connected to Substack; confirm your WordPress membership plugin can work with those existing customers before you cancel anything on Substack.

On a custom domain with /p/ URLs preserved, rankings usually hold, since Google sees the same URLs with the same articles. Leaving a substack.com subdomain is different: the new domain has none of the old URLs' history, and if the Substack copies stay public, Google may keep ranking them over yours. Expect to rebuild.

• Spot-check a dozen /p/ URLs for a 200 on WordPress.
• Confirm images and audio load from your own server.
• Submit the new sitemap and run the site audit for broken links inside imported posts, many of which point at the old subdomain.