Blogger → WordPress
Analyze and move a Blogger or Blogspot publication into a prepared WordPress site through controlled post, author, label, comment, media, permalink, feed, validation, and cutover work. Blogger and Blogspot share this single commercial migration page.
Self-service migration path
This pair is not currently listed as a fully supported self-service direction. blogger: In development. wordpress: Available. Review system status and directions. Available migration objects and capabilities depend on the selected source and target systems.
Create an account, connect a staging destination, and let the app analyze the supported scope for this direction.
No credit card required to analyze the migration and run a free sample.
Scope
The app confirms available entities after connection. Final coverage depends on source access, downloadable assets, and the destination model you prepare.
Before you connect
Use a staging destination and the least-privilege access supported by each platform. Do not send credentials through a public form.
Provide the canonical Blogger or custom-domain URL. The current standard connection reads published content through the Blogger API and validates pagination.
Create a Blogger or Google Takeout backup before cutover. Export availability does not replace live reconciliation, but it provides an additional source artifact.
Provide a prepared staging site and an Application Password. Confirm permalink structure, author rules, taxonomies, media handling, and SEO storage before loading.
How it works
You control each stage in the app. Optional expert assistance is available for custom data or destination requirements.
Start in the app and select the real source and target.
Authorize read access to Blogger and connect a prepared staging WordPress destination.
Review detected records, available entities, media, URLs, and anything that needs a decision.
Choose where supported Blogger data belongs in the prepared WordPress model.
Move a small set of real records to staging and inspect the result before purchasing the full migration.
Review counts, records, media, links, warnings, and exceptions, then purchase and start the full migration when ready.
Technical detail
Open only the detail you need for planning, mapping, or validation.
This page is synchronized with the testing Blogger source capability and WordPress destination snapshot. Blogger is source-only and the standard app path reads published records from a public blog URL.
The current catalog exposes Author, Comment, Content, Tag. The standard connection reads public posts and their related authors, labels, and comments without presenting Blogger as a destination.
Authenticated REST and versioned Bridge adapters support posts, authors, categories, tags, comments, media, slugs, metadata, redirects, and approved destination models.
Standard means the current adapters expose the record directly. Review means identity, access, assets, or URL behavior needs an approved rule. Custom means it is not a configured Blogger source entity.
| Blogger source | WordPress target | Status and boundary |
|---|---|---|
| Published posts | WordPress posts | Standard: titles, content, dates, status, source IDs, and source URLs are read through the Blogger API. |
| Authors | WordPress authors | Review: visible author identity can map; passwords, Google Accounts, and permissions do not transfer. |
| Labels | Categories, tags, or another taxonomy | Review: one approved rule decides whether Blogger labels become categories, tags, or split taxonomies. |
| Comments | WordPress comments | Standard with validation: comments are loaded after posts and must resolve to the correct destination ID. |
| Post images and embedded media | WordPress media and embeds | Review: the source entity has no standalone attachment catalog, so files and embeds require content-level discovery and transfer checks. |
| Blogger post URLs | WordPress permalinks and redirects | Delivery artifact: year/month paths, custom-domain URLs, and mobile variants require explicit mapping and testing. |
| Feed URLs and subscribers | WordPress feeds or an external email platform | Review/custom: feed destinations and subscriber ownership are separate from post migration. |
| Draft, scheduled, private, or deleted content | WordPress editorial states | Custom access: the standard public path exposes published content only. |
| Standalone pages | WordPress pages | Custom: Page is not a configured entity in the current Blogger adapter catalog. |
| Theme, widgets, gadgets, and scripts | Theme, blocks, plugins, and integrations | Rebuild: presentation and functionality do not transfer as post data. |
The approved rules preserve source identity and relationships while making destination taxonomy, author, asset, and permalink decisions explicit.
| Blogger value | Migration rule | WordPress result |
|---|---|---|
| Post ID and URL | Preserve the source ID and add every known URL variant to the URL map | Stable rerun identity plus final permalink and redirects |
| Title, HTML, published date | Normalize safe content while retaining approved embeds and chronology | WordPress title, content, and publication date |
| Label | Apply the approved category/tag strategy and resolve term IDs | WordPress taxonomy relationships |
| Author ID and name | Match or create an approved author record | WordPress author assignment without Google credentials |
| Comment post ID | Load posts first and resolve the destination parent before comment creation | Comment attached to the correct WordPress post |
| Image URL | Discover in content, download, validate, upload, and rewrite | Owned WordPress media reference or documented exception |
Blogger migrations often fail after content import because the old post paths, custom domain, mobile parameters, and feed destinations were not treated as launch requirements.
Collect canonical post URLs, custom-domain paths, Blogspot hostnames, archive links, label pages, mobile variants, feeds, and priority inbound links.
Decide whether WordPress retains the year/month pattern or uses a different structure backed by one-to-one redirects.
Each valuable old post should resolve to its closest relevant destination instead of sending all traffic to the homepage.
Review Atom, RSS, FeedBurner, email, and subscription destinations separately from browser redirects.
A post can look correct while still loading images from Blogger or another external host. Asset acceptance requires destination ownership and rewritten references where included.
Parse representative and full post bodies for image, document, iframe, and media references instead of relying on a standalone attachment list.
Record inaccessible, hotlink-protected, malformed, duplicate, oversized, or unsupported files before declaring migration complete.
Create WordPress media records where approved and replace source URLs in body content and featured-image rules.
Open old, recent, simple, media-heavy, and high-traffic posts across desktop and mobile after the rewrite.
A successful importer run is not final acceptance. Counts, relationships, rendering, redirects, feeds, and analytics must be checked against the approved baseline.
Compare posts, authors, labels, comments, loaded, skipped, failed, and unresolved totals at every migration stage.
Verify dates, status, authors, labels, comment parentage, and representative long discussion threads.
Test one-to-one redirects, mobile variants, chains, loops, broken internal links, assets, canonicals, and sitemap entries.
Track crawl errors, indexed pages, landing-page traffic, feed behavior, forms, and conversions during stabilization.
Before purchase
The free sample migration creates a limited set of records in staging. Check fields, relationships, media, URLs, rendering, and reported exceptions before paying for the full run.
Pricing
Package fit depends on supported record volume and complexity. Analyze the source first, then review the fixed package or dynamic estimate shown for the migration.
Compare migration packagesPlan the move
Compare ownership, editing, design, SEO, maintenance, and migration tradeoffs.
Open guide →Plan exports, mappings, comments, inline media, validation, and cutover.
Open guide →Plan URL variants, redirects, metadata, feeds, launch checks, and monitoring.
Open guide →Estimate content, media, URL, destination, validation, and cutover work.
Open guide →Clear answers
Yes for supported public records. Posts load first, then comments are resolved to destination post IDs and validated for authorship, dates, visibility, and parent relationships.
Not through the standard public URL path. Draft, scheduled, private, or deleted records require an approved authenticated or export-based custom workflow.
Either can work. The mapping contract defines one consistent rule based on the current label structure and the prepared WordPress taxonomy model.
Included images must be discovered in post content, downloaded, validated, uploaded, and rewritten. Inaccessible or unsupported assets are documented as exceptions.
Standalone pages are not a configured standard entity, and themes, widgets, gadgets, scripts, and layouts require separate WordPress reconstruction.
The project can implement and test an approved redirect plan, but exact control depends on the old domain, Blogger configuration, destination hosting, and available redirect mechanism.
No. Reduce avoidable migration risk with URL mapping, redirects, internal-link updates, metadata review, sitemap checks, analytics, and post-launch monitoring.
Next step
Create an account, select Blogger and WordPress, and use the app to analyze supported public content before committing to the full migration.
