# Do my posts keep their publish dates after a migration? > Not automatically; posts keep their publish dates only if you carry those dates across as part of the migration. A common failure is that the import stamps every post with the date it was imported, so a ten year archive suddenly looks like it was all published this week. That misrepresents your content to readers and can disturb how search engines understand the age and freshness of your pages, since the original publish date and last modified date are signals they read. The fix is to map the original published date, and ideally the last modified date too, from the old site into the matching fields on the new platform, rather than letting the new system default to now. After importing, spot check the dates on a range of old and new posts to confirm they survived. Dates are not a major ranking factor, so this is about accuracy and freshness signals, not a dramatic SEO swing, but a whole archive collapsed onto one date is both misleading and avoidable. WPBuildAI scans your site and returns each post with its content, so you can confirm what published dates the live pages actually show. Source: https://wpbuildai.com/do-posts-keep-publish-dates-after-migration/ By lawrence-arya ยท 2026-06-05 --- Not automatically; posts keep their publish dates only if you carry those dates across as part of the migration. The common failure is easy to picture: the import stamps every post with the date it was imported, so a ten year archive suddenly looks like it was all published this week. That misrepresents your content to readers and can disturb how search engines understand the age and freshness of your pages, since the original publish date and last modified date are signals they read. The fix is to map the original published date, and ideally the last modified date too, from the old site into the matching fields on the new platform, rather than letting the new system default to now. After importing, spot check the dates on a range of old and new posts to confirm they survived. Dates are not a major ranking factor, so this is about accuracy and freshness signals, not a dramatic SEO swing, but a whole archive collapsed onto one date is both misleading and avoidable. WPBuildAI scans your site and returns each post with its content, so you can confirm what published dates the live pages actually show. Dates are worth protecting because freshness now shows up in more than one place: Google [added Search Generative AI performance reports to Search Console on 3 June 2026](https://ppc.land/google-finally-gives-search-console-its-own-generative-ai-visibility-reports/), so you can see whether older posts still surface in AI Overviews once their timestamps change. ## Why dates get reset Understanding the cause makes the fix obvious. Every post has a date field, and when content is imported into a new platform, that field has to be filled. If the migration supplies the original date, the post keeps it; if it does not, the new system fills the field with the current moment, the time of import. So a reset is not a bug so much as a default: the platform puts now into a field nobody told it the true value for. This is why dates are quietly lost in migrations that otherwise succeed, the content arrives perfectly, but the date field was never mapped, so every post inherits the import timestamp instead of its real one. ## What a reset archive looks like The symptom is unmistakable once you see it. After a careless import, your entire blog shows the same recent date, as if a decade of writing appeared in a single afternoon. To a reader browsing your archive, this is confusing and undermines trust, because a guide that clearly references old events now claims to be brand new. To search engines, it muddies the age signal: pages that had established histories now look freshly minted all at once, which is both inaccurate and the opposite of the gradual, genuine freshness a real archive shows. Web Almanac 2024 ([HTTP Archive](https://almanac.httparchive.org/en/2024/)) is a reminder of how much content sites accumulate, so a reset can misdate hundreds or thousands of posts in one move. ## Do dates actually matter for SEO It is important to be measured here, because dates are often over weighted in people's minds. Original and last modified dates are signals that help search engines and readers judge a page's age and freshness, which matters for time sensitive queries where recency is genuinely relevant. They are not, however, a major ranking factor; content and links carry a page, as the [Ahrefs study](https://ahrefs.com/blog/search-traffic-study/) and [Backlinko analysis](https://backlinko.com/search-engine-ranking) show. So resetting dates will not collapse your rankings. What it does is misrepresent your archive and disturb freshness signals you would rather keep honest. The right framing is accuracy: keep the dates true because they describe your content correctly, not because they are a powerful lever. ## Published date and modified date There are really two dates worth preserving, and they say different things. The published date records when a post first appeared, anchoring it in time and establishing its history. The last modified date records when it was meaningfully updated, which is the freshness signal that matters when you genuinely revise content. A good migration carries both. A common mistake is to let the import set the modified date to now for every post, which falsely marks your whole archive as just updated, the same misleading effect as resetting the published date, only on the freshness axis. Carry the real published date and the real modified date, and do not let a bulk import overwrite either with the time of the move. ## How to carry dates across The remedy is to treat dates as fields to map, not values to default. When you export your posts, include the original published and modified dates, and when you import, map them into the new platform's corresponding date fields rather than leaving them blank for the system to fill. This is part of carrying your full content faithfully, alongside the body, metadata, and URLs, the same completeness covered in [migrate WordPress without losing SEO](/migrate-wordpress-without-losing-seo). If your export is incomplete or the live pages are your most reliable source, capture the dates the published pages actually show, then apply them on import. The principle is simple: the new platform should receive each post's true dates, so it never has to invent them. ## Check the dates after import Because date resets are silent, verification is essential. After importing, open a spread of posts, the oldest, the newest, and several in between, and confirm each shows its correct published date, and that modified dates were not mass set to the import day. If you find the archive collapsed onto one date, you can usually reapply the correct dates from your captured source before the site goes live, which is far easier than fixing it after launch. This check belongs in your pre launch routine, like confirming redirects and metadata, and it pairs naturally with a [content audit before the migration](/content-audit-before-website-migration), where you already have the list of posts and their details in hand. ## Steps to preserve publish dates 1. **Include published and modified dates** in your export or capture them from the live pages. 2. **Map both dates** into the new platform's date fields on import. 3. **Do not let the import default** dates to the time of the move. 4. **Avoid mass updating the modified date** for every post at once. 5. **Spot check old and new posts** after import to confirm the dates survived. 6. **Reapply correct dates** from your captured source before launch if any reset. ## Worked example: saving a decade of dates Imagine a blog with ten years of posts moving to a new platform. The first import test comes back with every post dated this week, because the date field was not mapped and the system defaulted to now. The team captures the true published dates from their source, including the dates shown on the live pages, and re runs the import mapping those values into the new platform's published date field, leaving the modified date alone except where a post was genuinely revised. They then spot check the oldest posts, a few from the middle years, and the newest, confirming each shows its real date. The archive now reads as the decade long history it actually is, rather than a suspicious burst of recent activity. Nothing about rankings swung dramatically, but the content is represented honestly, and the freshness signals stayed accurate, unlike the confusion that can follow a careless move and look like a [post redesign drop](/fix-seo-drop-after-website-redesign). ## Limitation: dates are accuracy, not a ranking lever It is fair to keep this in proportion. Preserving publish dates keeps your archive accurate and your freshness signals honest; it does not, by itself, raise rankings, and changing a date will not make a weak page rank. Conversely, faking newer dates to seem fresh is a poor tactic, because freshness helps only when the content is genuinely current, and misdating real content is just inaccuracy in the other direction. So treat date preservation as part of migrating content faithfully, the same care as keeping text, images, metadata, and URLs intact, rather than as an SEO trick. The goal is a true record, which is the honest foundation freshness signals are meant to reflect. ## Common mistakes - Letting the import default every post's date to the time of the move. - Mapping only the published date and letting modified dates reset to now. - Assuming dates carried across without spot checking after import. - Fixing reset dates after launch instead of before, when it is harder. - Faking newer dates to seem fresh, which misrepresents the content. ## Key points Posts keep their publish dates after a migration only if you carry the dates across deliberately, because a default import stamps every post with the import date and collapses your archive onto one day. That misrepresents your content and disturbs freshness signals, even though dates are a minor ranking factor rather than a major one. Map both the original published date and the last modified date into the new platform's fields, avoid mass updating the modified date, and spot check old and new posts after import, reapplying correct dates before launch if any reset. Treat this as carrying your content faithfully, alongside text, metadata, and URLs, the same completeness as a full [content export](/export-wordpress-authors-posts-excel). WPBuildAI scans your site and returns each post with its content, so you can confirm what published dates the live pages actually show. Send your web address for a free analysis. Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.