Website maintenance checklist: September 2026
A maintenance review should leave you with evidence that the website still serves customers. Use this September checklist to agree a small, repeatable review with your developer. It is a suggested working routine, not a vendor-mandated schedule or a claim that every site needs the same changes.
1. Can you recover before you update?
- Ask for the date of the latest backup, what it contains and evidence of a restore in an isolated environment. A backup filename alone does not show that recovery works.
- For WordPress, include files and the database in the recovery plan. Review the installed version and compatibility requirements against the official update guidance.
- Test the intended change on staging first. Record who can roll it back and how newer orders or enquiries will be protected.
2. Does a customer action reach its destination?
- Walk through one agreed enquiry using non-sensitive test data. Check the confirmation, receiving mailbox or record, and a fresh read of the destination.
- If the form opens an email draft, verify the recipient and generated message. The visitor still has to send it; opening a draft is not delivery.
- For a shop, use an approved test payment and check the order record and notification. Keep payment-provider evidence separate from a successful browser screen.
3. Is the mobile experience getting worse?
- Check a service page and a key customer journey on mobile. Look for slow visible content, delayed interactions and layout that moves while someone is reading.
- Core Web Vitals cover loading, responsiveness and visual stability through LCP, INP and CLS. Use field data where available; a lab score alone is not proof of every visitor's experience.
- Record the affected page, device and observation. Choose one measured problem to fix, then repeat the same journey.
4. Did the repair preserve search access?
- Check that important public URLs still return the intended content. Google treats persistent server errors differently from successful responses; a repair needs more than one green homepage.
- Review whether staging restrictions, redirects or indexing settings accidentally reached production. Check canonical links and language versions after a migration.
- Leave a short maintenance record: what changed, what passed, what remains open and who owns the next action. Repeat at a frequency appropriate to how often your site changes.
5. September security review: check your actual software
- Two advisories updated on 8 September 2026 illustrate why maintenance must include software versions. The Windows-hosted Next.js advisory lists fixes in 15.5.24 and 16.3.3; the sharp image-processing advisory lists 0.35.4 as patched.
- These affect specific software and conditions, not every website or every WordPress installation. Ask your developer whether your deployed site uses the affected packages, choose a supported patched version and verify the running version after release.
Sources and further reading
- WordPress — Updating WordPress
- web.dev — Web Vitals
- Google — HTTP status codes and crawling
- Next.js — Security advisory updated 8 September 2026
- sharp — Security advisory updated 8 September 2026
Prepared with AI assistance and checked against the linked primary documentation on 9 September 2026. Practical guidance, not a claim of a new platform release or guaranteed results.
Still blocked after the safe checks?
Send Flow the exact error, when it started and the checks you completed. Never send passwords through the form.
Get website help