WordPress hosting for an export catalogue is a capacity question. A buyer in another timezone can open dozens of product URLs while the office that built the site is asleep. If PHP runs out of memory, that buyer gets a partial page or a timeout. The plan name on the invoice will not tell you which.
Read four numbers before you read the brochure. Installed RAM. The live PHP memory_limit. How many PHP workers may run at once. Time to first byte. Those four decide whether the machine can serve the catalogue. The rest of the plan is packaging.
A 1 GB machine cannot honour a 1024M PHP ceiling
One recorded case is a 1-core, 1 GB machine running three WordPress sites. It stayed unstable for a long stretch. The site count was the wrong suspect. PHP memory_limit had been set to 1024M. That figure is the whole machine, before the operating system and MySQL take their share.
A single PHP process on that stack measured 80–124 MB. Six workers at the top of that range are a arithmetic problem, not a traffic mystery. Six times 124 MB is 744 MB, and MySQL is not in that sum. The machine has 1024 MB in total. The stable change was memory_limit at 256M, and the worker count cut from 6 to 4.
Here is the test to repeat on any host. Multiply the worker cap by the memory a real process used, not by the ceiling in the ini file. Compare that product with installed RAM. Leave room for the database. If the product is larger than the box, the host is oversubscribed on paper, even when the panel looks idle at noon.
Three WordPress sites on 1 GB can be a calm setup. The same three sites with a 1024M limit are not. Ask for the live php.ini value. An advertised “PHP memory” line on the plan page is a different sentence, and it is often the wrong one.
The 256M ceiling is still a ceiling, not a measurement of typical use. Four workers at 256M can in theory ask for the whole gigabyte if they peak together. What it stops is one request trying to allocate the entire machine and taking every other request with it. That was the failure mode. It is worth naming, because a lot of “the host is too small” tickets start here.
The disk filled up. The websites were not the large part
On a multi-site server the disk moved from 91% full to 37% full. The space did not come back from deleting a website. A filter plugin had written its cache into the database. One row was 30 MB. Enough rows of that size and the disk alert is a table problem.
A panel that only shows “disk used” hides this. You want the size of the largest tables, and a straight answer on whether a cache plugin may store blobs in MySQL. An object cache in RAM is a different design from a row that stays on disk after the visitor has left.
Before a migration, ask for the ten largest tables. A 30 MB row should be explained or removed before it rides to the new machine. Copying it faithfully is how the new host inherits an old mess and then gets blamed for it.
Backups make the same mistake when they snapshot the cache tables every night. The backup grows. Restore time grows. The catalogue did not. If the host bills by disk, you are paying to store a plugin’s scratch pad.
Time to first byte moved. The server did not
On waimaodulizhan.com the homepage time to first byte went from 2.14 seconds to 0.067 seconds. The machine stayed. The change was an nginx fastcgi_cache block. Another site on the same machine already had that block.
So a slow export site is sometimes a missing cache stanza. It is not automatically a reason to buy more cores. If you cannot add that stanza, the host is the constraint. Managed panels that hide the nginx file turn a one-line fix into someone else’s ticket. That difference never shows up in a CPU graph taken at lunchtime.
Measure it from outside the machine. The number you want is time to first byte, not the fully loaded page. A page can spend two seconds in PHP and then look “fine” in a screenshot. Ask the host which cache header a cached HTML response carries. If they cannot name it, you do not have a page cache. You have a hope.
A WordPress site that is slow while the checklist is green is this shape. The public test passed. The wait is still there. Read TTFB, then the cache header, before you order a larger plan.
A heavy first image fails the page when the server is healthy
One product template carried a 15 MB image in the first screen. Hundreds of product URLs then failed Core Web Vitals. The server itself was not the broken part.
Google’s published thresholds are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less. Those figures are on the Core Web Vitals thresholds page. A 15 MB file in the first screen spends the LCP budget before PHP has done anything wrong.
Hosting write-ups that ignore file weight send people shopping for RAM they do not need. The fix sits in the template. That work is WordPress development. A new invoice from the host will not shrink the file.
Ask for the byte size of the LCP element on a real product URL, on a phone, on a cold cache. If nobody on the call can produce that file size, the conversation about “premium WordPress hosting” is still missing the object the buyer actually downloads.
Server country is not a definitive ranking signal
Export teams hear this every year. Put the server in the buyer’s country, or Google will not treat the site as local. The current Google note on multi-regional sites lists the signals it actually uses. Country-code domains are a strong signal. hreflang is an explicit one. Server location, meaning the IP of the server, can be a signal because the machine is often near the users. Google also says it is not a definitive signal, because many sites use a CDN or sit in a country chosen for the quality of the infrastructure.
The page to read is how Google handles multi-regional sites. The server-location sentence on that page was checked on 22 September 2026. It calls the IP a signal, and not a definitive one. Pick the location for latency to the buyers you have, and for who can log in when the disk crosses 90%. Don’t pick it as a ranking trick.
Visitors inside mainland China are a different network problem. Licence, path, and the firewall sit in another decision. That decision is written up as hosting a website for visitors inside mainland China. An export catalogue aimed at buyers outside China should not be planned from that page.
Forty-nine sites, and the lower fee had a condition
A recorded move of 49 WordPress sites off Cloudways onto a self-managed VPS cut the fee for the same spec by more than half. The condition was a person watching the machines full time. The lower fee is a trade. A panel is swapped for an operator.
Tianwen Network, founded in 2017, maintains 30–40 export WordPress sites, plus three of its own. The figures on this page come from that work and from the Google pages linked above. They are not a forecast of enquiry volume, and they are not a promise that your TTFB will land on 0.067 seconds. That number is one homepage, after one cache change, on one machine.
If nobody on your side can read an nginx error log, a self-managed VPS is a worse product than a smaller managed plan. If someone can, the 1 GB box with a 256M limit and four workers is a calmer machine than the same box with a 1024M limit and six workers.
Five questions that sort a host on one call
Write the answers down. A vague answer is useful. It tells you the panel hides the number.
- Installed RAM, and the live PHP memory_limit.
- The PHP worker cap, and what one process used the last time the site timed out.
- The largest database table, and whether a plugin may write cache rows into MySQL.
- Whether you can set fastcgi_cache, or an equivalent, or whether that file is locked.
- Who is on call when disk use crosses 90% on a local holiday.
You don’t need a question about unlimited visits. Unlimited is not a number you can operate.
When the answers say you should leave, the move has its own failure list. Files can copy cleanly while mail, redirects, and cache do not. That list is moving WordPress to a new host.
Separate the wait into three clocks
A buyer says the site is slow. That sentence hides three clocks. Time until the first byte leaves the server. Time until the largest element paints. Time until a tap gets a response. The recorded homepage moved from 2.14 seconds to 0.067 seconds on the first clock only. The other two can still fail when the template ships a 15 MB image.
Is the host the bottleneck? Sometimes. Run the four numbers first. If memory_limit sits under the RAM, the workers fit, the largest table is an ordinary size, and TTFB is already a small fraction of a second, stop buying cores. Look at the image. Core Web Vitals is the public name for the second and third clocks, with the thresholds linked above. A hosting change that only touches TTFB can be a real win and still leave product URLs failing. Ask which clock was measured. If the answer is that the site “feels slow”, there is no clock yet.
The week after you sign
Write the four numbers down on the day you receive access. memory_limit, worker cap, largest table in megabytes, and TTFB from outside the datacentre. Repeat the TTFB reading at the hour your buyers are awake. A noon reading in the office that built the site is the wrong hour for a buyer several timezones away.
Plugin updates sometimes push memory_limit back to 1024M. The earlier repair is then gone. Check the ini value after updates. This is dull work. It is also how a 1 GB machine stays up after the first fix, instead of failing again in the same way six weeks later.
Is a bigger plan the right next purchase? Only after those notes exist. Without them, a larger plan copies the same ini file onto more RAM, and the 30 MB rows come along for the ride.
Cache layers that get mixed up
A page cache stores HTML. An object cache stores PHP lookups. A CDN stores files nearer the buyer. The fastcgi_cache change on this homepage, from 2.14 seconds to 0.067 seconds, is a page cache inside nginx. It does not shrink a 15 MB JPEG. It only sits in front of the HTML that points at the file. A CDN without a smaller image moves the same 15 MB closer to the buyer. The buyer still downloads 15 MB.
The browser cache helps the second visit, not the first. Export buyers often arrive once, from a search result, with an empty cache. Design that first visit. The second visit is a bonus.
If the host’s acceleration toggle does not name which layer it turns on, leave it off until someone can name it. An unnamed cache is how a changed product price stays wrong for a day. You edited the database. The HTML the buyer received was yesterday’s file.
What a managed plan still has to show
People pay for managed WordPress hosting so that patching is someone else’s job. Fair. Management does not replace the arithmetic. A managed plan that sets memory_limit to 1024M on a 1 GB instance is managed into the same crash. Ask the five questions anyway. If the desk cannot read them back, you are renting a queue, not capacity.
Shared neighbours are a hypothesis, not a default explanation. If TTFB jumps at the same hour and your own PHP is idle, a neighbour is worth testing. The test is to move one site, or to watch the process list during the spike. It is not a sentence in a sales call.
Backups belong in the same conversation. A backup you have never restored is a file, not a plan. Ask when the last restore was rehearsed, how long it took, and whether cache tables were excluded. You want a time, not a checkbox.
What this page will not claim
It will not name a best host. A brand that is fine for a quiet brochure can fall over under a 15 MB template and a 1024M PHP limit. It will not promise a ranking, a load time for your URLs, or a count of enquiries. Nobody can honestly promise those from a plan name.
It will not tell you to put every export site on the cheapest VPS. The 49-site move worked because someone was paid to watch the machines. Without that person, the cheaper box is how a 30 MB row sits there until the disk alert fires.
If you want the four numbers read against a site you already run, send the URL and the live memory_limit if you have it. If you don’t have it, that gap is already part of the answer.
Questions about WordPress hosting
Is a 1 GB server enough for three WordPress sites?
It can be. In one recorded case, three WordPress sites on a 1-core 1 GB machine were unstable because PHP memory_limit was 1024M. A single PHP process used 80–124 MB. Setting memory_limit to 256M and cutting workers from 6 to 4 restored it. The site count was not the cause.
Does the server's country decide Google rankings?
Google’s multi-regional documentation lists the server IP as a signal and says it is not definitive, partly because of CDNs. Country-code domains and hreflang are the explicit signals. Choose a location for latency and for who can administer the machine.
Why did one homepage TTFB fall from 2.14 seconds to 0.067 seconds?
The machine stayed the same. An nginx fastcgi_cache block was added. Another site on that machine already had the block. The figure is one homepage, not a promise for every URL.
A product page fails Core Web Vitals. Is that the host?
Not always. One template shipped a 15 MB image in the first screen, and hundreds of product URLs failed Core Web Vitals while the server was fine. The published thresholds are LCP 2.5 seconds, INP 200 milliseconds and CLS 0.1.