A rule changed on 15 March 2026, and no website noticed
On 15 March 2026 the maximum lifetime of a newly issued, publicly trusted TLS certificate fell from 398 days to 200 days. The rule comes from the CA/Browser Forum, whose Baseline Requirements also schedule the next steps: 100 days from 15 March 2027 and 47 days from 15 March 2029. No website changed that day and nothing broke. But every site whose certificate is installed or renewed by hand now has a shorter fuse than it had the week before, and the person who knew how to renew it may have left in 2024.
That is the pattern behind most launch-and-vanish failures. A website does not rot; a set of clocks runs out, one after another, and nobody has been assigned to read them. The site looks identical the day before each failure. This article lists the clocks, puts them in the order they tend to fire, and describes the discipline that stops each one.
Certificates: a clock that keeps getting shorter
Let’s Encrypt, the free certificate authority, issues 90-day certificates and recommends renewing them every 60 days. Its own schedule moves the default to 64 days on 10 February 2027 and 45 days on 16 February 2028. It says most automated users need no changes, but that you should verify your automation copes with shorter lifetimes.
Automation works until something beneath it changes: a host migration, a DNS edit, a validation step that stops succeeding. Then renewal fails and nothing announces it. Let’s Encrypt ended its expiry-reminder emails on 4 June 2025. The fix has two parts: automated renewal, and an alert from outside the system that fires well before expiry and reaches a person who will act on it. Dwize lists certificate rotation for managed domains among the maintenance it applies during a Care Year.
Domain and DNS: one date, sent to one inbox
A domain registration is a date in someone’s database, and the reminder goes to whichever email address is on file. The .IN registry warns that if the registrant cannot be reached by email, the domain may expire without their knowledge. When a .IN name is deleted, the site and any email on it stop working until it is restored, and after a 30-day redemption period plus five days it can be registered by anyone.
The registry suggests registering for the maximum term, which is 10 years, and having two people responsible for checking the details. Both remove a failure that is entirely administrative. Who holds the registrar login matters just as much, and it appears in the questions table near the end.
The CMS, PHP and the layers underneath
Patchstack, a WordPress security vendor, counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than in 2024. Of those, 91% were in plugins and 9% in themes; core had six, all low priority. For the most heavily exploited vulnerabilities, the weighted median time to first exploitation was 5 hours, and 46% of all vulnerabilities had no developer fix when they were made public. Patchstack sells protection, so read its framing with that in mind. The counts are the useful part.
WordPress.org says only the latest version is officially supported, although its security team backports fixes to older versions as a courtesy. By default, background updates for plugins and themes happen only in special cases decided by that team. On a default install, a plugin is updated when somebody logs in and clicks.
None of this makes WordPress a bad tool. Core had six low-priority issues in 2025, and a site with a disciplined maintainer can be run safely. What the numbers rule out is the arrangement where the maintainer is nobody. No monthly cycle beats a 5-hour window on the worst vulnerabilities, so what you control is how many plugins exist and how fast fixes go in. Our view on that trade-off is on its own page.
Underneath the CMS sits PHP. PHP 8.1 reached end of life on 31 December 2025, and the supported-versions table lists 8.2 security support ending on 31 December 2026. WordPress recommends PHP 8.3 or greater and says older versions may expose your site to security vulnerabilities. When a host moves you to a supported version, a theme nobody has touched since 2022 may stop working.
Newer stacks have their own version of this. In December 2025 the React team disclosed CVE-2025-55182, a critical (CVSS 10.0) unauthenticated remote code execution flaw in React Server Components, and noted that apps supporting them could be affected even without server function endpoints. A static site avoids that kind of runtime exposure, because no server code answers requests, but its build tools and dependencies still age.
Forms and email: failures nobody sees
The contact form is usually the first feature an owner asks for and the first to fail without a sound. A common cause is email authentication. Since 1 February 2024, Google requires SPF or DKIM authentication for senders to Gmail, and says unauthenticated messages might be marked as spam or rejected with a 5.7.26 error. A form that sends from the web server, using your own domain in the From line, passes only if your DNS authorises that server through SPF, or the message is signed with DKIM. Move the site or change the mail provider and the check can start failing. The visitor still sees a thank-you page, and you see fewer enquiries and blame the season.
Listings and speed: drift, not breakage
Google’s help page on special hours covers closures of up to 6 days in a row and advises confirming hours for official holidays even when they match your regular hours. A listing that still shows last Diwali’s timings sends customers to a locked shop. Nothing is broken, which is why nobody checks.
Speed drifts the same way. Google’s Core Web Vitals targets are LCP within 2.5 seconds, INP at or under 200 ms and CLS at or under 0.1, measured at the 75th percentile of page loads. Consider a clinic that adds a 4 MB phone photograph to its homepage in month five. That is an illustration, but it is how a fast site becomes a slow one without any single decision to slow it.
Apps: two sets of dates you do not control
Apple has required apps uploaded to App Store Connect to be built with Xcode 26 or later since 28 April 2026, and since 9 September 2026 requires iOS apps to target iOS 13 or later. Google Play requires new apps and updates to target Android 16 from 31 August 2026 (a few categories such as Wear OS and TV have lower targets), with an extension to 1 November 2026 on request. Existing apps must target Android 15 or higher to remain available to new users on devices running newer Android versions.
Installed copies keep running. What decays is your ability to ship a fix, and your visibility on newer phones. An app nobody has rebuilt since launch is exposed to both.
A 12-month failure timeline
This ordering is illustrative, not a survey. The dates inside each row come from the sources above, and the sequence for your site depends on what it runs.
| When | What fires | What you notice | What stops it |
|---|---|---|---|
| Weeks 1 to 13 | First certificate renewal comes due | A full-page browser warning, if renewal quietly failed | Automated renewal plus an outside expiry alert |
| Months 1 to 3 | A plugin or dependency flaw is disclosed | Often nothing, until spam pages, redirects or suspension | Fewer plugins, fast patching, a named owner |
| Months 2 to 4 | Form email stops arriving after a mail or hosting change | Fewer enquiries; the form still says thank you | SPF or DKIM set up; a monthly test enquiry |
| Months 3 to 6 | Phone number, timings or festival closures change | Customers reach a closed shop or a dead number | One list of every place your details appear |
| Months 4 to 8 | Photos and pages pile up | The site feels slow on a phone | Image rules at upload; a quarterly speed check |
| Months 6 to 12 | The host’s PHP branch reaches end of life | A forced upgrade breaks an old theme | Tested upgrades; someone who reads the PHP calendar |
| Months 9 to 12 | An app-store requirement date passes | No fix can be uploaded; new users on newer phones lose sight of the app | A rebuild planned into every year |
| Month 12 | The domain renewal date arrives | Website and email vanish together | Multi-year registration, auto-renew, a mailbox two people read |
The discipline that stops each clock
Five habits cover almost every row. Give each clock an owner, a date and a place where the date is written. Automate renewals and patches, then watch the automation from outside. Keep a change log, so the next person knows what changed and why. Practise a restore once a quarter by recovering a backup to a scratch location, because a backup you have never restored is a hope. And remove moving parts you do not need. What you do not run cannot be exploited, which is why Dwize Site is delivered static-first.
Dwize’s version is written into the Care Year. Dwize monitors the delivered surface, applies maintenance, and sends at least one check-in a month. When something breaks, an incident ends with a written postmortem within 7 days of resolution. The operating standards page shows how each commitment is measured, and the Care Year page covers the rest of the year.
Questions to ask before you sign a maintenance contract
| Ask | A good answer sounds like |
|---|---|
| Who renews the certificate and domain, and how will I know if it fails? | A named owner, an automated renewal, and an outside alert |
| What happens when a security fix is released late on a Friday? | A stated cadence, not “we monitor” |
| How is one update counted, and how fast is it live? | A unit (request, page or change) and a number of days, in writing |
| Where do my form entries go, and who tests delivery? | A named inbox and a test schedule |
| Who holds the registrar, DNS, Google and app-store logins? | You do, with the vendor added as a user |
| What is not covered? | A written exclusions list |
| What do I receive if I leave, and when do I see the list? | Named exports and a date, before the contract ends |
When you do not need a Care Year
If you have an engineer who owns the code and reads the calendar above, you do not need to pay someone else to do it. If your site is a one-page link for Instagram and QR codes, a smaller product such as Dwize Go covers it, and you can check the pricing page for the difference. If an outage costs you almost nothing, a yearly retainer is more than the risk deserves. A Care Year makes sense where a dead form, an expired certificate or a lost domain costs you real enquiries, as it would for a clinic or coaching centre that takes bookings online.
Questions this answers
Quick answers
How often should a small business website be updated?
It depends on what the site runs. Content changes when your business changes. Software security fixes should go in as soon as they exist, because Patchstack's 2025 data puts the weighted median time to first exploitation of heavily attacked WordPress vulnerabilities at 5 hours. Clock items such as the certificate, domain and PHP version belong on a calendar with a named owner.
Is a static website maintenance-free?
No. A static site removes the plugin and server-runtime exposure, but the domain still expires, the certificate still renews, the contact form still depends on email authentication, and your Google listing still goes stale. It also has build tools and dependencies that age. It needs less patching, not none.
My SSL is automatic. Do I need to do anything?
Check that the automation copes with shorter lifetimes, which is Let's Encrypt's own advice, and watch expiry from a system outside the one being watched. Let's Encrypt stopped sending expiry emails on 4 June 2025, so a silent renewal failure no longer announces itself.
Will my app stop working if I do not update it?
Installed copies keep working, and Google says users who already installed an app are not affected. What you lose is the ability to ship fixes, because Apple has required new uploads to be built with Xcode 26 since 28 April 2026, and the discoverability of the app for new users on newer Android versions if it targets an old API level.
How do I know my contact form still works?
Submit a real test enquiry on the first of every month from a phone, and check which inbox receives it and whether it lands in spam. A form that shows a thank-you page tells you nothing about delivery.
- #website-maintenance
- #launch-and-vanish
- #ssl
- #wordpress-security
- #app-store
- #vendor-selection
