Website management that takes the burden off your shoulders

WordPress updates — what happens if you don’t install them?

WordPress is currently the world’s most popular content management system — it powers over 40% of all websites. However, this popularity comes at a price. The more widely used the software is, the more profitable it is to look for vulnerabilities in it — and the more people actively seek them out. The WordPress team regularly releases updates that patch discovered vulnerabilities, improve performance and adapt the system to changing technical standards. Each such update also serves as public information about what has been fixed — which means that owners of websites running on older versions have software on their servers with publicly documented vulnerabilities.

The problem isn’t limited to WordPress itself — in fact, plugins present a much greater opportunity for exploitation. The average WordPress-based website uses between a dozen and several dozen plugins, each of which is a separate piece of software developed by independent creators with varying levels of expertise and update frequencies. Some plugins are developed by large teams and updated regularly, others by individual developers who may abandon the project without warning. An abandoned plugin, whose author has stopped developing it, eventually becomes an open door for attackers — its vulnerabilities will never be patched, and the site using it becomes increasingly vulnerable with every passing month.

Regular updates sound like a simple task — log into the dashboard, click ‘Update All’, and you’re done. In practice, however, it is a task requiring knowledge and caution. Updates to plugins, themes and WordPress itself can conflict with one another — particularly if carried out in bulk after a long break. Updating a popular page builder such as Elementor or Divi can change the look of the entire site. A new version of WooCommerce can break the payment gateway. Updating a theme with custom code may overwrite previously made modifications. That is why professional website management never relies on blindly clicking “update” — every major update should be preceded by a backup and tested, ideally first in a staging environment, before it goes live on the production site.

Putting off updates “until later” is one of the most common mistakes made by website owners. The logic seems rational — if the site is working, why change anything? The problem is that every week of delay is a week during which the site is running on software with publicly known vulnerabilities. Industry research consistently shows that the vast majority of successful hacks on WordPress-based sites result precisely from unupdated plugins or themes — not from sophisticated, targeted attacks, but from mass scanning and exploitation of known, long-patched vulnerabilities on those sites that simply haven’t carried out the updates.

It is also worth mentioning server-side updates — specifically the versions of PHP on which WordPress runs. PHP is regularly developed, and older versions eventually lose support and cease to receive security patches. A website running on an outdated version of PHP is a twofold problem — on the one hand, a security risk; on the other, increasingly poor performance, as newer versions of PHP are significantly faster than older ones. Upgrading to a newer version of PHP sounds technical, and for many website owners, it is something they are completely unaware they should be doing. Meanwhile, the hosting provider will not usually enforce this automatically — or will do so at the least opportune moment, causing incompatibilities with old plugins.

Good website management means that updates are carried out regularly, sensibly and according to a defined process — a backup, an update under controlled conditions, and verification that the site is working correctly after every change. It is a routine that requires time and attention, but it eliminates a whole range of problems faced by owners of neglected websites. Instead of putting out fires after an attack or fixing the site after a failed update, you simply maintain the environment in a state where such situations rarely occur — and if they do, you have the tools to quickly return to square one.

Website backups — is the one provided by your hosting provider enough?

Website backups are a topic that most business owners treat much like insurance — they know it’s worth having, but rarely delve into the details of exactly what it covers and whether it will actually work when the time comes. The common belief is simple: the hosting provider does backups, so I’m safe. This belief is partly true — but it is precisely the untrue part that can come as a painful surprise at the worst possible moment.

Let’s start with what hosting backups actually offer. Most reputable hosting providers perform automatic backups — usually once a day, sometimes more frequently. They store them for a set period, typically between 7 and 30 days, depending on the plan. At first glance, this sounds reasonable. The problem arises when we look at the details. Firstly, in the vast majority of cases, hosting backups are stored on the same server infrastructure as your website — either on the same physical server or within the same data centre network. If the problem affects the server — hardware failure, a serious system error, an attack on the hosting infrastructure itself, a server room fire — the backup may be just as inaccessible as the website itself. History is full of cases where hosting companies have lost customer data along with their backups, because both were stored in the same location.

Secondly, the scope of hosting backups is often limited. Some providers only back up files on the server, omitting the database — or vice versa. A full backup of a WordPress-based website includes both files (theme, plugins, media, configuration files) and the database containing all content, settings and user data. A backup that covers only one of these layers is useless for a full site restoration. Thirdly, even if a backup exists and is complete, accessing it and the restoration process can prove surprisingly complicated. Some hosting providers require manual contact with support, who carry out the restoration within a few hours or days — and every hour the site is down represents a real loss.

A separate issue is the frequency of backups and the granularity of the history. A backup performed once a day means that, in the worst-case scenario, you lose a whole day’s work — all added content, new orders in the shop, completed contact forms, configuration changes. For an online shop with several dozen orders a day, this can be a significant loss. For a company website where you have just published a lengthy article or updated your product range, this is also a significant issue. A professional approach to backups involves taking copies at least once a day, stored in an external location independent of the hosting provider — most often in an external cloud such as Amazon S3, Google Cloud Storage or Backblaze — with a history going back at least 30 days.

It is also worth raising an issue that is rarely discussed — the verification of backups. A backup that has never been checked is a backup that cannot be trusted. Backup files may be corrupted, incomplete, or created at a time when the database was in an inconsistent state. The only way to be sure that a backup will work when needed is to regularly test the restoration process — uploading the backup to a test environment and verifying that the site functions correctly. This is a task that website owners practically never carry out themselves, as it requires technical knowledge and access to the appropriate environment. As part of professional administration, verifying backups should be a regular part of the work schedule.

There is one more scenario worth knowing about — and one that hosting backups handle particularly poorly. We’re talking about a situation where a malware infection isn’t immediate or obvious, but unfolds over time. Infected code can sit in the website’s files for weeks or months before it starts to act in a visible way. If the backup history only goes back 7 or 14 days, all available copies may already contain malicious code — meaning that restoring from a backup will not solve the problem, but will merely revert the site to its state prior to the most recent changes. That is why a long backup history — a minimum of 30 days, ideally more — is not a luxury, but a practical necessity which, at the right moment, can determine whether the site can be successfully cleaned up without losing months of work.

In summary — a backup from your hosting provider is a good starting point, but in most cases an insufficient security foundation for a website that plays a vital business role. An independent copy in an external cloud, regular verification of its completeness, and a long restoration history are the standard that should apply to every professionally managed website. It is one of those elements of technical support that remains invisible for a long time — until the day it turns out to be the only thing standing between the company and the loss of everything that has been built.

Website uptime monitoring — how does it work in practice?

Website uptime monitoring is one of those services whose value is almost impossible to overestimate — until you find yourself in a situation where its absence is painfully felt. Imagine your website stops working on Friday evening. All night, through Saturday, through Sunday — it’s unavailable. Potential customers get an error message, the contact form isn’t working, the shop isn’t accepting orders. You only find out about it on Monday morning, because a friend mentions in passing that they tried to visit your website and couldn’t. Such scenarios happen regularly — and are 100% avoidable.

Availability monitoring involves automatically and periodically checking whether the website responds correctly to requests. Specialised tools — such as UptimeRobot, Pingdom, Better Uptime or StatusCake — send a request to the server at set intervals, usually every one or five minutes, and verify whether the site returns a valid response. If the server does not respond, returns an error, or the response time exceeds a defined threshold, the system immediately sends a notification — via email, SMS or instant messenger — to the person responsible for administration. In practice, this means that the website administrator is often aware of the problem before the first visitors even notice it.

However, this is only the basic level of monitoring. The mere fact that the server is unresponsive tells us relatively little about what has actually happened and how serious the problem is. That is why a professional approach to monitoring includes several additional layers. The first of these is monitoring the HTTP response code — distinguishing between a 500 error indicating a server-side issue, a 404 error suggesting a broken URL, and a 503 error indicating overload or maintenance work. Each of these scenarios requires a different response and a different priority. The second layer is response time monitoring — a website may technically be ‘working’, but load so slowly that, from the user’s perspective, it is practically inaccessible. A sudden increase in response time often signals a database issue, server overload or malicious traffic.

Another key element is SSL certificate monitoring. SSL certificates have a specific expiry date — typically 90 days for popular Let’s Encrypt certificates or one year for commercial certificates. When a certificate expires, browsers display a warning to users about an unsafe site, which in practice means an immediate drop in traffic and a complete loss of visitor trust. Most systems automatically renew Let's Encrypt certificates, but automation can sometimes fail — a change to the server configuration, a problem with domain verification or an error in the renewal schedule can cause the certificate to expire without warning. SSL monitoring provides advance warning of an impending expiry, giving you time to react before the problem reaches users.

It is also worth mentioning domain monitoring — that is, tracking the expiry date of a domain registration. It sounds obvious, but losing a domain due to missing a renewal deadline happens surprisingly often, especially when a business owner has changed the email address linked to their registrar account and stopped receiving reminders. An expired domain is not just an inaccessible website — it is a risk of the address being taken over by third parties, who may use it for activities harmful to the company’s image or attempt to resell it at an inflated price. Losing a domain with an established history and SEO equity is one of the most damaging scenarios a website owner can face.

Security monitoring is a separate category — scanning the website for malware, unauthorised changes to files and suspicious activity. Tools such as Wordfence, Sucuri and MalCare regularly compare website files with reference versions of clean software, detecting any unauthorised modifications. Early detection of an infection makes a huge difference in terms of costs and the time needed for repair — malicious code detected within hours of being injected is incomparably easier to remove than an infection that has been developing for weeks and has had time to become deeply embedded in the file structure.

All these layers of monitoring together form an early warning system that drastically reduces the time between a problem occurring and its detection and resolution. In the context of website administration, this is the foundation of responsiveness — without monitoring, the website administrator is blind and only reacts once a problem is reported by a client or the owner themselves. With monitoring, they react before anyone has a chance to notice that something is wrong. That is the difference between a few minutes’ downtime and a failure lasting several hours, which has already reached dozens or hundreds of potential customers.

Managing an online shop — how does it differ from a standard website?

Managing an online shop presents a whole different set of challenges compared to maintaining a standard company website. It’s not just that a shop involves “more” — more subpages, more files, more plugins. The point is that an online shop is an environment where every minute of downtime, every technical error and every data inconsistency has a direct impact on revenue. A showcase website that displays an error for an hour loses potential enquiries. A shop that doesn’t accept orders for an hour loses actual money — immediately, in real time.

The first and most obvious difference is technical complexity. A shop based on WooCommerce, PrestaShop, Shopify or another e-commerce platform is a system many times more complex than a typical company website. WooCommerce alone — the most popular e-commerce platform for WordPress — comprises dozens of its own database tables, an extensive system of hooks and filters, its own caching mechanisms, specific server requirements, and entire ecosystems of extensions handling payments, deliveries, invoices, stock levels, loyalty schemes, and integrations with external systems. Every update in this environment is a potential source of conflict — between WooCommerce and the payment gateway, between the theme and the stock management plugin, between the caching system and the dynamic pricing mechanism. Testing updates on a production environment without first checking them on a test copy is, in the case of an online shop, tantamount to irresponsibility.

The key issue is the continuity of business processes. An online shop is not just a website — it is a system linked to multiple external services simultaneously. Payment gateways such as Przelewy24, PayU, Stripe or PayPal communicate with the shop via APIs and require up-to-date configurations, valid certificates and correct webhook addresses. Couriers — InPost, DPD, DHL, UPS — integrate with the shop via dedicated plugins or direct API connections. Invoicing systems, email marketing platforms, analytics tools, price comparison sites, and product feeds for Google Shopping — each of these integrations is a separate component that may cease to function following an update, a change to server configuration, or a modification to the shop’s structure. Shop administration involves regularly checking that all these connections are working correctly — because the shop may appear to be functioning, whilst customers are unable to complete their purchases or orders are not being sent to the courier system.

Product and catalogue management is a separate, often underestimated area of shop administration. Depending on the industry and business model, this may involve regularly adding new products with descriptions, photos and variants, updating prices and stock levels, managing categories and attributes, handling promotions and discount codes, and synchronising with an external warehouse system or ERP. For a shop with hundreds or thousands of products, this is a task that, without the right processes and tools, can take up a disproportionate amount of time. Errors at this level — incorrect stock levels, incorrect prices, duplicate products or non-functional variants — directly impact the customer experience and can lead to complaints, returns and negative reviews.

Online shop security is a topic that requires particular attention for one fundamental reason — the shop processes customers’ payment and personal data. Even if the transaction itself takes place via an external payment gateway and the shop does not technically store card numbers, personal data — names, addresses, telephone numbers, order history — is stored in a database and is subject to GDPR regulations. A security breach at a shop is not just a technical problem — it entails potential legal consequences, an obligation to report the incident to the Data Protection Authority (UODO), the need to notify customers, and the risk of severe financial penalties. This is why shops require an exceptionally rigorous approach to updates, access control, security monitoring, and regular configuration audits.

Performance in the context of an online shop has a different dimension to that of a corporate website. A shop’s product page is a dynamic environment — prices may be personalised, stock levels change in real time, and the shopping basket and user session must be handled individually. All this means that aggressive caching — which works very well for static company websites — requires a much more careful configuration in an online shop. A poorly configured cache in an online shop can result in outdated prices being displayed, incorrect stock levels, or — in extreme cases — shopping baskets being mixed up between different users. Optimising a shop’s performance is a specialist skill that requires an understanding of both the technical layer and the business logic of the e-commerce platform.

The response time to issues in an online shop must be significantly shorter than for a standard website. A shop that is down on Black Friday, at the peak of the festive season, or during an ongoing advertising campaign is a scenario that can cost the owner thousands of zlotys in just a few hours. That is why online shop management at GBoost comes with the shortest response times of all our packages — we prioritise your issues, even at weekends and outside standard working hours. The shop cannot go down — and this principle is the foundation of our entire approach to e-commerce support.

How much does website maintenance cost?

The question of how much website maintenance costs is one of those where the honest answer is: it depends. It depends on the type of website, its technical complexity, the platform used, the scope of work required and the response time needed. This is not an excuse or a dodge — it is the reality of a market where quotes start at a few dozen zlotys a month for basic maintenance and can reach several thousand zlotys for comprehensive management of complex websites and online shops. To make an informed purchasing decision, it’s worth understanding what really distinguishes these offers and what to look out for when comparing them.

The cheapest website management offers on the market — in the range of 50–100 zlotys a month — usually cover only automatic system and plugin updates, and occasionally a basic backup. It sounds good until you realise what ‘automatic updates’ actually mean in this context. It is usually a script or plugin that clicks ‘update’ without any verification of the result — without checking whether the site still works properly after the update, without testing in a staging environment, and without a backup taken just before the changes. If the update breaks something, the owner finds out for themselves — and it often turns out that the fix isn’t covered by the cheap package. This is a model that gives the illusion of technical support without actually providing it.

The mid-range — the 150–400 PLN per month bracket — offers real value, including manual verification of updates, availability monitoring, regular backups at an off-site location, and a set budget of hours for ongoing changes. This range is entirely sufficient for a typical company website, provided that the provider actually delivers on what they promise — and verifying this is not always easy before signing the contract. The GBoost packages for small and medium-sized corporate websites fall within this price range, where we focus on transparency of scope and specific, defined response times rather than vague promises.

Online shops and complex websites require a higher budget — usually ranging from 400 to several thousand zlotys per month, depending on the scale and scope. This is due to several factors simultaneously: the greater technical complexity of the environment, the need to manage integrations with external systems, higher requirements regarding response times, and often a higher monthly volume of editorial work — adding products, updating prices, and managing promotions.

 For a shop with hundreds or thousands of products, this is a task that, without the right processes and tools, can take up a disproportionate amount of time. Errors at this level — incorrect stock levels, incorrect prices, duplicate products or non-functional variants — directly impact the customer experience and can lead to complaints, returns and negative reviews.

Online shop security is a topic that requires particular attention for one fundamental reason — the shop processes customers’ payment and personal data. Even if the transaction itself takes place via an external payment gateway and the shop does not technically store card numbers, personal data — names, addresses, telephone numbers, order history — is stored in a database and is subject to GDPR regulations. A security breach at a shop is not just a technical problem — it entails potential legal consequences, an obligation to report the incident to the Data Protection Authority (UODO), the need to notify customers, and the risk of severe financial penalties. This is why shops require an exceptionally rigorous approach to updates, access control, security monitoring, and regular configuration audits.

Performance in the context of an online shop has a different dimension to that of a corporate website. A shop’s product page is a dynamic environment — prices may be personalised, stock levels change in real time, and the shopping basket and user session must be handled individually. All this means that aggressive caching — which works very well for static company websites — requires a much more careful configuration in an online shop. A poorly configured cache in an online shop can result in outdated prices being displayed, incorrect stock levels, or — in extreme cases — shopping baskets being mixed up between different users. Optimising a shop’s performance is a specialist skill that requires an understanding of both the technical layer and the business logic of the e-commerce platform.

The response time to issues in an online shop must be significantly shorter than for a standard website. A shop that is down on Black Friday, at the peak of the festive season, or during an ongoing advertising campaign is a scenario that can cost the owner thousands of zlotys in just a few hours. That is why online shop management at GBoost comes with the shortest response times of all our packages — we prioritise your issues, even at weekends and outside standard working hours. The shop cannot go down — and this principle is the foundation of our entire approach to e-commerce support.