Moving WordPress blog posts without losing rankings comes down to preserving three things per post: its URL, its content, and its metadata. Keep the permalink or 301 it, carry the body and images across intact, and move the title tag and publish date unchanged. WPBuildAI migrates posts this way by default, mapping every permalink and re-linking every in-post image, which is why a blog can move hundreds of articles and hold its search positions. Posts are higher risk than pages because there are simply more of them, and each one is an indexed URL with its own backlinks.
The rule for a blog: treat every post as a ranked page, because to Google, it is one.
What has to move with each post
A blog post is more than its text. To keep its rankings, you carry across the permalink, the full body content, the in-post images, the title tag and meta description, the publish and updated dates, and the category and tag structure that links posts together. Drop any of these and you either break the URL, weaken the page, or sever the internal links that spread authority around your blog.
Comments and author bylines matter for trust and completeness, so move them too where they exist.
Which post elements carry the most ranking weight
Not every element affects rankings equally. This is where to concentrate care.
| Post element | Ranking impact | Migration risk | Verdict |
|---|---|---|---|
| Permalink (URL) | Very high, holds all backlinks | High if the structure changes | Preserve or 301, never drop |
| Title tag and meta | High, what Google ranks on | Medium, easy to alter by accident | Carry over verbatim |
| In-post images | Medium, layout and image search | High, many hard-coded paths | Re-link and verify each |
| Categories and tags | Medium, internal link equity | Medium, often restructured | Keep the taxonomy intact |
| Publish date | Low to medium, freshness | Low, easy to reset by mistake | Preserve the original date |
The pattern: the permalink and the title carry the most weight, so they get the most care. WPBuildAI maps every permalink and preserves titles and dates as a default, not an upgrade.
How to preserve permalinks across the move
The cleanest outcome is keeping the exact same permalink structure, so every indexed URL and backlink still resolves with no redirect needed. When the structure has to change, map each old post URL to its new one with a 301 redirect, which passes the post’s ranking signals to the new address. Google’s site move guidance treats this as the core of a safe move.
For example, a blog on /2019/03/post-title/ dated URLs can either keep that pattern or 301 each one to a clean /post-title/ URL; what it cannot do is change the pattern and leave the old URLs to 404. For the full move sequence this fits into, see how to migrate a WordPress site to Lovable.
Do not lose the metadata that makes posts rank
Carry the title tag and meta description across exactly, and preserve the original publish date so Google does not read every post as brand new. Keep any article structured data so rich results survive the move. Changing titles or dates during a migration adds variables that make a ranking dip impossible to diagnose; migrate identical, then optimize later. The wider signal list is in the WordPress migration SEO checklist.
Why is the blog archive the riskiest part of a migration?
Because it is the largest part of the site and the part nothing currently links to, so every process that starts from the navigation misses it entirely.
A site with twelve pages in its menu and six years of posting has hundreds of addresses that no menu points at. They are reached from search results, from other people’s articles, and from internal links inside other posts, which means a rebuild driven by the site map reproduces the visible site and drops the archive.
The archive is also where the long tail lives. Individual posts each earn a small amount of traffic for queries nobody tracks, and the total is frequently larger than the service pages everyone worries about. Losing it looks like a modest unexplained decline rather than an obvious failure.
And it carries most of the external links. Other sites link to useful articles far more often than they link to a service page, so the archive holds the equity that cannot be rebuilt.
Which archive URLs get forgotten?
The generated ones, because nobody wrote them and so nobody remembers they exist.
| URL type | Why it matters | What happens if it is dropped |
|---|---|---|
| Paginated listings, page 2 onward | Crawl paths to older posts | Deep archive recrawls far more slowly |
| Category and tag pages | Some rank for real queries | Positions lost with no obvious cause |
| Author archives | Occasionally linked externally | Small, avoidable 404 cluster |
| Date archives | Often indexed, rarely useful | Noise in the not found report |
| Post attachment pages | WordPress creates one per upload | Large 404 group, appears in week four |
| Feed URLs | Some have real subscribers | Silent loss of a distribution channel |
Decide each of these as a category rather than row by row. Paginated listings and taxonomy pages usually deserve preserving or mapping. Date archives and attachment pages are frequently better returned as gone, provided that is a decision somebody made rather than an omission.
How do you check the posts arrived complete?
By comparing each new post against the captured original mechanically, because the eye is a poor judge of whether something is missing.
Word count first. A post that arrives materially shorter than the one that was ranking will rank lower, and this is the single most common cause of a partial recovery that nobody can explain.
Heading structure second. Sections dropped during a redesign take their subheadings with them, and those subheadings are frequently what the post ranked for.
Images with alt text third, since a post that loses its diagrams loses the reason people linked to it.
Then the metadata: title, description, canonical, and publish date. The publish date matters more than people expect, because a migration that resets every post to today’s date tells search engines the entire archive was written this week, which is both false and unhelpful.
Run the comparison as a list rather than a browse. Twenty posts checked properly is more useful than two hundred glanced at.
When should a post not come across?
When it was never earning anything and it is not worth the redirect. An archive built over years accumulates posts that got no traffic, no links, and no impressions, and carrying all of them forward preserves clutter rather than equity.
The test is per post and it takes one export: did this address earn traffic, impressions, or external links in the last two years. If none of the three, it is a candidate for retirement, and returning gone is more honest than redirecting it somewhere unrelated.
It is also right to leave behind posts that are actively wrong. Advice that no longer applies, product coverage for things you stopped selling, and announcements about events long past are all better retired than republished, because a rebuilt site full of stale content is a worse site than the one it replaced.
The caution is to prune deliberately and in one pass, with the numbers in front of you, rather than dropping posts because nobody got around to moving them. Those two produce the same result and only one of them is a decision.
What happens to internal links between posts?
They are the thing most often lost in a rebuild, because a new site is built from a design rather than from the old link graph.
Six years of posting produces a web of cross references: posts linking to earlier posts, roundups pointing at individual articles, and updates linking back to the piece they revise. That web tells search engines which pages the site itself treats as important, and it is how crawlers reach the deep archive at all.
A rebuild that carries the post bodies across carries most of those links automatically, provided the URLs are preserved. A rebuild that changes URLs turns every one of them into a hop through a redirect, which still works and wastes crawl budget on every request.
So after the move, update in-post links to point at final addresses rather than through redirects. It is tedious, it is entirely within your control, and it measurably improves how quickly the archive gets recrawled.
Watch for the reverse problem too: posts that end up with no inbound internal links at all. A post nothing points at is discovered slowly and treated as peripheral, however good it is.
How long does the archive take to recover?
Longer than the rest of the site, and that is normal rather than a sign of failure.
Popular posts recrawl within days and are usually back within two weeks. Mid-archive posts with a few internal links take three to six weeks. Old posts with one link pointing at them can take eight weeks or more, because Google visits them rarely and the schedule is not something you can accelerate meaningfully.
The practical consequence is that total impressions can look flat in week three while money pages have recovered and the archive has not, which reads as a stall and is actually two opposite movements cancelling out.
Split the recovery by page type when you look at it. If the money pages are back and the archive is climbing, the migration worked. If the archive is not moving at all by week six, check the not found report against the post list, because that is where an unmapped category hides.
Key takeaways: moving blog posts without losing rankings
Treat every post as the ranked page it is. Preserve or 301 each permalink, carry the body, images, titles, dates, and taxonomy across unchanged, and keep article structured data so rich results survive. The permalink and title carry the most weight, so protect those first. WPBuildAI moves posts with permalink mapping and metadata preservation built in, which is how a large blog migrates without a traffic drop.
Questions people ask before moving
How do I move WordPress blog posts without losing rankings?
Preserve each post’s permalink or map it to a 301, carry the body, images, title tag, meta description, and publish date across unchanged, and keep the category and tag structure intact. WPBuildAI migrates posts this way by default, mapping every permalink and re-linking every image, so a blog can move hundreds of articles and hold its rankings. The permalink is the single most important element, because it holds the post’s backlinks.
Will changing my permalink structure hurt SEO?
Only if you change it without redirecting. If you alter the URL pattern, every old post URL must 301 to its new address so its backlinks and ranking signals transfer. Keeping the existing structure is the lowest-risk option because no redirects are needed. The damage happens when the pattern changes and the old URLs are left to return 404s.
Should I keep the original publish dates?
Yes. Preserve each post’s original publish date so Google does not treat long-established content as brand new, which can briefly unsettle rankings. Update the modified date only when you genuinely revise a post. Resetting all dates to the migration day is a common accidental mistake that misrepresents your archive’s history.
What about comments on my posts?
Move them if they add value, which they usually do for engagement and completeness, but they are not a ranking-critical element like the permalink or title. If your comment system cannot transfer directly, preserving the post content and URLs matters far more. Prioritize the URL, content, and metadata first, then bring comments across where the platform allows.
Why is the blog archive the riskiest part of a migration?
Because it is the largest part of the site and nothing in the navigation points at it, so any rebuild driven by the menu reproduces the visible site and drops the archive. It also holds the long tail of traffic for queries nobody tracks, and most of the external links, since other sites link to useful articles far more often than to a service page.
How do I check my posts arrived complete?
Compare each new post against the captured original mechanically rather than by eye. Check word count first, since posts arriving materially shorter than the ones that ranked are the most common cause of an unexplained partial recovery. Then heading structure, images with alt text, and the metadata including the original publish date, which a migration can silently reset to today.
How long does a blog archive take to recover after a move?
Longer than the rest of the site, and normally so. Popular posts are usually back within two weeks, mid-archive posts take three to six, and old posts with a single internal link can take eight weeks or more because Google visits them rarely. Total impressions can look flat in week three while money pages recover and the archive has not yet started.
