Nothing announces itself.
That is the entire problem.
A deploy adds a directive that blocks crawling. A plugin update breaks the contact form. A certificate expires on a Saturday. None of these produces an alert, an error page or a phone call — the site keeps looking exactly as it did, and the damage is discovered weeks later in a report nobody can explain.
Built for home services contractors, franchise systems and private equity portfolios whose sites quietly stop working — a form that fails silently, a page that slows, a plugin update that breaks a phone number. One location or two hundred, nobody notices until the leads stop.
The site looks fine. It has been leaving the index for six weeks.
This is the specific shape of the problem. Almost nothing that damages a website's search performance produces a visible symptom, so discovery is delayed until the consequence is large enough to appear in a summary.
Take the most common one. A release promotes a staging rule and the site's robots.txt now disallows crawling, or a template-level noindex survives into production. Every page still loads perfectly for a human. Nothing errors. The decline shows up in indexed pages first, then in traffic, then eventually in a monthly report — by which point four other changes have shipped and disentangling them takes longer than the original fix would have.
The pattern repeats across every category. Forms submit successfully and stop arriving because an SMTP credential rotated. Performance drifts one script at a time until field Core Web Vitals fail, with no single change to blame. A certificate expires on a weekend. None of these announce themselves, and all of them are cheap to detect and expensive to discover late.
There is a second index most maintenance plans never look at. Microsoft Copilot answers from Bing, which crawls separately, indexes separately and reports separately. A site can be healthy in Search Console while its Bing coverage quietly collapses, and nobody notices because nobody opened that console — the same two-index point covered in technical SEO.
When something does go wrong, Google publishes a structured sequence for debugging search traffic drops. Working it in order separates a technical fault from a seasonal change from a broad ranking movement. Guessing is the expensive alternative, and guessing is what happens when nobody captured a baseline.
Fix it when it breaks. Or notice it the day it happens.
Both are real maintenance plans with real invoices behind them. The difference is not effort or skill — it is where in the timeline the work happens, and that decides what the failure costs.
Waiting for a symptom
- Trigger. Somebody notices. Usually a customer, occasionally a salesperson asking why the phone stopped.
- Elapsed damage. However long it took anyone to notice — typically weeks for anything that is not visually broken.
- Diagnosis. Hard, because several changes have shipped since the cause, and nobody recorded what the site looked like before.
- Updates. Applied in a batch when something forces it, so a failure has several possible causes at once.
- Backups. Running, probably. Never restored, so nobody knows whether they work.
- The bill. Emergency hours, plus the lost period, which nobody puts on the invoice.
Checking on a cadence
- Trigger. A check fails. At deploy time for the two that matter most, on a schedule for the rest.
- Elapsed damage. Hours, because the check runs against the release rather than against a complaint.
- Diagnosis. Straightforward — one change, one check, one cause, against a recorded baseline.
- Updates. Applied deliberately and individually, so a regression is attributable to the thing that caused it.
- Backups. Verified by actually restoring one, because an untested backup is a belief rather than a backup.
- The bill. Predictable, and it does not include a quarter of lost traffic.
Maintenance covers three different jobs. Most plans cover one.
Keeping the software current, keeping the site findable, and keeping the leads arriving are separate disciplines with separate failure modes. A plan that only does the first is a plan that only prevents the visible failures.
The software layer
Core, plugin and theme updates, certificate renewal, backups, and the security posture underneath. Straightforward work with one discipline problem: applied in a batch, a regression has six possible causes and finding it takes longer than the updates did.
- Updates applied individually where a plugin touches the front end, so cause and effect stay attached
- Backups verified by performing a restore, not by confirming a job ran
- Certificate and domain expiry tracked ahead rather than discovered
- Every deploy compared against the previous state instead of assumed safe
The findability layer
Crawl access, index and canonical directives, coverage in both Search Console and Bing Webmaster Tools, redirects still resolving in a single hop, and field performance against Google's technical requirements.
- It sits between the developer and the marketer, so neither owns it
- Nothing here produces an error page, so no monitoring tool fires
- Bing has its own console that nobody opened
- Recovery is slow even after the fix, because reindexing is not instant
The revenue layer
A form that submits successfully and delivers nowhere. The visitor sees a thank-you message and assumes you have their details, so there is no complaint — you simply stop hearing from anyone, and it reads as a slow month.
- Real submissions sent on a cadence and confirmed as received, not just as sent
- Call tracking still attributing, and the number still tappable
- Conversion tracking still firing after theme and plugin updates
- Thank-you states still reachable only by converting, per landing page practice
What gets checked, and how often it earns being checked.
Cadence is a cost decision. The two checks that run at deploy time are there because a regression caught the same day costs almost nothing and the same regression caught in a quarterly review costs a quarter.
The standing checks
Everything below is dull, and that is the point. None of it is clever work; all of it is work that stops being done the moment nobody is specifically responsible for it.
- Crawl access — at every deploy. robots.txt compared against the previous version, because a disallow rule removes pages before any other directive is even read.
- Index directives — at every deploy. Template-level noindex and canonical state diffed against the previous release. This is the check that catches a staging rule reaching production.
- Form and call delivery — weekly. A real submission sent and confirmed received, and call attribution verified. Submitted is not delivered.
- Coverage in both consoles — weekly. Google Search Console and Bing Webmaster Tools, because Copilot answers from Bing and it reports separately.
- Field performance — monthly. Core Web Vitals on the templates that convert, tracked over time so gradual drift is visible before it fails.
- Links and redirects — monthly. Internal links still resolving, outbound citations still live, redirects still single-hop rather than chained.
- Backups — monthly, by restoring one. An untested backup is a belief. Restoring one is the only evidence that exists.
- Updates and security — continuous. Core, plugins and theme applied deliberately, with certificate and domain expiry tracked ahead.
Six regressions that arrived with a routine release.
Every one of these was introduced by a change nobody considered risky, and every one is caught by a check that takes seconds to run against a deploy.
The staging directive
A noindex or a robots Disallow written for a staging environment, promoted with the build.
Why it is worst: it removes pages silently and recovery is not instant — reindexing takes its own time after the fix. This is the single highest-value deploy-time check.
The form that stopped delivering
A rotated credential, a changed sending domain, a plugin update resetting a notification address. The visitor still sees a thank-you message.
Why it is expensive: nobody complains, so it reads as a slow month rather than a fault. Highest cost per day on this list.
Redirect chains
A single-hop redirect becomes two, then three, as pages are moved over years. Google documents how redirects should be implemented.
Why it accumulates: each individual addition is reasonable, and nobody ever looks at the whole chain.
Performance drift
A tracking script here, a chat widget there, a new font. No single addition is the problem; the sum fails Largest Contentful Paint in field data months later.
Why it hides: a lab test on a fast connection still passes. Only real-world data shows it.
Structured data that stopped matching
Hours, address or services change on the page and the LocalBusiness markup keeps stating the old values.
Why it matters: markup contradicting the visible page is a contradiction rather than an advantage, and it desynchronises the wider listing set.
Bing coverage collapse
Google coverage is fine, Bing coverage is not, and nobody opened the second console. Copilot reads Bing rather than Google.
Why it is missed: most maintenance plans define health as one dashboard being green. See AI SEO.
We restore a backup to prove the backups work.
We maintain sites for single-location contractors and for national franchise systems and private equity portfolios. A one-site operator and a two-hundred-site franchise system face the same failure modes; what changes is how many places a single bad update can break at once.
Almost every maintenance plan includes backups. Almost none of them ever restore one. A backup job that reports success and produces an unusable archive is indistinguishable from a working backup right up until the day it matters, and that is the day you find out.
So we restore one, on a schedule, to a staging environment. It is unglamorous, it produces nothing a partner can see, and it is the only evidence that the line item on the invoice is real.
The same principle governs the rest of the plan. Submitted is not delivered, so forms get a real test submission confirmed as received. Green in one console is not healthy, so both get checked. Every claim on this page links to the authority behind it; patterns we have observed are labeled as observations.
What separates this from a standard care plan.
Not a competitor teardown — a description of where the practices differ, so the choice can be made on substance.
| Practice | Standard care plan | AllegiantOMNIVIZ™ |
|---|---|---|
| Crawl and index directives | Not monitored | Diffed against the previous release at every deploy |
| Backups | Job reports success | Verified by actually performing a restore |
| Forms | Assumed working | Real submission sent and confirmed received |
| Search consoles | Google only, if any | Google and Bing, since Copilot reads Bing |
| Updates | Applied in a batch | Applied individually where they touch the front end |
| Performance | Lab score when asked | Field data tracked over time so drift is visible |
| When a drop happens | Guesswork | Google's published debugging sequence, against a baseline |
Four maintenance line items you can stop paying for.
Three of these are things that sound like protection and are not. The fourth is real work priced as something it is not.
Uptime monitoring as the maintenance plan. An uptime monitor tells you the server responded. It cannot tell you the site left the index, the form stopped delivering, or the markup now contradicts the page. Every failure on this page returns a healthy status code — which is precisely why they go unnoticed.
Backups nobody has restored. A backup that has never been restored is an assumption. The line item is legitimate; charging for it without ever testing it is where it stops being one.
Security plugin dashboards as evidence. A green score is a configuration report, not a security posture. Useful as an input; sold as the deliverable, it is a picture of a problem invoiced as a solution — the same pattern as heat maps in conversion work.
Ranking reports inside a maintenance retainer. Real work, wrong package, and the mixing is not accidental — it makes a maintenance failure look like an SEO problem. Google's guidance on evaluating third-party SEO advice is a fair lens here, including on us.
The pattern beneath all four: they report on something that is easy to measure rather than on the things that actually fail. The failures that cost the most produce no signal at all unless someone deliberately looks.
- Google Search Central — Technical requirements
- Google Search Central — Introduction to robots.txt
- Google Search Central — Block indexing with noindex
- Google Search Central — Redirects and Google Search
- Google Search Central — Debugging drops in Google Search traffic
- Google Search Central — Core Web Vitals
- Google Search Central — Understanding page experience
- web.dev — Largest Contentful Paint
- Google Search Central — LocalBusiness structured data
- Google Search Central — AI features and your website
- Google Search Central — Evaluating third-party SEO advice
- Search Console Help — Generative AI performance report
The questions operators actually ask.
Answered against primary sources where they exist, and answered honestly where they do not.
We have uptime monitoring. Isn't that maintenance?
It covers one failure class and misses the expensive ones. An uptime monitor confirms the server responded; it cannot tell you a template started returning noindex, that robots.txt now disallows crawling, or that the contact form stopped delivering. Every one of those returns a healthy status code, which is exactly why they go unnoticed for weeks. The checks that catch them are directive diffs at deploy and real test submissions. Related: technical SEO.
How would we know if our forms stopped working?
You would not, and that is what makes it the most expensive failure on the list. The visitor submits, sees a thank-you message, and assumes you have their details — so nobody complains. From your side it reads as a slow month. The only reliable detection is sending a genuine submission on a cadence and confirming it was received rather than confirming it was sent. Call tracking needs the same treatment, since an unattributed call is a conversion that happened and was never counted, as covered under landing pages. Google's technical requirements cover the site side.
Our traffic dropped. Was it an update or an algorithm change?
Work it in order rather than guessing — Google publishes a structured sequence for debugging search traffic drops that separates a technical fault from seasonality from a broader ranking movement. Check technical causes first, because they are the ones you can fix: crawl access, index directives, redirects still resolving, and whether anything shipped around the date the decline began. A recorded baseline is what makes this quick; without one, every diagnosis is a guess. Related: local SEO.
How often should plugins and core be updated?
Promptly for anything security-related, and individually for anything touching the front end. The discipline point matters more than the frequency: six updates applied together mean a regression has six possible causes, and finding it takes longer than the updates did. Applied one at a time, cause and effect stay attached. Whatever the cadence, the deploy should be followed by a check of crawl access and index directives against the previous release, and by field performance over time. See website design.
Do we really need to test backups?
Yes, and this is the plainest thing on the page. A backup job that reports success and produces an unusable archive is indistinguishable from a working backup until the day you need it, which is the worst possible day to find out. Restoring one to a staging environment on a schedule is the only evidence that exists. It produces nothing visible and it is the difference between a line item and a service. Once restored, the same technical checks apply to the restored copy against Google's technical requirements as to the live site — the audit itself sits under the website audit.
Why check Bing as well as Google?
Because Microsoft Copilot answers from the Bing index, which crawls, indexes and reports separately. A site can be entirely healthy in Search Console while its Bing coverage collapses, and most maintenance plans define health as one dashboard being green. Google's own AI features documentation makes clear that its AI surfaces draw on its Search index — which is the point: a separate index has separate failure modes. Two consoles, checked on the same cadence. See AI SEO.
How long does recovery take after we fix the problem?
Longer than the fix, which is the argument for catching things at deploy time. Correcting a directive is a minutes-long task; being recrawled and reindexed afterwards is not, and Google states that meeting every requirement does not guarantee indexing or serving. That asymmetry is the whole economic case for standing checks: the same regression costs hours when caught the day it ships and a quarter when found in a review. Progress is tracked in the consoles and, for AI surfaces, the generative AI performance report. Related: content.
Should maintenance include SEO work?
It should include the technical hygiene that protects what you already have — crawl access, index directives, redirects, page experience — and it should not include ranking work priced inside the same retainer. Bundling them is not accidental: it makes a maintenance failure look like an SEO problem, so the wrong lever gets pulled. Google's guidance on evaluating third-party SEO offers is a reasonable lens, including on us. Growth work belongs in SEO.
Our structured data was set up years ago. Does it need attention?
Yes, because the page changes and the markup does not. Hours change, a service is dropped, an address moves, and the LocalBusiness markup keeps stating the previous values. Markup that contradicts the visible page is a contradiction rather than an advantage, and it also desynchronises everything downstream — the profile, the listings, the citations that should all agree. It is a fast check and it is almost never on a maintenance schedule. Reconciliation across the wider set is directory management.
What does a maintenance report actually tell us?
What was checked, what changed since last time, and what failed — not a list of tasks performed. The useful version states the current state of each standing check against its previous state, so a slow drift is visible before it becomes a failure. That includes field Core Web Vitals tracked over months rather than sampled once, coverage in both consoles, and confirmation that a real form submission arrived. Anything we observed rather than measured is labeled as an observation. Start with an A.R.C. Report.
Find out what broke while nobody was looking.
A maintenance audit: crawl access and index directives across every template, coverage in both search consoles, whether your forms are actually delivering, field performance over time, and whether your backups restore. Findings are yours whether or not we work together.
- Crawl access and index directives checked template by template
- Coverage compared across Google Search Console and Bing Webmaster Tools
- Live form and call delivery test, confirmed received
- Redirect chains and broken internal links mapped
- Field Core Web Vitals on the templates that convert
- Backup restore test and update posture review
Explore the wider program: all services, technical SEO, website design, conversion rate optimization, profile optimization and reputation management.
We will tell you whether your site is still fully crawlable, whether your forms are delivering, and whether your backups would actually restore.
No cost, no commitment. We will follow up by email or phone to walk you through the findings.
