Your organic leads fell 24% this month. The web developer updated the site, the marketing assistant rewrote six service pages, Google rolled out an update, and somebody changed the cookie banner.

Which change caused the drop?

Most small businesses can’t answer. They have charts, invoices, email threads, and half-remembered conversations, but no single record of what changed and when. The result is an expensive guessing session. One vendor blames Google. Another blames the redesign. The team starts reversing good work because it happened near the same time as the decline.

An SEO change log fixes that operating problem. It is a dated record of changes that could affect search visibility, website measurement, leads, or revenue. You can run one in a spreadsheet. Fifteen careful minutes each week is more useful than another dashboard nobody understands.

Why a Traffic Chart Is Not Enough

A line moving down tells you what happened, not why.

Google lists five broad causes of Search traffic drops: technical issues, security issues, manual actions, algorithmic changes, and changes in search interest. Google also recommends checking for reporting anomalies because data processing or logging errors can create an apparent decline: Google’s guide to debugging Search traffic drops.

Your own business adds more possibilities. A tracking tag may have stopped firing. Paid campaigns might have ended, reducing branded searches. A high-volume product may be out of stock. Call tracking numbers can fail. A sales team may classify leads differently after a CRM change.

Without a log, every event becomes a suspect. With one, you can line up dates, affected pages, and measured outcomes before deciding what to investigate.

Google specifically advises site owners affected by a core update to note its start and end dates from the Search Status Dashboard: Google’s core update guidance. That same principle should cover your releases. Record the full window, not just the day someone clicked publish.

What Belongs in an SEO Change Log

Do not record every corrected comma. Capture changes that could alter discovery, crawling, page meaning, user behavior, measurement, or conversion.

Use these categories:

  • Website releases: redesigns, navigation changes, templates, redirects, hosting, JavaScript, forms, checkout, cookie consent, and analytics tags.
  • SEO and content: new pages, deleted pages, title changes, substantial rewrites, internal links, canonicals, robots directives, schema, and sitemap changes.
  • Outside events: confirmed Google updates, Search Console data anomalies, outages, seasonality, promotions, press coverage, inventory changes, and major competitor moves.

Google says Search Console is the source of truth for performance in Google Search, while Google Analytics is the source of truth for behavior on your website: Google’s guide to using Search Console and Analytics together. Your log should sit beside both because neither tool knows that your agency launched a new header or your office stopped answering calls for three days.

The Eight Fields You Actually Need

A useful log does not need project-management software. Create one row per meaningful event with these fields.

1. Date and time

Record when the change reached the public website, not when the work started. If a rollout took several days, enter a start and end date.

Time matters when diagnosing a total tracking failure or broken form. A daily date is usually enough for content and ranking analysis.

2. Change category

Use a short controlled list such as technical, content, tracking, conversion, outside event, and Google update. Consistent categories let you filter the sheet later.

3. Plain-English description

Write what a future employee would need to know.

“SEO updates” is useless. “Rewrote the emergency plumbing page, changed its title, added pricing examples, and linked it from all four city pages” is useful.

4. Affected URLs

Link to the exact page or a saved list of URLs. For a sitewide template change, write “all pages” and name the template.

This field prevents a common reasoning error. If traffic fell only on product pages, a change limited to blog author bios is unlikely to be the direct cause.

5. Owner

Name the person or vendor who made the change. The point is not blame. The owner can explain the release, confirm whether it finished, and help reverse it if necessary.

6. Evidence

Link to a pull request, ticket, CMS revision, screenshot, vendor release note, campaign calendar, or official announcement. Preserve enough evidence to reconstruct what happened.

For Google updates, use the official Google Search Status Dashboard. For an apparent reporting problem, check Google’s Search Console data anomalies page before declaring a ranking loss.

7. Expected result

State what the change was supposed to improve and where you expect to see it.

Example: “Increase quote requests from the commercial roofing page without reducing organic clicks.” That gives the team two measurements instead of a vague hope that “SEO improves.”

8. Review date and result

Set a date to evaluate the change. Then record the outcome as positive, negative, mixed, or inconclusive, along with the relevant numbers.

Google warns that some search changes can take from a few hours to several months to show an effect, and not every change produces a noticeable result: Google’s SEO Starter Guide. Do not label a content revision a failure after two days. Choose the review window based on the size of the change, crawl frequency, traffic, and normal sales cycle.

A Copyable Example

Imagine a local HVAC company changes its air-conditioning repair page on June 8. The row might read:

June 8, 10:15 a.m. | Content + conversion | Rewrote service details, replaced hero image, shortened form from eight fields to four | /air-conditioning-repair/ | Owner: Maya | Evidence: CMS revision 1842 | Expected: hold organic clicks and raise completed forms | Review: June 29

Three weeks later, Search Console clicks are flat, form starts are up, and completed forms are down. That is a mixed result. The content probably did not damage search traffic, but the form or lead quality needs investigation.

Now compare that with “Updated AC page.” The second record gives you nothing to test.

How to Use the Log When Traffic Drops

Start with the shape of the decline. Google’s debugging guide illustrates different patterns for technical sitewide problems, algorithm changes, seasonality, and reporting glitches: Google’s traffic-drop documentation. A sudden cliff across every channel calls for a different response than a gradual loss on three blog posts.

Then work through this sequence.

Confirm which number moved

Did Search Console clicks decline, or only Analytics sessions? Did impressions fall? Did conversions fall while traffic stayed level? Did phone calls decline while forms increased?

If Search Console remains steady but Analytics organic sessions collapse on the same day as a consent or tag change, investigate measurement first. Google explains that the two systems measure different activity and will not match exactly: Search Console counts what happens in Google Search, while Analytics records behavior inside the site: Google’s Search Console and Analytics comparison.

Segment before you blame

Compare pages, queries, devices, countries, and search appearance in Search Console. Google recommends comparing the drop period with a similar period and examining these dimensions to identify the pattern: Google’s traffic-drop debugging steps.

A sitewide decline points toward sitewide changes or outside events. A decline isolated to one folder points toward that page type, template, topic, or customer demand.

Match the affected area to the log

Filter your log to the two to six weeks before the decline. Look for events that touched the pages or measurements that moved.

Treat timing as a clue, not proof. Two events occurring together does not establish cause. Form a testable explanation: “The new navigation removed internal links to these 12 services, and those pages lost impressions afterward.” You can verify the links, crawl activity, indexing, and page-level performance.

Check outside events

Review the Search Status Dashboard, data anomalies, seasonality, local events, promotions, stock levels, and sales coverage.

Google recommends using Google Trends to determine whether a traffic change reflects broader search interest or only your site: Google’s guide to getting started with Google Trends. If demand for “furnace repair” drops every spring, your March-to-April decline may be normal even when the website is healthy.

Reverse only when the evidence supports it

Do not roll back five releases at once. You will not know which action worked, and you may remove improvements that had nothing to do with the problem.

Fix clear failures immediately, such as accidental noindex tags, broken tracking, dead forms, bad redirects, or server errors. For uncertain cases, change one meaningful variable, document it, and monitor the affected metric.

Add Annotations Where Your Team Already Looks

The spreadsheet is the permanent record. Annotations make important dates visible on the chart.

Google Analytics supports annotations in reports with line graphs and through its Admin API. An annotation can cover one date or a date range, include a title and description, and use colors to distinguish events: Google Analytics annotation documentation.

Add annotations for major launches, tracking changes, migrations, outages, promotions, and confirmed update windows. Keep the full details in your change log and paste its link into the annotation when possible.

Do not create 40 chart markers for minor edits. Annotations should explain the chart at a glance. The log can carry the detail.

Assign One Owner and a Weekly Routine

Shared responsibility often means no responsibility. Give one person ownership of the log, even if several people submit changes.

Use a short Friday routine:

  1. Review completed website, content, tracking, and campaign work.
  2. Add missing rows and links, then create annotations for major events.
  3. Check that every meaningful change has an expected result and review date.
  4. Revisit rows due for evaluation and record the outcome.
  5. Send unresolved negative results to the person who owns the affected system.

This is not an SEO-only document. Developers, marketers, sales managers, outside agencies, and owners all create events that can move website results. Give each vendor a simple rule: no material production change is complete until it appears in the log.

Start Before You Need It

You cannot reconstruct six months of undocumented releases with confidence during a traffic emergency. Start the log now.

Backfill only the large events you can verify: redesigns, migrations, domain changes, analytics replacements, major content launches, outages, and known Google updates. Then maintain it weekly.

The payoff arrives when a number moves. Instead of asking, “What did Google do to us?” you can identify what changed, which pages were touched, which measurement failed, and what evidence to test next.

If your website changes keep turning into expensive detective work, get started with Your Web Team. We can help you put a measurable release and reporting process in place.