EAGLE SOLUTIONS
In short: Before a busy season, I check whether the hosting survives simultaneous carts and checkouts, since caching cannot help there; whether payments, couriers and the confirmation email still work with a real test order; and whether automatic updates should be frozen for a few weeks.
There are a few days in the year when your online store either brings in money or does not, and this online store checklist is about exactly those days: the first weekend of the season. Black Friday, the two weeks before Christmas, the opening of the ski season, graduation season: whichever one is yours, that day is not the time for debugging.
This article is about three things worth checking four to six weeks before the season. None of them makes anything prettier or faster. All three answer the same question: what happens if they really do show up tomorrow.
1. Will the hosting survive a crowd
The most common misunderstanding I run into: "everything is fine on my side, PageSpeed says 95". PageSpeed measures a single page load by a single visitor, served from cache. It is an important number, but it says nothing about what happens with a hundred simultaneous carts.
The reason is that in an online store the three pages that bring in the money are exactly the ones that cannot be cached: the cart, the checkout and the my account page. These differ from visitor to visitor, so every single time they open, that means real PHP execution and real database queries. While someone is browsing products, the server barely works. When fifty people want to pay at the same time, every click lives off the raw power of the server.
What is worth checking:
- How many parallel PHP processes your plan gives you. This is the number that is the real limit, and the one that shows up least often in the marketing material. Ask the hosting provider directly. On shared hosting it is often between 2 and 10.
- Whether there is an object cache (Redis or Memcached). For an online store this is worth more than page caching, because it takes the repeated database queries off the server, and the checkout generates exactly those.
- Last year's error log. If you have had a season already, the answer is right there in the server error log: "resource limit reached", 508 errors, memory exhaustion. If it happened last year, it will happen this year too, only more.
- Load test the cart, not the front page. The front page is served from cache, so every test gives a pretty result there. The real measurement is when you put load on the cart URL.
If the measurement shows the limit is tight, there are two solutions: a bigger plan, or less unnecessary work on the server. The second is often cheaper, since an online store frequently runs ten to fifteen plugins where two are actually needed.
2. Do payments, couriers and email still work today
This point sounds boring, which is why it gets skipped. If your store has been live for two years, then for two years nobody has checked whether the payment gateway keys are still valid.
What I go through before a season:
- A real test order, with a real card. In production rather than the provider's sandbox, with a hidden 1 RON product that I refund to myself afterwards. The sandbox tests whether the code is good. The real order tests whether your settings are good, which is a separate question.
- The payment provider's dashboard. Barion, SimplePay, euplatesc, BT iPay: keys, certificates and webhook addresses expire or go stale. The provider does send a notice about it, just to the email address you gave when the store launched.
- The courier integration. Fan Courier, Sameday, GLS, Packeta: generate a real waybill. APIs change versions, and the old integration often dies silently: there is no error message, it simply stops producing waybills.
- The order confirmation email. This is the most common silent failure I come across. WordPress sends through the server's
mail()function by default, without authentication, and Gmail and Outlook today put that kind of email in spam or simply drop it. On my own site I took this all the way: authenticated SMTP, SPF, DKIM, DMARC, and a mail-tester score of 10/10 at the end. Until that is in place, the order confirmation is a lottery, and a customer who gets no email assumes the order did not go through. - The acceptance checkboxes on your forms. On my own contact form I found that a badly configured GDPR checkbox disables the submit button. There is no error and no warning; nothing happens. At checkout the same risk exists with the terms acceptance.
- Stock. Set one product's stock to 1, order it, and see what happens with the second one. The middle of the season is the worst possible moment to discover that the store sells something that does not exist.
3. What changes on its own in the middle of the season
WordPress and the plugins update themselves by default. For eleven months of the year that is a good thing: security fixes arrive on time. During the two weeks of the season it works against you: an automatic update on Thursday night can break the checkout by Friday morning, and you meet it for the first time when the first customer writes to you.
What I do about it:
- A deliberate update round four weeks before the season. On a copy first, not in production. Then a full test order.
- A freeze window. From two weeks before the season until it ends, I turn off automatic updates for the plugins that touch the checkout, payments or shipping. Security updates are the exception: those go manually, after checking.
- A restore test. You only know a backup works once it has been restored. On a copy it takes half an hour, and it is the only way to find out whether your backup really contains the database too, not just the files.
- Have someone to call. Before the season, make it clear who is reachable for a Saturday afternoon problem, and how. If that is not spelled out, it does not exist.
What NOT to do before the season
This matters as much as the rest of the list. The four to six weeks before a season are not the right time to:
- put a new design or theme on the site,
- migrate hosting or the domain,
- switch payment providers,
- replace large plugins (page builder, stock sync, invoicing).
Each one can be a good idea in February. Before the season every change is a risk whose payoff arrives after the season, while its risk arrives during it.
The online store checklist in three lines
If you have no time for the details right now, this much is enough for a start:
- Ask the hosting provider how many parallel PHP processes you get, and look at last year's error log.
- Place a real 1 RON test order with a real card, and check whether the confirmation email arrives, including in the spam folder.
- Two weeks before the season, stop automatic updates, and try restoring the backup once to see whether it really comes back.
If you go through these three, you have already filtered out most of the likely failures of the season. The rest is what monthly maintenance is for, so that you do not have to do this once per season, in a hurry. If you want to know why building a site once is not enough, I wrote about that separately: why WordPress needs maintenance.
If you are launching an online store or taking over an existing one, the prices are here, or write a few lines about where you are now, and I will tell you what I would check first.
