Supported scope
- Supported blog posts, site owner/author, blog categories, comments, files, and accessible pages from the selected API or archive path
- WordPress posts, pages, authors, taxonomies, comments, media, slugs, source IDs, and redirects
Weebly → WordPress
Weebly to WordPress migration
Move portable Weebly content into WordPress while separating API-accessible records and archive files from drag-and-drop layouts, store data, forms, widgets, and theme behavior.
Self-service migration path
Start with your actual Weebly data
This pair is not currently listed as a fully supported self-service direction. weebly: Beta. 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
What can move and what needs review
The app confirms available entities after connection. Final coverage depends on source access, downloadable assets, and the destination model you prepare.
Confirm after connection
- Classic Weebly versus Square-managed account access, page availability, blog comments, archive completeness, externally hosted files, and SEO values
- Page hierarchy, navigation, scheduled/draft posts, password-protected content, member areas, and source shutdown timing
Separate or custom work
- Store products, orders, customers, coupons, inventory, memberships, form submissions, and app records
- Drag-and-drop layouts, themes, widgets, slideshows, forms, scripts, and interactive behavior
Before you connect
Access requirements
Use a staging destination and the least-privilege access supported by each platform. Do not send credentials through a public form.
Weebly account and API access
Provide the account/site identifiers and approved API credentials where available. Confirm whether the site is classic Weebly or managed through Square.
Archive and crawl
Generate the Weebly site archive and provide it alongside a full crawl. The archive does not include blog or store pages, so it cannot be the only source.
WordPress staging
Prepare post/page types, taxonomies, authors, comments, media, SEO storage, permalinks, and an Application Password.
How it works
From connection to full migration
You control each stage in the app. Optional expert assistance is available for custom data or destination requirements.
01
Choose Weebly and WordPress
Start in the app and select the real source and target.
02
Connect both systems
Authorize read access to Weebly and connect a prepared staging WordPress destination.
03
Analyze the source
Review detected records, available entities, media, URLs, and anything that needs a decision.
04
Confirm the mapping
Choose where supported Weebly data belongs in the prepared WordPress model.
05
Run a free sample migration
Move a small set of real records to staging and inspect the result before purchasing the full migration.
06
Validate and launch
Review counts, records, media, links, warnings, and exceptions, then purchase and start the full migration when ready.
Technical detail
Platform-specific migration notes
Open only the detail you need for planning, mapping, or validation.
Current app compatibility
Weebly is beta and source-only in the site capability snapshot. The current app includes dedicated source coverage and integration tests for posts, categories, authors, comments, files, and supported pages.
Weebly source coverage
The app exposes site owner, blog taxonomy, blog posts/pages, comments, and files through the reviewed source path. Real account access and archive completeness are confirmed before estimating.
WordPress destination coverage
WordPress receives approved posts, pages, users, taxonomy, comments, media, slugs, and source identifiers through authenticated REST or Bridge access.
Weebly to WordPress compatibility matrix
Weebly API records, the downloadable archive, and the rendered public site expose different pieces of the migration dataset.
| Weebly source | WordPress target | Status and boundary |
|---|---|---|
| Blog posts | WordPress posts | Standard when accessible: title, body, URL, date, and published state are mapped. |
| Regular pages | WordPress pages | Review: availability and body structure depend on the API/archive path; layout reproduction is separate. |
| Site owner and post authors | WordPress authors | Review: preserve authorship without transferring Weebly credentials. |
| Blog categories | Categories or tags | Standard: normalize terms and rebuild relationships after term creation. |
| Comments | WordPress comments | Standard when exposed: posts load first; moderation and parent relationships are validated. |
| Uploaded files and inline images | WordPress media | Review: discover across API, archive, and HTML; then upload and rewrite accepted assets. |
| Page and post URLs | Permalinks and redirects | Delivery artifact: use the live crawl rather than filenames alone. |
| SEO titles and descriptions | WordPress SEO fields | Review: extract from accessible data or rendered pages and map to the chosen plugin. |
| Navigation and page hierarchy | WordPress menus and page parents | Review/custom: rebuild from crawl and page evidence; no generic visual navigation transfer is promised. |
| Store, members, forms, and apps | WooCommerce, membership, forms, or integrations | Separate scope: not standard content records in this pair. |
| Theme, sections, widgets, and scripts | WordPress theme and blocks | Rebuild: design and behavior do not migrate as portable content. |
Example Weebly to WordPress mapping rules
The mapping workbook combines API identity, archive assets, public URLs, and destination relationships.
| Weebly value | Migration rule | WordPress result |
|---|---|---|
| Post ID | Preserve as source identity | Stable post lookup for reruns |
| Post title, body, date, published flag | Normalize markup and translate state | WordPress post fields |
| Page URL and hierarchy evidence | Approve destination parent and slug | WordPress page and permalink |
| Category ID/name | Normalize, create, and resolve | Taxonomy relationship |
| Author identity | Match or create an approved author | Post authorship |
| Comment post ID | Resolve after the destination post exists | Attached WordPress comment |
| File or inline asset URL | Download, validate, upload, and rewrite | Owned WordPress media reference |
Combine Weebly API, archive, and crawl evidence
No single Weebly export represents the complete site.
Use API data where available
Extract structured posts, categories, authors, comments, files, and supported pages with stable IDs.
Treat the archive as partial
Use exported files and HTML as evidence, while recognizing that Weebly excludes blog and store pages from the archive.
Crawl the rendered site
Inventory public URLs, metadata, hierarchy, navigation, inline assets, canonicals, and redirect priorities.
Classify builder elements
Assign each layout, widget, form, slideshow, store, and app element to content transformation, rebuild, or exclusion.
Reconstruct Weebly routes before the source disappears
Public paths and blog URLs must be captured while the original site remains accessible.
Freeze a URL inventory
Record page, blog, category, archive, pagination, file, and priority backlink destinations.
Approve WordPress routing
Define post and page permalinks, parent paths, taxonomy archives, collision rules, and canonicals.
Rewrite dependencies
Replace internal links and accepted Weebly-hosted assets with destination references.
Test the cutover
Verify one-to-one redirects, chains, loops, metadata, sitemap entries, analytics, and forms.
Validate Weebly content across all extraction paths
Counts from the API, archive, and crawl are reconciled rather than assumed to match.
Reconcile entities
Compare posts, pages, authors, categories, comments, files, loaded, skipped, failed, and unresolved totals.
Inspect builder-heavy samples
Review long posts, complex pages, comments, external embeds, galleries, files, and high-traffic routes.
Confirm ownership and relationships
Validate authors, taxonomy, comment parentage, page hierarchy, media rewrites, and source IDs.
Document gaps
Record inaccessible records, archive omissions, unsupported widgets, accepted rebuild work, and post-launch exceptions.
Before purchase
Verify real output in staging
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
One migration, one-time payment
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
Weebly to WordPress guides
Weebly migration workflows
Review the combined API, archive, crawl, builder, and source-shutdown plan.
Open guide →Weebly to WordPress cost
Review source-path, reconstruction, volume, SEO, cutover, and package cost factors.
Open guide →Weebly to WordPress checklist
Coordinate the API, partial archive, crawl, WordPress preparation, launch, and source shutdown.
Open guide →WordPress migration workflows
Review WordPress destination modeling, users, taxonomies, media, SEO, and custom fields.
Open guide →More migration planning guides
- CMS migration workflows — Understand the broader self-service migration scope and delivery boundaries.
- CMS migration cost — See package limits, estimate factors, exclusions, and fixed-scope rules.
- CMS migration timeline — Connect access, mapping, dry runs, cutover, and stabilization to delivery time.
- Migration checklist — Coordinate discovery, staging, launch, and post-launch tasks.
- Migration validation — Review reconciliation, sampling, exception, and acceptance evidence.
- Migration security — Plan credentials, staging access, transfer, retention, and incident ownership.
- Shopify Blog to WordPress — Review the boundary between Shopify editorial content and a separate ecommerce migration.
- HubSpot CMS to WordPress — Review CMS content separately from CRM, consent, automation, and HubL behavior.
- TYPO3 to WordPress — Review page trees, content elements, FAL, languages, extensions, and Bridge versions.
- Umbraco to WordPress — Review document types, property editors, Delivery API, media, cultures, and members.
Clear answers
Frequently asked questions
No. Weebly states that blog and store pages are excluded. Combine approved API data, the archive, and a public crawl.
Yes when exposed through the selected source path. Posts load first, then comments resolve against destination post IDs.
Supported page content can migrate after extraction review, but drag-and-drop layout and widgets require WordPress reconstruction.
Included assets are downloaded, validated, uploaded to WordPress, and rewritten so accepted content does not depend on the old host.
No. Products, customers, orders, coupons, inventory, checkout, and Square integrations require separate ecommerce scope.
No. Themes, sections, widgets, forms, slideshows, and scripts require destination-native implementation.
Crawl the live site, approve final WordPress paths, prepare one-to-one redirects, and test priority routes before and after launch.
Next step
Start your Weebly to WordPress migration
Create an account, connect the systems, and analyze the supported scope before purchasing the full migration.