A launch changes many things at once: layouts, navigation, forms, tracking, page addresses, and sometimes hosting. A drop that begins near launch deserves attention, but timing alone does not identify the cause.
This triage plan helps the business owner and website team separate urgent customer failures from measurement problems and longer-term search changes. Keep a record of the launch time, affected pages, and tests so each repair has evidence behind it.
Start with the actual business symptom
Clarify what declined. Is the office receiving fewer unique requests, is the analytics report showing fewer events, or are fewer suitable inquiries becoming booked work?
Compare a meaningful period with the earlier baseline and account for incomplete days, weekends, seasonal demand, advertising, and capacity changes. A quiet afternoon after a low-volume site's launch does not establish a trend, but a form that fails a direct test needs action immediately.
Ask the office team what it received, not only what the marketing dashboard displays. Separate spam, repeated contacts, and test submissions from genuine inquiries.
First priority: test every important contact route
Use the public site on a real phone and a desktop browser. Do not rely on the version an administrator sees while signed in.
- Open a core service page from the public navigation.
- Follow its contact button to the intended form or booking destination.
- Complete an authorized test with the fields a customer would use.
- Check that errors are understandable and the submit control works.
- Confirm the success message appears only after the intended action succeeds.
- Verify delivery to the actual business recipient.
- Test the displayed telephone link and call routing separately.
Check pages with different templates or forms, not just the contact page. A copied form can retain an old recipient, and a mobile overlay can obstruct a button that works on desktop.
Give a confirmed delivery failure to the person responsible for forms, hosting, or email routing. Until it is repaired, the business may need an accurate, working alternative contact route approved by the owner. Do not simply add another form that depends on the same broken delivery service.
Second priority: determine whether tracking changed
If real inquiries still arrive but the report falls, inspect the measurement configuration. Did the new site remove a tag, change a form identifier, replace a thank-you page, or alter the consent setup?
Google Analytics DebugView can help an appropriately configured test device show which events are collected. Google notes that privacy controls or consent choices can affect event visibility, so a missing event needs context.
Record the old and new definitions of the reported action. A click on “Get a Quote” differs from a delivered request. A redesign that stops counting repeated clicks may produce a lower number without reducing genuine inquiries.
Do not restore inflated tracking to make the graph look familiar. Correct the configuration, document the change in comparability, and keep test activity identifiable. Preserve customer privacy when inspecting form data and analytics parameters.
Third priority: find where traffic changed
If fewer visitors are arriving, separate channels and landing pages. A decline in paid traffic needs a different investigation from fewer organic clicks to one service page.
Compare available Search Console data with website analytics using compatible dates and filters. The systems measure different things, so they will not necessarily match exactly. Look for the location of the change rather than forcing their totals to agree.
Google's traffic-drop guidance recommends examining causes such as technical problems, demand changes, and ranking changes, and checking for reporting anomalies. Do not label every launch-adjacent decline an algorithm update.
Prioritize the affected pages. A site-wide failure, a missing service section, and a change concentrated on mobile each suggest a different next test.
Check old URLs and production indexing controls
Open important prelaunch URLs directly. Use the old site inventory, search data, customer links, or the migration map to find them. Confirm each URL still serves the intended page or redirects to a relevant replacement.
Watch for redirects to unrelated pages, chains, loops, and errors. Inspect internal links and any business-profile website link that may still use an old address.
Ask the developer to verify the public site's indexing directives, canonical destinations, sitemap references, and any staging restrictions. The production site should not accidentally identify a staging address as the preferred version or retain a development-only block.
Google's site-move guidance discusses URL mapping and monitoring, and notes that search fluctuations can occur as changes are processed. That is a reason to investigate carefully, not a reason to ignore a confirmed broken page.
When traffic is steady, inspect the decision to contact you
If visitors still arrive and forms work, compare the old and new experience on important service pages. Did the redesign remove information people used to assess fit?
- Can visitors quickly understand the actual service?
- Is the service area clear?
- Are useful qualifications, project details, and trust evidence still present?
- Is the next step visible and accurately described?
- Does the form ask for substantially more information than before?
- Do pop-ups, layout problems, or slow interactions obstruct the task?
Use actual customer questions and observed problems to choose a focused improvement. A new color scheme alone is not an adequate explanation for lower inquiry volume.
Choose the repair that matches the evidence
Hypothetical example: a contractor receives fewer quote requests after launch. Organic clicks to its main service pages look broadly similar, but the new form requires an attachment and some phone users cannot complete it. The first task is to verify and correct that obstacle, then repeat the submission and delivery test. Publishing more articles would not resolve the immediate failure.
Keep each finding in an incident record: symptom, affected page, confirmed evidence, proposed repair, owner, completion test, and review date. Distinguish a confirmed fault from a theory still being tested.
A full rollback may be appropriate for a serious unresolved launch failure, but it is a business and technical decision. Confirm what would be restored, what recent data might be lost, and whether a narrower repair is safer. Do not repeatedly switch versions without a recovery plan.
Follow through after the immediate fix
Retest the affected journey, inspect other pages using the same component, and record the repair time. Review actual inquiries and the relevant reporting over a suitable follow-up period, with any measurement break explained.
Close the incident only when the agreed tests pass and someone owns remaining work. Longer-term SEO should build on that evidence, not hide the problem beneath another broad redesign proposal.
Guardian's SEO services consider technical access, service content, and inquiry paths together. Our proposal checklist helps clarify who will investigate and implement repairs.
Discuss a post-redesign inquiry problem with Guardian Solutions. Share the website, launch date, the change you have observed, and any confirmed failing contact route.