WP All Import hosting for runs that take longer than a request.
Importing fifty thousand rows is not a page load. It is a job, and the difference between a finished import and a half-finished one is entirely about how it is run.
Half an import is worse than none.
Every failure mode here produces a site that looks fine and is quietly wrong in a region of the data nobody checked.
Chunks small enough to finish, driven by cron
Imports run in batches on a real scheduler rather than in a browser tab somebody has to keep open. Closing the laptop no longer stops the job half way.
A unique key that actually matches
Re-running an import should update records, not create second copies. Matching on a stable identifier is what separates an update from thirty thousand duplicates.
Remote images pulled without stalling
Rows often reference images on somebody else's server. Those downloads happen with their own timeouts, so one unreachable file does not hold up the whole run.
Memory sized for the widest row
A single record with many fields and a long description is what sets the memory ceiling, not the row count. Limits are set from the widest row rather than the average.
A restore point before the run
The fastest fix for an import that mapped a field wrong is going back to before it. A snapshot is taken first, because noticing takes longer than the import.
The job outlives the request.
PHP request limits were written for page loads. An import is a batch process wearing a web request's clothes, and every default works against it.
- Batches driven by system cron, not a browser tab
- Records matched on a unique key
- Remote media fetched with its own timeouts
- Restore point taken before a full run
The measure is whether it finished.
Import speed matters far less than import completeness. A fast run that stopped at row nine thousand has produced a data problem, not a slow site.
What we change for WP All Import
Everything here treats the import as a background job rather than as a very patient page load.
| Setting | What we do | Why |
|---|---|---|
| Run mode | Chunked batches advanced by system cron | A browser-driven import stops when the tab closes or the connection drops, which on a long run means it usually stops. |
| Record matching | Keyed on a stable unique identifier | Without one, a second run inserts rather than updates and the catalogue silently doubles instead of refreshing. |
| Remote media | Downloaded with per-file timeouts | Feeds reference images on servers you do not control, and one unreachable file otherwise stalls every row behind it. |
| Memory ceiling | Set from the widest record, not the average | One row with many fields and a long body decides whether the process survives, and averages hide exactly that row. |
| Pre-import snapshot | Taken before any full run | A wrong field mapping is discovered hours later, and rolling back is faster than reversing a mapping across fifty thousand records. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why does my import stop part way through?
Re-running my import created duplicates. Why?
Can it download images referenced in the feed?
How do I undo an import that mapped a field wrongly?
Finish the import, every time.
Move the site across. Migration is free, import configuration reviewed.