Website Maintenance & Support in Pune: What an AMC Should Actually Include in 2026

Website Maintenance & Support in Pune: What an AMC Should Actually Include in 2026

A proper website maintenance AMC (annual maintenance contract) should cover five things at minimum: security patching of the CMS/plugins/dependencies, off-site backups with a tested restore process, uptime and SSL monitoring, a defined allowance for content changes, and a written SLA that says how fast someone responds when the site breaks. In Pune's market in 2026, that bundle typically costs somewhere between ₹2,000 and ₹18,000 a month depending on whether the site is a WordPress brochure site, a custom-coded application, or an e-commerce store — and most of the AMC contracts we see clients bring in for review are missing at least two of those five items, usually the backup guarantee and the SLA.

If you already have a website — built by us or by anyone else — and you're now trying to decide whether you need a maintenance contract, what it should include, and what a fair price looks like, this article is for you. It does not cover how to choose a developer to build a new site (we've written about that separately); it's about the after-launch relationship, which is a different problem with different failure modes.

Why this decision matters more in 2026 than it did five years ago

The honest answer to "do I really need this" depends on what your site is built on and how much of the internet's background noise it's exposed to. That noise has gotten measurably louder. Patchstack's State of WordPress Security research counted 11,334 new vulnerabilities disclosed across the WordPress ecosystem in 2025, a 42% jump over the prior year, and 91% of those were in plugins rather than WordPress core itself. Separate tracking in 2026 puts weekly plugin vulnerability disclosures above 250, with roughly 43% of them exploitable without any login credentials at all, and about 23% still unpatched a full month after they're made public. WordPress still runs somewhere around 41.5% of all websites globally as of mid-2026, which is exactly why it absorbs the overwhelming majority of CMS-related vulnerability disclosures — attackers write automated scripts once and point them at millions of sites.

The part that should actually change how you think about maintenance frequency: researchers tracking the most heavily exploited flaws found a weighted median time of about five hours between a vulnerability going public and mass automated exploitation starting. Five hours is not a window you can cover by "checking the site every few weeks." It's a window that only a scheduled, automated patching routine can realistically close, which is the core argument for a maintenance contract over ad-hoc fixes whenever something looks broken.

None of this means every website is under constant attack — a static five-page brochure site with no plugins and no login form has a much smaller attack surface than a WooCommerce store with forty plugins. But it does mean the cost of neglect compounds silently. A plugin that was safe when your site launched in 2023 can become a live vulnerability the moment a security researcher discloses a flaw in it, whether or not you've touched your website since.

What a maintenance AMC should actually include

Most agencies sell "maintenance" as a vague monthly retainer. A contract worth paying for breaks down into distinct, checkable line items. Here's what each one should mean in practice.

Security patching (CMS, plugins, themes, server dependencies). This isn't a one-time task, it's a schedule. For WordPress, that means core, plugin, and theme updates applied on a defined cadence (weekly is reasonable for most business sites; daily monitoring for anything handling payments or personal data) with a staging test before anything goes live on a site that has custom code layered on top of plugins. For a custom-coded application, the equivalent is dependency updates (npm/composer/pip packages), framework version upgrades, and server-level OS and library patches. Ask specifically: is this scanned and applied on a schedule, or only "when we notice something"?

Uptime monitoring. A script that pings your homepage every few minutes and alerts a human when it doesn't respond. This sounds trivial until your site goes down at 2 AM on a Saturday and nobody knows until a customer complains on Monday. The industry-standard framing here is the "99.9% uptime" SLA you'll see quoted by every hosting provider — that number allows roughly 43 minutes of downtime per month (about 8.76 hours a year) and not a minute more, without breach. Moving to 99.99% cuts that allowance down to around 4 minutes a month, which is a materially harder (and usually more expensive) commitment. Whatever number is in your contract, make sure it's tied to actual monitoring, not just a promise.

Backups and disaster recovery. This is the single most commonly missing item in AMC contracts we've reviewed for prospective clients. "We take backups" is not a guarantee — it's a sentence with no verifiable content. A backup clause worth signing specifies: frequency (daily is the reasonable minimum for anything with a database that changes — e-commerce orders, form submissions, blog content), retention period (30 days is common; e-commerce sites should push for 90), storage location (off-site/off-server, because a backup stored on the same compromised server is not a backup), and — critically — whether restores are ever actually tested. A backup nobody has restored from is a hypothesis, not a safety net.

SSL/TLS certificate renewal. Most certificates today are free (Let's Encrypt) and auto-renew every 90 days, but auto-renewal depends on a cron job or a hosting-panel process that can silently fail. When that happens, visitors hit a "Not Secure" browser warning that will crater your conversion rate within hours, regardless of how good your SEO rankings are. Maintenance should include someone actually confirming renewal succeeded, not just assuming the automation worked.

Performance monitoring — and this is the one people forget. A site that scored well on Core Web Vitals at launch does not stay that way on its own. Third-party scripts are consistently identified as the biggest threat to ongoing performance — a chat widget added by the marketing team, a new ad-tracking pixel, an analytics snippet, a personalization tool — each one added independently, each one degrading load time and interactivity a little more, until eighteen months later the site that used to load in two seconds takes six. Google's March 2026 core update increased the weighting of Core Web Vitals in ranking and added site-wide performance penalties, which means this drift is no longer just a UX nuisance — it's an SEO cost that compounds the longer it goes unchecked. Maintenance should include a quarterly (at minimum) Core Web Vitals check against the live site, not just a one-time report from the day it launched.

Content update allowance. A defined number of hours or a defined number of update requests per month — text edits, image swaps, price changes, adding a page — with clarity on whether unused time rolls over (usually it doesn't) and what happens when you exceed the allowance in a given month (usually billed at an hourly rate stated in the contract, not negotiated after the fact).

Related reading: if you're still choosing who builds or rebuilds the site in the first place, our guide on how to choose a web development partner in Pune covers vendor selection in more depth than we go into here.

The distinction that determines your bill: bug fix vs. change request

This is the line item most disputes come from, and it's worth understanding before you sign anything.

A bug fix means the site is not doing what it was built and agreed to do — a broken contact form, a checkout that throws an error on a specific browser, a page that displays the wrong price, a plugin conflict that breaks the layout. This is a defect in delivered work, and a properly written AMC covers it as part of the monthly fee with no extra billing, because the developer (or their predecessor) is responsible for it working correctly in the first place.

A change request means you want the site to do something new or different from what was originally agreed — a new page template, a redesigned homepage banner, an added filter on your product listing, a new integration with a CRM. This is new work, and it gets scoped and quoted separately, whether that's an hourly rate or a fixed quote per request.

The friction happens when the boundary is fuzzy. "The mobile menu doesn't work properly on iPhones" — is that a bug (it was supposed to work and doesn't) or a change request (nobody ever specified iPhone behaviour explicitly)? A contract that doesn't define this boundary in writing — with examples, not just abstract language — leaves it to be argued over every single time something comes up, usually with you on the losing end because the agency wrote the contract. Ask for a contract that lists example categories of each, states a monthly cap on how many "genuinely ambiguous" cases get resolved in your favour by default, and states the hourly or per-task rate for confirmed change requests up front, not after the work is done.

Red flags in AMC contracts

A handful of patterns show up repeatedly in maintenance contracts that end up being expensive or useless in a crisis:

• Vague scope language — "ongoing support and maintenance as required" with no line-item breakdown of what's actually covered. If you can't point to a specific clause and say "this covers a hacked site," it probably doesn't.
• No SLA, or an SLA with no teeth. "We aim to respond promptly" is not an SLA. A real one states a response time (e.g., 4 business hours for a critical issue, 24 hours for a minor one) and, ideally, what happens if that's missed.
• No backup guarantee, or a guarantee with no stated frequency, retention, or restore testing — see above.
• No data or code ownership clause. If you leave the agency, do you get your database, your source code, and your latest backups handed over cleanly, or does the relationship end with your site effectively hostage to their hosting account? This should be explicit, not assumed.
• Hosting lock-in disguised as "included hosting." Bundled hosting can be a genuine convenience, but if the contract doesn't separately state what happens to your site and domain if you cancel the AMC, you may find migrating away is deliberately made painful.
• No incident-response commitment for security breaches. A site that gets hacked needs someone who will actually clean it, not just "we'll look into it when we can." Ask what a compromised-site response looks like and whether it's covered under the AMC or billed as an emergency at a premium rate.
• No visibility or reporting. If you can't see what was actually updated, patched, or backed up in a given month, you have no way to verify the AMC is doing anything at all. A monthly or quarterly summary — even a short one — should be part of the deal.

Realistic AMC pricing in India, 2026

Pricing varies by what the site is built on, how much traffic it carries, and how fast a response you need. The ranges below reflect what's commonly quoted across Indian web agencies for 2026 — treat them as a planning band, not a fixed rate card, and always get a written scope alongside any number.

A few things worth noting about that table. First, e-commerce pricing runs higher not because the work is inherently more complex per hour, but because the cost of downtime is higher — an hour of checkout failure during a sale directly costs revenue, so the SLA and monitoring frequency both need to be tighter. Second, "custom-coded" sites often cost more to maintain than WordPress ones per feature, because there's no ecosystem of pre-built, community-patched plugins doing the heavy lifting — every fix is bespoke code review, which is also why the WordPress vs. custom build tradeoff matters for total cost of ownership, not just build cost. Third, these figures are for ongoing support on an existing site — they are a different number from what you'd pay for a new build, which our guide on choosing a Pune development partner covers with its own pricing table for that stage.

If you're currently paying at the very bottom of these ranges or below, it's worth asking exactly what's included — a genuinely comprehensive AMC rarely costs less than the low end shown here, and an unusually cheap quote is more often explained by a short list of inclusions than by efficiency.

In-house hire vs. external AMC: where the line actually sits

This decision comes down to volume and specialisation, not company size alone.

A single site under roughly 20–30 pages, updated a few times a month, no e-commerce. An external AMC is almost always the cheaper and more reliable option here. A part-time or full-time in-house hire capable of covering security patching, backups, and performance work costs a minimum of ₹25,000–₹40,000 a month in Pune's job market even at a junior level — more than a full year of most WordPress AMC contracts — and you're paying for a person's full attention on a workload that takes a few hours a month.

A handful of sites, or one site with frequent content changes (weekly blog posts, changing offers, active social campaigns feeding into landing pages). This is the zone where a retainer-style arrangement — an AMC with a higher content-update allowance, or a part-time freelance content editor paired with an external AMC for the technical/security side — tends to work better than either extreme. You get someone who knows your brand voice for content, and a specialist team for the parts that require actual security and infrastructure expertise.

An e-commerce store doing continuous catalog changes, running promotions, or multiple properties (a main site plus microsites, or a franchise/multi-location setup). This is usually where an in-house person starts to make sense — but typically for content operations and day-to-day catalog/CRM management, not for security and infrastructure, which still benefits from an external specialist because the skill (server hardening, vulnerability patching, payment gateway compliance) is narrow and hard to keep current with a generalist hire. Many businesses at this scale run both: an in-house ops person for daily changes, and an external AMC for security, backups, and performance.

The mistake to avoid in either direction: hiring in-house for security work without genuine specialisation just moves the risk from "the agency might not patch fast enough" to "our one person might miss something and there's no backup coverage when they're on leave." And relying purely on an external AMC for a site that needs daily content changes without an adequate allowance just pushes you into constant change-request billing that ends up costing more than a hire would have.

What actually happens when you skip maintenance

The consequences aren't hypothetical, and they don't scale linearly — they tend to look fine for a long time and then compound quickly.

An unpatched plugin sits quietly until a vulnerability in it is disclosed publicly; given the roughly five-hour median window before mass exploitation attempts begin, an unmonitored site is exposed the moment that clock starts, regardless of how long it had been running safely before. A compromised site typically gets flagged by Google Safe Browsing, which shows visitors (and search results) a "This site may be hacked" warning — recovering from that involves cleanup, a manual review request to Google, and lost traffic in the meantime, all of which costs far more in time and money than the maintenance would have. Hosting providers frequently suspend accounts hosting malware outright, sometimes with short notice.

Backups matter most exactly when nothing has gone wrong recently and complacency sets in — a site with no tested backup, hit by ransomware or a bad update that corrupts the database, can lose months of content, orders, or donor records permanently. An expired SSL certificate is a smaller-looking problem that still tanks conversions within hours, because most visitors will not click through a browser security warning. And Core Web Vitals drift is the slowest, least visible of these — a site doesn't crash, it just quietly loses organic ranking and conversion rate over eighteen months as third-party scripts and content accumulate, and by the time someone notices traffic is down, reconstructing what changed and when is far harder than catching it with quarterly checks would have been. Our SEO service page covers the ranking side of this in more depth if that's the angle you're most concerned about.

None of these failures require a website to be "important" or high-traffic to happen — they happen to small business sites and NGO donation pages just as often as large e-commerce stores, because most of them are automated attacks or automated neglect (a cron job failing silently), not targeted human effort.

How We Handle Maintenance

At Govindani Infotech, our approach to post-launch support grew directly out of building and supporting 650+ websites since 2018 — including more than 500 NGO donation platforms, where a missed backup or a broken payment gateway isn't an inconvenience, it's a donor who couldn't complete a transaction. That history shapes what we treat as non-negotiable in a maintenance arrangement: a defined patching schedule rather than reactive fixes, backups that are actually tested for restore rather than just taken, and a written distinction between what's a bug fix and what's a change request so neither side is guessing when a request comes in.

Because we build and support both WordPress sites and custom-coded platforms — including e-commerce stores on Shopify, WooCommerce, and custom carts — our maintenance scope adapts to what the site is actually built on, rather than applying one generic checklist to every client. A WordPress business site gets plugin and core update management with staging tests; a custom application gets dependency and framework-level patching; an e-commerce store gets the tighter monitoring and priority response time that a live payment flow needs.

We work with businesses whether or not we built the original site. A technical audit of an existing site — checking what's outdated, what's unpatched, whether backups exist and actually restore, and where Core Web Vitals have drifted since launch — is usually the right starting point before committing to any AMC, ours or anyone else's, because it tells you what you're actually paying to have covered.

If you want that audit, or a written maintenance scope specific to your site rather than a generic package, you can reach us through our contact page or by phone at 092019 58274. Our office is at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009.