Your website has been running for three years without major problems. It loads, it looks fine, it has the contact form. Nobody has complained. But beneath that façade runs a set of JavaScript libraries, plugins and dependencies the original developer installed in 2021 and nobody has touched since. Some no longer have active maintenance. Others have publicly documented security vulnerabilities. A couple aren’t even compatible with the browsers your clients use today.
This isn’t a hypothetical problem. It’s the real state of most corporate websites PTW reviews when running a technical diagnostic. The site “works”, but it’s built on components nobody supervises, accumulating risk with every month that passes.
Why it happens: technical debt on corporate websites
Technical debt on a website is generated the same way financial debt is: by taking shortcuts that make sense at the time, without calculating the accumulated future cost.
When a developer builds a site, they pull in external libraries rather than writing code from scratch. A slider, a forms system, an animation library, a Google Maps plugin, a chat solution. Each of those pieces is third-party code with its own lifecycle. When the project is delivered and the developer moves to the next client, that lifecycle continues with nobody at your company monitoring it.
The problem is compounded by three factors that combine quietly:
The original developer is gone. Nobody in your organisation knows the site’s architecture in depth. If something breaks tomorrow, the first step will be working out what’s installed before anyone can touch it.
The site “works”, so nobody checks it. This is the most dangerous logic in corporate web maintenance. Problems from obsolete dependencies don’t show up as visible errors immediately. They accumulate until a browser updates its engine, Google changes an indexing criterion, or an attacker finds a known vulnerability nobody patched.
The commercial team measures the site by what it looks like, not by what it runs. If the site looks fine on the manager’s phone, it’s assumed to be in good shape. Technical debt doesn’t appear on screen.
What this means concretely
To be specific: in 2021, a critical vulnerability in Log4j affected millions of systems using that Java library without knowing it. In the context of corporate websites, the most frequent equivalents are un-updated WordPress plugins, obsolete jQuery versions with documented XSS vulnerabilities, or npm libraries left without an active maintainer.
A real and verifiable example: jQuery UI, used heavily between 2014 and 2020 for interactive interfaces, has multiple known vulnerabilities in versions before 1.13.0. CVE-2021-41184, for instance, allowed HTML injection vectors in earlier versions. If your site was built in 2019 and nobody updated that dependency, the vulnerability has been sitting there for years waiting for someone to use it.
Another concrete case: Slick Slider, one of the most widely installed carousel plugins on WordPress, stopped receiving active security updates. Thousands of corporate sites still have it installed and active, because “the carousel works fine”.
The silent risk isn’t only about security. Obsolete dependencies also affect:
- Load speed: older libraries ship more JavaScript weight than modern versions or their current replacements.
- Browser compatibility: Chrome, Safari and Firefox update their engines constantly. A library that isn’t maintained stops guaranteeing compatibility.
- Technical SEO: Google penalises sites with high load times and with code that triggers browser security warnings. An unsupported dependency can be the cause of both.
- User experience on current devices: the behavioural patterns of old code create inconsistencies on modern screens or recent versions of iOS and Android.
How to assess the real state of your site’s dependencies
You don’t need to be a developer to make a first diagnosis. There are accessible tools that give enough information to understand whether the problem exists and how big it is.
Diagnostic tools you can use today
Google PageSpeed Insights (pagespeed.web.dev): Enter your site’s URL. Under “Opportunities” and “Diagnostics”, the report identifies JavaScript libraries with known vulnerabilities and code blocking the load. It isn’t a full dependency report, but it catches the most critical problems.
Retire.js (retirejs.github.io): A tool specifically for identifying obsolete JavaScript libraries or ones with known vulnerabilities. It exists as a browser extension and as a command-line tool. It scans the JavaScript running on your site and compares it against a database of known vulnerabilities.
WPScan (if your site uses WordPress): Identifies installed plugins, their versions, and cross-references that against the WordPress vulnerability database. The free version gives enough for a first diagnosis.
Chrome DevTools → “Sources” tab: In any Chrome browser, press F12, go to the Network tab and reload your site. Filter by “JS”. You’ll see every JavaScript library loading, including versions. You can then check manually whether that version has known vulnerabilities.
A review checklist for corporate web maintenance
You can apply this list without hiring anyone. It’s a starting point for understanding the real state of your digital asset:
- Do you know what CMS or technology your site uses and which version is installed?
- When was the last time anyone updated the site’s plugins or libraries?
- Does your site use WordPress? Are all active plugins updated to the latest available version?
- Are there plugins installed but deactivated? (they remain a risk vector)
- Does your site load external libraries from third-party CDNs? Are those CDNs still active and from trustworthy sources?
- Does the site have a current SSL certificate with no browser warnings?
- Does the contact form work correctly, and does the data reach the configured inbox?
- Is there any plugin or library whose name you don’t recognise and whose purpose you don’t know?
If you can’t answer three or more of these, the site has undocumented technical debt. That doesn’t mean it will explode tomorrow, but it does mean it’s operating without supervision.
The right way to manage website risk
The question PTW hears frequently is: “But if nothing has happened in three years, why change it now?”
The answer is in how risk accumulates. A vulnerability in a dependency isn’t activated the day it’s discovered: it’s activated the day someone decides to exploit it. And that someone can be an automated bot scanning thousands of sites looking for exactly that vulnerable version of a known plugin.
Corporate web maintenance isn’t continuous improvement in the cosmetic sense. It’s active supervision of a digital asset that represents your company to clients, prospects and competitors. A site compromised or down at a critical moment — during a proposal, after a campaign, the day after a commercial event — has a concrete cost that rarely gets calculated before it happens.
The right roadmap doesn’t mean rebuilding the site every two years. It means having visibility of the real technical state: which dependencies are active, which still have support, which need replacing and in what order of priority. That judgement is what separates a managed site from one that simply exists.
For companies working with PTW on ongoing support and monitoring, this process is part of the monthly supervision: dependency audits, updating libraries with active support, and documenting the site’s technical state. Not as a cosmetic service, but as the basic management of a digital asset that has to keep working properly.
If after reading this you don’t have clarity on your site’s real technical state, the logical starting point is PTW’s digital diagnostic. A structured review identifies exactly which dependencies are out of date, what risks exist and what makes sense to resolve first. No assumptions, no generic recommendations.