Website maintenance in Bali: the checklist behind a useful care plan

Maintenance begins with consequences, not a list of plugins

For a villa, a broken availability or booking handoff can affect revenue immediately. For a property business, a lead form may appear successful while the CRM receives nothing. A wellness operator may leave an outdated programme, schedule, or contact instruction live for weeks. A portfolio site with no transactions has a different risk profile. Maintenance frequency should follow consequence, change rate, and system complexity.

List the journeys the website supports and assign a severity to each failure. Include the public page, the action, the receiving system, the notification, and the human response. This turns a vague care promise into something that can be tested. It also prevents a provider from reporting that the server was online while the only action customers needed was broken.

• Discovery: can search engines and people still reach the correct public pages?
• Decision: are services, prices, availability, policies, and proof still accurate?
• Action: do forms, calls, WhatsApp, bookings, payments, and account flows work?
• Response: does the message reach the right person with enough context to act?
• Measurement: are important actions recorded without exposing private data?

Create an ownership and access register first

Maintenance cannot be reliable if nobody knows who controls the domain, DNS, hosting, source code, CMS, database, email sender, booking tool, analytics, Search Console, social preview assets, or paid licences. Record the business owner, operational user, technical access, renewal date, recovery method, and vendor contact for each system. Keep secrets in an appropriate password manager, not in the maintenance report.

Review access when staff or providers change. Remove accounts that no longer need entry, keep business ownership above vendor access, and avoid a single personal account as the only recovery path. Document production, preview, and development environments so an update is not tested against the live customer journey by accident. A provider should be able to explain the access they require and why.

Treat backup and restore as separate controls

A dashboard saying “backup complete” is not the same as a recoverable site. Define what is backed up: source, database, uploaded media, configuration, redirects, content, and any business-owned files outside the application. Store copies away from the same failure domain where practical, protect access, set a retention period, and record the last successful run.

Test restoration on a safe environment at an agreed interval. The test should answer how long recovery takes, which data could be lost between backups, what credentials are needed, and who approves a production rollback. WordPress typically needs both files and its separate database. A code-deployed site may recover its application from version control while still requiring independent protection for forms, media, CMS content, or other persistent data.

• Recovery point: how much recent data could be lost?
• Recovery time: how long can the affected journey remain unavailable?
• Restore evidence: when was a complete recovery last tested?
• Authority: who can approve rollback, data replacement, or emergency DNS change?

Update software through a controlled path

Core software, frameworks, dependencies, themes, plugins, runtime versions, and third-party APIs change on different schedules. The maintenance scope should define how updates are identified, prioritized, tested, deployed, and reversed. Security-relevant changes may need a faster path than feature upgrades. Unsupported components need an explicit replacement decision rather than an indefinite warning.

For WordPress, check core, theme, and plugin compatibility, take or verify a backup, apply changes in a safe order, and test the critical journeys afterward. Site Health can surface configuration and software information, but it does not replace a business-specific test. For custom or static sites, dependency scanning and builds still need human review: a successful package update does not prove that a booking widget, layout, or analytics event continues to work. The platform comparison guide explains how these responsibilities differ by operating model.

Test the complete action, not only the visible button

A contact form can show a success message while email delivery fails. A booking widget can load but reject a mobile date selection. A WhatsApp link can open the wrong number. A payment can complete while the order system misses the confirmation. Maintenance tests should reach the receiving system with safe test data and verify the expected notification, attribution, and response path.

Name who supplies test accounts, how synthetic data is labeled, when a test transaction is refunded, and how private information is handled. Keep a short runbook for third-party outages: visible customer message, alternative action, vendor escalation, internal owner, and recovery confirmation. If a critical flow cannot be tested without a real booking or charge, agree on an appropriate controlled method rather than leaving it untested.

Maintain the search and content layer

Check that important pages remain indexable, canonical URLs still point correctly, the sitemap reflects the intended public routes, redirects resolve in one step, and accidental preview or duplicate pages have not entered search. Review Search Console for new indexing, security, manual-action, and enhancement issues at a reasonable cadence. Search Console does not need daily attention for most small sites, but it should be checked after material releases and when traffic changes unexpectedly.

Content maintenance is equally operational. Confirm opening hours, contact details, service boundaries, prices, policies, staff references, claims, and external links. Review structured data against what is visibly true on the page; markup should not preserve an old price or unsupported rating. For multilingual sites, update linked language versions together when the underlying fact changes and keep reciprocal hreflang intact.

Monitor performance and measurement without chasing one score

Watch for changes that affect real use: larger images, new fonts, consent tools, chat widgets, booking scripts, advertising tags, and content shifts near the top of a page. Lab tools are useful for repeatable diagnostics, while field data shows how eligible real visits experienced the site over time. A maintenance report should state the tool, URL, date, environment, sample, and limitation instead of presenting one best run as a permanent truth.

Verify analytics events against the actions they represent. A renamed form, new booking domain, changed consent setting, or modified button can silently break measurement. Keep an event dictionary with the business meaning, trigger, parameters, destination, and last test. Review trends to find investigation work, but do not attribute a ranking, lead, or revenue change to maintenance alone without comparable evidence.

Set a cadence and an incident boundary

A practical schedule might check uptime, critical actions, backup status, and urgent software issues frequently; review content, search, analytics, performance, access, and routine updates monthly; test restores and deeper cross-device journeys quarterly; and reassess vendors, licences, architecture, ownership, and recovery plans annually. The right interval depends on how often the site changes and how costly failure would be.

Define normal request hours, target acknowledgement for each severity, what qualifies as an incident, who can authorize paid emergency work, and which third-party failures remain outside direct control. Separate maintenance from new pages, campaigns, experiments, and integrations. A clear boundary protects both sides: the business knows what response it is buying, and the provider can reserve capacity for the failures that actually matter.

• Frequent: availability, critical customer actions, backup completion, urgent alerts.
• Monthly: updates, content facts, Search Console, event checks, access changes, broken links.
• Quarterly: restore exercise, device/browser journey, performance baseline, account review.
• Annual: architecture, licences, vendors, recovery objectives, support terms, ownership register.