A traffic graph can tell you that something changed. It cannot, on its own, tell you what to fix. Before I rewrite an article with falling visits, I check whether people can still reach it, whether the right page is being served and whether the measurement still works.
This is especially useful when several unrelated pages fall together. A common technical change deserves a look before every author is asked to improve their copy.
Write down exactly what fell
Start with the metric, the affected URLs and the first complete period showing the change. Search clicks, recorded sessions and enquiries describe different parts of a visit. Do not combine them into one vague claim that the site has lost traffic.
Google explains that Search Console and Analytics measure different activity, so their totals need not match. I compare the direction and timing of a change within each system, with consistent filters, rather than trying to make the totals identical.
Check whether the report is complete. A delayed import or a missing day is missing evidence, not a day with no visitors. Keep the original export so you can repeat the comparison after the data catches up.
Check what an ordinary visitor receives
Open an affected URL while signed out. Check the final address, the actual content and any unexpected login, error or verification screen. A successful response alone is not enough: an error message can arrive inside an otherwise successful page.
Try a small sample of affected and unaffected pages on mobile as well as desktop. If only one template fails, investigate that template. If the problem appears everywhere, shared assets, hosting changes or a common integration become more useful places to look.
Compare the public cached page with the expected current version using your normal diagnostic tools. Record cache headers and response details. Avoid clearing everything immediately: that can remove evidence and briefly make an intermittent problem disappear.
Line up the dates with technical changes
Make a short timeline of releases, consent changes, analytics changes, redirects and incidents around the first affected period. A matching date is a clue to investigate, not proof of cause.
For example, if recorded mobile sessions fall after a consent interface changes while search clicks remain broadly steady, test the mobile measurement journey. Do not immediately rewrite the pages. If both visitors and monitoring encounter errors, restore the broken journey before assessing the copy.
Server requests are another piece of evidence, but they include activity that is not a person reading a page. Use logs to check errors, response patterns and affected routes; do not relabel every request as a visitor.
Reassess after the repair
Save what changed, verify the affected journeys and wait for a complete follow-up period. Compare like-for-like days and relevant seasons. Keep content edits separate where practical so the follow-up is easier to interpret.
If delivery and measurement are working and the decline remains, move on to search intent, competing results, outdated information and internal links. The hosting check has narrowed the problem; it has not proved that the article is good.
My useful end result is a short evidence note: what fell, what was tested, what was fixed and what still needs checking. That is much more actionable than a red traffic badge.
Further reading: Google’s guide to using Search Console and Analytics together.