A Backup Nobody Has Ever Restored Is Not A Backup. It Is A Hope.

Ours run from INR 6,000 to 12,000 a month for a brochure site, INR 15,000 to 28,000 for a site that earns, and INR 35,000 to 60,000 where downtime costs money by the hour, all published above rather than kept for a call. Across the market you will see anything from a few hundred rupees to several lakhs, and the spread is not really about quality, it is about scope that nobody writes down. The number that makes plans comparable is the response window. A plan at a third of our price with no stated response time is not cheaper, because what you are buying in maintenance is mostly what happens on the bad day. Ask any provider for three things in writing: the response window, how often a restore is actually tested, and whose name the hosting is in. Those answers will sort the quotes faster than the prices will.

It mostly is not, and we would rather be straight about that. Maintenance protects what you have rather than growing it, and the pitch that it drives growth is usually stretched. What it genuinely does is remove a category of expensive week: the hack, the week of downtime, the expired certificate warning your customers saw before you did, the upgrade that broke checkout. There is a real indirect benefit, because a site that is down or broken cannot convert and cannot be crawled, so neglect does eventually cost you traffic and enquiries. But if you want growth, the money belongs in SEO or paid search. Maintenance is insurance with a monthly fee, and it should be priced and judged as insurance.

Yes, and for most businesses under about fifty people it is the sensible choice, because the work is occasional but needs doing on time and in the right order. The in-house version fails in a predictable way: somebody technical takes it on alongside their real job, does it well for four months, then stops, and nobody notices until an incident. Where in-house wins is on response, if you genuinely have somebody available. The decision is less about capability than about whether the task has an owner with time. If you do outsource, the two things to insist on are that every account stays in your name and that a restore is tested on a schedule, because those are the two places an outsourced arrangement quietly becomes a dependency.

Typically: core, plugin and theme updates, backups, some security monitoring and an uptime check. That list is also the problem, because it describes activity rather than outcome, and three of those four can be running perfectly while the site is unrecoverable. What should be included, and often is not: a restore actually performed to a staging environment on a schedule with the date recorded, a version calendar tracking your PHP and platform against their published end-of-support dates, an access audit, verification that certificate renewal is still working rather than just automated, a stated response window with a named contact, and documentation of who owns every account. Our full scope is in the deliverables section above. When comparing providers, ask which of those a plan includes rather than how many updates it covers.

Security patches as soon as they are available and tested, which in practice means a weekly cycle for most sites and immediately for anything flagged critical. Feature updates to plugins and themes monthly, on staging where the site matters. Backups daily at minimum, with enough version history to go back past the point a problem started rather than only to last night. Restore tests quarterly on a small site and monthly on anything that earns. Access audits quarterly, because administrator accounts accumulate. And version planning continuously against published dates, which is the part with real deadlines: PHP 8.2 loses security support on 31 December 2026 whether or not anyone has looked. Content is a separate question and depends on your business rather than on any maintenance schedule.

For most WordPress sites today, PHP 8.4, moved on staging first. The reasoning is in the published calendars rather than in preference. WordPress recommends PHP 8.3 or greater, and the PHP project’s own schedule shows 8.3 finished active support on 31 December 2025, so 8.3 now receives security fixes only. PHP 8.4 is in active support until 31 December 2026 and 8.5 until the end of 2027. Meanwhile 8.2 drops out of security support entirely on 31 December 2026, which is the deadline worth acting on if that is where you are. WordPress also notes that PHP 7.4 still works while being end of life and may expose your site to security vulnerabilities, so if you are on 7.4 or below this is urgent rather than housekeeping. Check the dates yourself, they are public and they do not move.

Because a backup is a claim and a restore is evidence, and the gap between them is where most site losses actually happen. Every compromised or broken site we have taken over had backups running and a dashboard reporting success. What failed was the output: a database dump truncated at a size limit, an uploads folder excluded from the job, a destination disk that filled up months earlier, a backup stored on the same server that died. None of those show up in a success message, and all of them show up the moment you need the file. Testing is not complicated: restore to a staging URL, open the site, check the database and the media, record how long it took. We do it in the first month and then on a schedule, and in roughly a third of inherited accounts the first attempt finds something that would have mattered. That is our own count rather than an industry figure.

You should, in your own name, with the provider granted access. This is worth settling before any money changes hands and it is the single most common trap we see. When a developer registers the domain and buys the hosting on the client’s behalf, it is usually genuine convenience at launch, and it becomes leverage later: leaving means migrating a site you cannot log in to, and the quote for that is rarely small. We have taken over sites where the client had no access to their own domain for years. Our arrangement is that every account is in your name from day one, documented on a single page with the work, and if you ever leave us you take working credentials rather than a negotiation. Ask any provider this question directly and get the answer in writing.

It depends entirely on your tier and you should know the answer before it happens rather than after. On Essential you get a response within two working days, which is honest rather than impressive and appropriate for a brochure site. On Standard, the same working day. On Managed, four hours with extended cover including evenings and weekends, because that is the tier for sites where an hour of downtime has a number attached. In every case monitoring alerts a named person rather than a shared inbox. The reason we publish these windows is that almost nobody in this market does, and best effort means whatever the provider needs it to mean at eleven at night. If a plan you are considering does not state a window, the scope is not defined, whatever the feature list says.

Yes, and we quote it separately from any maintenance plan on purpose. Recovery is its own piece of work: establishing how they got in, cleaning or rebuilding compromised files, checking for persistence left behind, resetting credentials, reviewing what data was exposed, then getting the site back cleanly. Folding that into a monthly fee would hide what the incident actually cost, and we think the client should see that number. Once recovery is done, a maintenance plan is the right next step, and it is usually the cheapest tier rather than the most expensive. One hard note: if a hack has been live for a long time, a clean rebuild of the site is sometimes safer and cheaper than cleaning, and we will tell you when we think that is the case even though it is a bigger quote.

Sometimes, which is why the method matters more than the frequency. Plugin and theme updates occasionally conflict with each other, with the theme, or with custom code, and the risk rises with the size of the plugin stack and the amount of bespoke work. The way to handle it is not to avoid updating, because unpatched software is a much larger risk than a layout glitch. It is to test on staging first, apply in a window, and keep a rollback path that somebody has actually used. That is why staging is included on the Standard and Managed tiers and used for upgrades on Essential. If a client declines staging to save money, we will still do the work and we put it in writing that we are accepting a risk on their behalf, so the decision is visible rather than implied.

For the first month after launch, yes, as part of the build. After that it is a separate arrangement and we think it should be, because bundling it permanently makes it impossible for you to judge what either thing costs. We would rather quote the build honestly, hand over a working site with every account in your name, and let you decide whether to buy maintenance from us, someone else, or nobody. A fair number of clients from our web design and WordPress work run their own maintenance afterwards with the documentation we provide, and that is a legitimate outcome rather than a lost sale.

Almost always, and we would rather not move you unless there is a real reason. We work with the common Indian and international shared and managed hosts and with VPS setups. There are two situations where we recommend a move and say why: when the host does not offer a PHP version still in support, which makes the version calendar impossible to follow, and when there is no practical way to run a staging environment, which makes safe updates impossible on a site that matters. Both are concrete constraints rather than preferences, and in both cases the hosting account goes in your name. We do not take hosting commissions and we have no interest in where your site runs beyond whether the work can be done properly.

The date of the last tested restore and how long it took, at the top. Then the version position, your PHP and platform against their published support dates with any upcoming deadline flagged. Then what was updated and whether anything needed a rollback. Then uptime and certificate status, including confirmation that renewal automation was verified rather than assumed. Then anything that needs a decision from you, and anything we think you should spend money on, including when the answer is nothing. It is deliberately short, usually one page, because long reports do not get read and an unread report is the same as no report. If you want the raw logs behind any of it, ask and you get them.

Yes. We provide website maintenance services in Delhi and across Delhi NCR, and we look after sites for businesses elsewhere in India and overseas, billed in INR, USD or AED. Good website support and maintenance work is entirely remote by nature, so being a website maintenance company Delhi NCR clients can visit matters less here than on design work. The same applies to our WordPress maintenance services, which are the bulk of what we do and do not require anyone to be in the same city. Before you hire website maintenance agency support anywhere, ask for one artefact: a recent monthly report from another client with the details removed. If it leads with a restore date and a version position you are talking to someone doing the job. If it leads with a list of plugin updates, you now know what you would be paying for.