America/New_York
Blog
/
Start a Project
Available nowChat with me
Posts

Why Your Website Broke After You Didn't Touch It for 6 Months

May 7, 2026
It's one of the most disorienting things that happens to a business owner with a website: you log in one day, or a customer mentions something, and the site is broken. Form not working. Weird error message. Browser showing a security warning. Maybe the whole thing is down. And your first instinct is: I didn't do anything. I haven't touched it in months. That's actually the problem. A website isn't a sign in a window. It's a piece of software running inside a larger ecosystem of software, services, and infrastructure, all of which keep changing whether you're paying attention or not. When you leave a site alone for six months, you're not maintaining a stable object. You're drifting away from a moving target. Here's what actually breaks sites that nobody touched. Your site's HTTPS padlock comes from a certificate issued by a certificate authority. That certificate has an expiration date, typically one year. Most hosting setups auto-renew it. When auto-renewal works, you never think about it. When it doesn't, because a credit card expired, a DNS setting changed, or an automated renewal just failed silently, the certificate lapses. The moment that happens, every browser immediately shows a security warning to every visitor: "This connection is not private." Most people don't click through security warnings. They leave. This is fixable in minutes once diagnosed. But it often goes unnoticed for days because the site owner isn't monitoring it and customers don't always mention it. WordPress sites and sites built with plugin-heavy platforms are especially susceptible to this one. Your site was working perfectly in November. It had fifteen plugins installed, all on the versions that existed in November. Between November and now, twelve of those plugins released updates. Three of them released updates that changed how they interact with other plugins. One of them released an update that conflicts with the version of PHP your hosting environment runs. You didn't update anything. But the upstream developers kept shipping. And now something that was stable eight months ago is broken, not because of anything you did, but because the software your site depends on evolved and your site didn't come with it. The fix is usually a series of controlled updates. The prevention is updating regularly, ideally in a staging environment first. The server your site runs on isn't frozen in time either. Hosting providers update their infrastructure, the version of PHP they run, the database software, the server operating system. Usually these changes are gradual and backward-compatible. Sometimes they're not. A site that was built for PHP 7.4 may behave differently or break entirely on PHP 8.2, which is what the host quietly migrated to during routine infrastructure maintenance. You didn't change anything. The ground changed under you. Most websites pull in external services: embedded maps, booking widgets, payment processors, contact form services, newsletter signup integrations, social media feeds, analytics scripts. Those services change their APIs, update their embed codes, deprecate old versions, or occasionally shut down entirely. When they do, the part of your site that depended on them stops working. The rest of the site looks fine. But the contact form no longer submits, or the map shows an error, or the booking widget just shows a blank space where it used to be. You didn't do anything. The third party did. But it's your site that looks broken to visitors. Domain registrations renew annually. Most registrars send reminder emails before expiry, and most people have auto-renewal set up. But the email goes to an address nobody monitors anymore. Or the payment method on file expired. Or the domain was registered by a developer who is no longer involved and the renewal notification goes to their inbox, not yours. A lapsed domain means the site goes down completely, and the domain may become available for someone else to register. This is the version of the problem that can turn from an inconvenience into a serious one very quickly. Browsers, Chrome, Safari, Firefox, regularly tighten what they allow. What was acceptable in a website two years ago may now trigger a security block or warning. Mixed content is a common example: a site that loads over HTTPS but pulls in certain images or scripts over HTTP. For years, browsers allowed this with a quiet warning. At some point they started blocking it. A site that was fine before that policy change displays broken images or console errors after it, with no change to the site itself. Your site might still be technically up and working, but invisible. Google periodically updates its indexing behavior, crawl priority, and ranking algorithms. A site that hasn't been updated in six months, no new content, no technical improvements, no signals of activity, may quietly lose ground in search rankings. This isn't a break you can point to, but it has the same outcome: fewer people find the site. A site can also get de-indexed if Google encounters enough crawl errors, if it identifies the site as having thin or duplicate content, or if something flags it as problematic during a routine audit. Without someone monitoring Search Console, this goes unnoticed until a business owner wonders why calls from the web stopped coming in. None of these require you to make a mistake. They happen to sites that were built correctly and left alone. The internet moves, and a site that doesn't move with it falls behind. "I didn't touch it" is true, but it's not an explanation. It's the explanation. The site broke because nothing was touching it, no one monitoring the certificate, no one running updates, no one watching Search Console, no one verifying that the external services it depends on are still behaving. This is why maintenance isn't optional for a site that matters to your business. Not because things will necessarily break in any given month, but because without someone watching, you won't know when they do.
If your site has been running on its own and you're not sure what state it's actually in, message me on WhatsApp. A quick check usually surfaces anything worth knowing, and most issues are straightforward to fix once they're identified.
On this page