WordPress Maintenance for Export Sites: What a Real Service Covers

No Comments

Photo of author

By Liu Yu

A WordPress maintenance service is the work that continues after the launch invoice is paid. Updates are the part everyone can see. The failures that spend the budget are quieter, and they sit there while the homepage still looks finished.

Three recorded patterns are enough to define the job. A form that stopped sending. A pile of backup files the public could download. A site that went white after a routine change. A retainer that does not look for these is a retainer that updates plugins and calls it care.

Twelve days, 207 paid clicks, one wrong key

On one site the enquiry form failed in silence for 12 days. During that stretch, 207 paid clicks landed on a form that could not send. The homepage did not announce the failure. The ads did not pause themselves. The root cause was a reCAPTCHA site key registered on a different domain. The widget still rendered. The check did not pass. Visitors saw a normal form and got no message back.

That is the maintenance test for any form. Submit it from a network that is not the office, on a phone, and confirm the message arrived in the inbox a human opens. Do it on a schedule, not after a customer complains. Twelve days is a long time to pay for clicks that cannot convert, and nothing on the pretty front end revealed it.

The same class of fault is written up as an invalid domain for the site key. If your form uses a challenge widget, the key’s domain list is part of the monthly check. A redesign, a domain change, or a staging copy promoted to production can all break it without touching the visual layout.

Thirty-six backup copies, sitting in the theme

In the theme directory of one site, 36 files ending in .backup were reachable from the public web. They were copies, and they were downloadable. A backup that lives inside the document root is not a backup. It is a second copy of the code, sometimes of configuration, offered to anyone who can guess the name.

A WordPress maintenance service should scan the web root for these leftovers. Old zip files. Editor backups. A dump of the database saved next to the theme “just for the afternoon” and left there through the next quarter. Delete them from the public tree after a real backup exists somewhere that is not the website. Then confirm the URL returns a not-found, so you know the file is gone rather than merely unlinked in a menu.

This is dull. It is also the sort of finding that does not show up in a plugin-update report. If the monthly note you receive is only a list of version numbers, you are not being shown the public directory. Ask for that scan by name.

White screens and mail are the other quiet breaks

A routine update can replace the site with a blank page. The useful response is a diagnosis before a random rollback. Which plugin, which PHP error, which URL. The longer version of that diagnosis is how a white screen gets diagnosed before it gets patched. Maintenance means someone will do that diagnosis on your site, with access arranged in advance, not after a weekend of guessing.

Mail fails on a different layer, and it fails while the form still says thank you. The message never leaves, or it leaves and lands in spam, or the DNS for the domain’s mail was never aligned with the server that now sends it. WordPress not sending email is the layer cake. A maintenance checklist that never sends a real message to an outside inbox will not catch it. Plugin updates will not catch it either.

What the month should actually contain

Updates of core, plugins, and the theme, on a staging copy if the site earns its living from the form. A look at the PHP error log, not only at the front end. A form test that includes the inbox. A scan for public backup files and for unexpected new administrator accounts. A check that PHP memory_limit has not been edited back to a value larger than the machine. A note, in writing, of what changed.

Performance belongs on the same list when the template is heavy. Google’s thresholds remain an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less, as published on the Core Web Vitals page. You don’t need to chase a perfect lab score every month. You do need to notice when a new image plugin starts serving the original 15 MB file again. That regression is a maintenance event.

Hacked pages are a maintenance event too. Google’s spam policies describe hacked content as anything placed on the site without permission, including injected pages and hidden links. The policy page is Google’s spam policies. A monthly look at newly published URLs and at outbound links you did not add is how that gets caught before a buyer does. Waiting for a search console warning is a slower version of the same job.

Where the update should run first

On a site that lives from the enquiry form, run core and plugin updates on a copy before you run them on the public URL. The copy needs the same PHP version as production, or the test is theatre. After the update, submit the form on the copy. Open the public site only when that message arrives.

Small brochure sites can be updated in place, with a backup taken first and someone watching the front end for ten minutes. Say which of the two patterns this retainer uses. “We update carefully” is not a pattern. A pattern has a copy, or it has a person watching, and it has a way back.

The way back is a backup you have restored at least once, stored outside the web root. A backup that has never been unpacked is a file with a hopeful name. The monthly note should say where it sits and the date of the last restore drill. If the drill has never happened, the note should say that too. Silence is how a missing drill survives for a year.

What the monthly note should list

Version numbers are the easy column. They are not the note. A note a manager can read in two minutes has six lines.

  1. What was updated, and whether it was on a copy first.
  2. Whether a real form message arrived in the inbox, and the date.
  3. Any new administrator account, and who it belongs to.
  4. Whether the public web root still contains backup files, dumps, or old zips.
  5. PHP memory_limit, if it changed.
  6. Any new URL that nobody on your side published.

The line-by-line buying list, the one you can hold next to a proposal before you sign, is what a WordPress care plan should include. This page is the service that has to perform those lines. The list and the retainer are not the same document.

Did the test message arrive? That is the line to read first. If the note does not contain it, the month was an update log, not a WordPress maintenance service. Ask for the line. You are paying for the answer, not for the version table.

New administrator accounts deserve a name. A user called admin2, created on a Tuesday, with an email at a domain you don’t own, is an incident. It is not a line to leave for the next quarter. The same scan catches a hacked account that updates nothing and simply waits.

Edits, emergencies, and the boundary

Maintenance includes a broken form, a white screen, a public backup file, and a mail path that stopped. It includes small text changes you can point at: a phone number, a changed address, a retired product taken down. It does not include a new catalogue structure, a second language, or a homepage film. Those are projects with their own scope. Mixing them into “unlimited small edits” produces either a refused emergency or a quiet second build.

Write the response time for a down site separately from the response time for a typo. A site that cannot send enquiries is the first kind, even when the homepage still loads. The 12-day, 207-click case was invisible from the homepage. The contract should treat a dead form as downtime, or you will discover the gap in the definition during the outage, which is the expensive moment to negotiate.

What a retainer should refuse

It should refuse a promise of rankings, of a fixed enquiry count, or of “we will keep you on page one”. Updates do not do that. Nobody honest sells that. It should refuse to hide the administrator account from you. It should refuse a scope that is only “unlimited small edits” with no definition of small, because that phrase is how a second redesign arrives disguised as maintenance.

Edits have a size. Changing a phone number is maintenance. Rebuilding the catalogue structure is a project. Write the boundary down. A WordPress maintenance service that blurs it will either refuse real emergencies or quietly do project work at a rate that makes no sense for either side.

Keep one queue for emergencies and another for edits, even if the same person does both. An emergency is a form that does not send, a white page, or a public file that should not be public. An edit is a sentence you can point at. When they share one unmarked queue, the sentence gets done because it is easy, and the form waits because it looks fine from the homepage. The 207 clicks landed on a form that looked fine. The queue rule exists so that “looks fine” does not outrank “does not send”.

Tianwen Network, founded in 2017, maintains 30–40 export WordPress sites. The 12-day form failure and the 36 public backup files are from that work. They are examples of the failure shape, not a claim that your site has the same bug today. The ongoing version of this job is described on WordPress support and bug fixes.

If the form on your site has not been tested this month, that is the first job. Send the URL. WhatsApp is enough: message Tianwen on WhatsApp. Say when the last test message arrived. If you don’t know, say that. It is a complete brief.

Questions about maintenance

What did a silent form failure cost in one recorded case?

The form failed for 12 days. 207 paid clicks landed on it. The cause was a reCAPTCHA site key registered on another domain. The page still looked normal.

Why are .backup files in a theme directory a problem?

On one site, 36 such files were publicly downloadable. A backup inside the document root is a copy of the code offered to anyone who can guess the name. Store backups outside the web root.

What should the monthly note contain besides version numbers?

Whether a real form message arrived, any new administrator account, whether public backup files remain, whether memory_limit changed, and any URL nobody on your side published.

Does maintenance include a new catalogue structure?

No. A phone number is maintenance. A new catalogue structure is a project. Write the boundary down before an emergency, not during one.

Leave a Comment