6 minute read · Practical marketing guidance
On this page 7 sections
Before updating a business website, decide what must keep working and how you will recover if it does not. A successful update message is useful, but your customers still need to read your services, navigate the site and reach your team.
For a Las Vegas or Henderson business using WordPress, this maintenance checklist turns an update into a small, accountable project. Use it before changing WordPress itself, a theme or a plugin. The goal is a clear decision to proceed, pause or request technical help.
1. Name the update owner and the business checks
Choose one person to coordinate the work. Record who will make the change, who will verify inquiries and who can reach the hosting provider if the dashboard becomes unavailable. Confirm those people are available during the planned window.
List the exact updates being considered and the reason for each. Avoid combining unrelated design edits with maintenance: that makes a changed result harder to explain. Check whether your host or another administrator also handles updates, so nobody starts overlapping work.
If access or responsibilities are unclear, complete the website access, renewal and handoff worksheet first. For this update, the owner needs a working recovery route, not passwords pasted into the checklist.
2. Check the backup before checking the update box
A complete backup of a typical WordPress site needs both its files and its database. Files include themes, plugins and uploads; the database holds content and settings. Downloading the website folder alone usually does not capture the database. See the official WordPress backup guidance.
Ask the person managing backups to confirm the latest successful backup time, what it includes, where it is stored and how it would be restored. A scheduled job is not proof that the latest run completed. Take a fresh backup before the planned change; WordPress recommends backing up before an update in its update instructions.
Where practical, have the technical owner test restoration into a separate environment. Loading an existing staging copy does not establish that your newest backup can be restored. Record which backup was tested and what worked. If restoration has not been tested, document that uncertainty and have the host or developer assess it before proceeding.
3. Use staging to rehearse the change
A staging site is a separate copy used for testing. WordPress’s plugin and theme troubleshooting lesson recommends staging for testing updates and investigating conflicts.
Ask how closely staging matches production, including the theme, plugins and hosting configuration. Confirm how test emails, payments and external integrations will be isolated. Use dummy information and approved test modes so rehearsals do not send customer notifications or create real transactions.
Staging reduces uncertainty, but it does not prove every live integration will work. An email service may behave differently on the staging domain. Plan to verify delivery again on the live site. Also confirm what deployment copies: replacing a live database with an older staging database can overwrite newer business data.
4. Record a baseline and agree on the sequence
Before changing anything, open the home page, a key service page and the inquiry page on a phone. Test navigation and the primary contact route. Submit a clearly labeled test inquiry using non-sensitive information, then confirm that the intended recipient actually receives it. Save the time and outcome.
WordPress’s Site Health screen provides configuration status and technical information about themes, plugins and the server. Ask the technical owner to record relevant warnings before the update, so existing issues are not mistaken for new ones.
Have that owner review the release notes, compatibility requirements and update instructions for the planned WordPress, plugin and theme versions, including any PHP requirements or dependencies and choose the sequence for this site. Do not assume a single “core first” or “plugins first” rule fits every combination. A long-neglected site or a component with dependencies may need a more deliberate plan. Keep a short change log and verify the important paths between manageable groups of changes.
After applying the planned updates, ask the technical owner to clear applicable caches and repeat the baseline checks on the public site while logged out. WordPress’s update guide notes that caching can keep showing an older version.
A before-and-after worksheet
Copy these two columns into your update notes. Replace each prompt with a name, time, result or decision. The final column becomes the handoff record.
| Before the update | After the update |
|---|---|
| Owner: Who performs the update, checks inquiries and contacts support? | Owner: Who completed each check? Who handles remaining issues? |
| Backup: Files + database confirmed? Time, location and restore-test result recorded? | Backup: Pre-update set retained? Current working state backed up after verification? |
| Staging: Planned updates rehearsed? Differences and deployment scope understood? | Staging: Live changes match the plan? Any unexpected differences recorded? |
| Pages: Home, service page and phone navigation work? Baseline saved? | Pages: Same pages and navigation checked as a visitor? Result and time saved? |
| Form: Labeled test arrives at the correct recipient? Baseline delivery confirmed? | Form: New live test received? Confirmation and any saved submission checked? |
| Inquiry path: Service page leads to the intended contact route? | Inquiry path: Buttons, links and any external booking handoff still work? |
| Stop rule: Which failed checks require a pause? Who decides recovery? | Decision: Accept, investigate or recover? New live data protected before any restore? |
5. Stop when a business-critical check fails
Agree on stop conditions before starting: an unusable service page, a broken inquiry route, missing test delivery or loss of administrative access. If one occurs, stop further changes and record the last completed update, the symptom and the time. Send that record to the technical owner or host.
Recovery may involve correcting configuration, addressing a specific component or restoring a backup. Let the responsible technical person assess the cause and the data consequences first. A full restore can remove changes made after the backup, including newly stored inquiries or orders. Identify those records and agree how to preserve them before restoring production.
After a fix, repeat the failed check and the other critical paths. If the fix changes a cached page, have the technical owner clear the applicable cache before verifying it. Check the public site while logged out as well as the dashboard.
The mobile website inquiry checklist can help investigate a customer-facing issue found during verification. Finish maintenance only when someone has confirmed the live result and documented any remaining work.
Make the next website conversation specific
If this checklist reveals a broader website problem, review Rank.Vegas’s website support page and email sales@rank.vegas. Include your website URL, the update you are considering and the page or inquiry step that needs attention. Do not send passwords or customer records.