A snapshot is a saved copy of a page at one observation time. A change log is a record that links two snapshots and explains the difference. These records let you replace “I think this changed last week” with a statement that another reader can check.
The supplied public discussion, observed October 25, 2026; personal context only describes manual page checks, screenshots, and difficulty remembering earlier wording. That concern shapes this method. Keep the old evidence, make the next check comparable, and separate what changed in the text from what remains unknown about the product.
1. Choose one buyer task and a small page set
Start with a buyer task: the work someone needs the product to do. For example, a researcher might need to check which export formats the documentation names for a reporting workflow. Keep the question narrow enough to review the full relevant passages.
Write a short collection plan before saving pages:
- Name the competitors and products you will check.
- State the buyer task in one sentence.
- Choose the official documentation sections that could answer it.
- Record the product version, language, and plan when the page states them.
- Choose your next observation date.
- State which changes would affect the buyer task.
Do not treat an unknown plan or version as “all plans” or “all versions.” Record it as unknown. Keep help pages and release notes separate when they make different kinds of statements.
Use a page register to define your selected pages. This is your list of pages to check again. It is not a claim that you have found all relevant documentation.
| Page register field | What to save |
|---|---|
| Page reference | Your own stable reference for the selected page |
| Competitor and product | The exact product under review |
| Buyer task | The work that makes this page relevant |
| Official-source basis | Why you accept the page as official |
| Requested URL | The address you opened |
| Final URL | The address reached after any redirect |
| Page title and section | The exact comparison location |
| Scope | Stated version, plan, language, and conditions |
| Next check | Your planned observation date |
A redirect sends a request from one address to another. Record both addresses. A changed address can affect whether two saves represent the same page.
2. Use search to find pages, then check them directly
If you already know the official help page, open it directly. Search is useful when you need to find candidate pages or check for related release notes. Search results alone cannot supply the saved page history.
The Google Search Scraper Actor fits this discovery step. An Actor is a hosted data collection program. A Task is a saved input preset for an Actor. Neither term means that this guide has collected page versions or tested the product.
The supplied check found that public default build 1.0.15 declares the input and output fields used below. The small input passed a static check against the declared input rules. No Actor run occurred for this brief. The check does not prove live results, complete coverage, or successful collection. See the public default-build evidence, checked October 25, 2026; declared fields and static input check only.
Use this proposed input for a small discovery attempt:
{"country":"US","engines":["google"],"language":"en","maxResultsPerExecutedQuery":3,"queries":["reporting software export release notes"]}Replace the sample query with words for your selected competitor, product, and buyer task. Replace the country and language when your research requires another market. Review the full input before running it. This example proposes Google as the engine; the static check does not establish its current runtime behavior.
The result limit is three results per executed query. It is a limit, not a promise that three results will be available. This sample is a proposed replacement input. It was not copied from a verified saved Task configuration.
The public Competitor SERP Research Task, checked October 25, 2026; page presence only was present with exact Task ID `Pjq0JLkzo0wHTcabU`. Its saved settings and runtime behavior remain unverified. Open it as a starting point and inspect its settings before use.
Keep these declared search fields if you collect results:
| Search field | Use and limit |
|---|---|
| `engine` | Records the search engine |
| `executedQuery` | Records the executed query |
| `observedAt` | Records the search observation time, not the page-save time |
| `rank` | Running position among supported result blocks parsed across fetched pages |
| `title` | Search result title; check the actual page title separately |
| `canonicalUrl` | Returned normalized candidate address, not proof of the page's HTML canonical address |
| `resultDomain` | Helps review the candidate domain; does not alone establish official status |
| `snippet` | Search text that can be missing; not saved page text |
| `isSponsored` | Records whether the result is marked sponsored |
A snippet is a short passage supplied in a search result. Open the page before using its wording as evidence. The guide to checked page evidence explains that handoff from a search result to a source passage.
Keep the saved search input with any results. If the same page appears through several queries, retain those observations. The guide to merging search exports explains how to preserve query and rank evidence. Here, the change comparison belongs to the selected page and its saved versions.
3. Confirm page identity before comparing versions
A page identity is your record of which document a save represents. An address alone may not settle that question. A page can redirect, change its language, or show documentation for a different product version.
For every later visit, check the requested address, final address, page title, section heading, and stated scope. Record changes to those values before comparing the text.
Do not silently compare an old export guide with a new general help page because one redirects to the other. Keep both saves and mark the comparison as unresolved until you establish what each page represents.
Likewise, keep different languages and product versions separate. If your research scope changes, record the change. A broader page set may be useful, but it does not create older snapshots for newly added pages.
4. Save the text and its observation time
Save the full relevant public page text each time. Also retain the exact passage around the buyer task. A screenshot can help preserve the visible layout, but keep text that you can compare and quote accurately.
Preserve conditions around the claim. A sentence about JSON export may depend on a nearby plan restriction, product version, or access requirement. Saving only the format name can remove the condition that gives it meaning.
Use one record per page observation:
| Snapshot field | What to record |
|---|---|
| Snapshot reference | Your unique reference for this save |
| Page reference | Link to the page register |
| Observation time | Date, time, and time zone when you saved the page |
| Requested and final URLs | Addresses checked for this observation |
| Access state | Whether you obtained the intended public text |
| Page title and scope | What the page actually showed |
| Full text reference | Location of your retained text copy |
| Exact relevant passage | Complete comparison passage with its conditions |
| Passage location | Heading or other locator within the page |
| Page-displayed date | Date shown on the page, or missing |
| Capture notes | Missing content or other limits |
Keep the observation time separate from a page-displayed date. Your save time shows when you observed the wording. A displayed date has only the meaning the page gives it. Neither automatically proves when a particular sentence changed.
Keep public evidence separate from your own records. The official page text is public source material. Your snapshot references, saved copies, review notes, and buyer priorities are records you maintain. The declared search fields do not establish that the Actor creates those records for you.
Do not overwrite an old save with a newer one. Without the retained old text, you cannot check the difference later.
5. Compare equivalent passages and classify the wording
Compare two accepted snapshots of the same page under the same relevant scope. Read the complete passages side by side. A text comparison can identify candidate differences, but review each difference in context.
Use separate wording classes:
| Class | What the comparison supports |
|---|---|
| Added wording | Relevant text appears in the later save and is absent from the earlier comparable passage |
| Removed wording | Relevant text appears in the earlier save and is absent from the later comparable passage |
| Changed qualification | A condition, restriction, version, or other limit changes |
| Presentation change | Layout or wording changes without a confirmed change to the relevant statement |
| Unresolved difference | Missing text or changed scope prevents a sound comparison |
Removed wording does not prove a removed feature. Added wording does not prove a newly released feature. A changed qualification may matter more to the buyer task than a newly listed format.
Record the observation interval in plain terms: “The wording differs between the October 1 and October 8 saves.” Do not replace that statement with an exact edit date that the evidence does not provide.
For each candidate difference, save a change record:
| Change record field | Purpose |
|---|---|
| Change reference | Your unique reference for the comparison |
| Page reference | Identifies the official page |
| Old and new snapshot references | Links both retained versions |
| Old and new observation times | Defines the observation interval |
| Old and new exact passages | Makes the difference checkable |
| Wording class | Separates additions, removals, and qualifications |
| Scope check | Records whether the passages are comparable |
| Buyer-task effect | Explains why the difference could matter |
| Product claim state | States what remains unverified |
| Next check | Names the evidence needed next |
6. Work through one careful example
Original fiction for teaching. This is not an Actor run, customer result, or observed company finding. All addresses, passages, dates, and records below are invented.
Imagine a researcher checks export documentation for one reporting workflow. The researcher saves the full public text of fictional page A at `https://example.com/help/exports` on October 1 and October 8, 2026. Both observations occur at 12:00:00 UTC. UTC is a standard time reference.
The page identity, language, and relevant scope match across both saves. The researcher also finds fictional page B at `https://example.com/help/report-formats` on October 8. Page B has no earlier save.
These are the complete relevant passages retained for the example:
| Page and observation | Exact fictional passage | Evidence state |
|---|---|---|
| A, October 1 at 12:00:00 UTC | “CSV export is available for reports.” | Accepted earlier passage |
| A, October 8 at 12:00:00 UTC | “CSV and JSON export are available for reports.” | Accepted later passage |
| B, October 8 at 12:00:00 UTC | “Reports can be exported as JSON.” | Current observation only; earlier text missing |
CSV and JSON are data formats. The example names them to show a wording comparison. It does not test either format.
For page A, the accepted change record says: “The export passage adds JSON wording between the October 1 and October 8 observations.” Both full page saves and both exact passages remain available for review.
For page B, the record says: “The October 8 passage documents JSON export. No earlier snapshot is available.” It does not record a second proven change.
The arithmetic keeps the units separate:
- Page A has 2 saved observations. Page B has 1 saved observation. Total: 2 + 1 = 3 saved observations.
- Page A provides 1 comparable pair. Page B provides no pair because its earlier save is missing.
- The comparable pair contains 1 observed wording change on 1 page.
- Page B contributes 1 current-only page observation. Its change status is unknown.
These counts describe pages, saves, and comparisons. They do not count customers, users, feature launches, or successful exports. The missing earlier save for page B is not evidence of zero earlier JSON wording.
The buyer-task note says that the JSON statement may affect the export review. The next step is to verify the feature under the buyer's required product scope. The record supplies no release date or usage result.
7. Keep failures and missing evidence visible
A failed check must not become a claim that wording disappeared. Use clear states so later readers can see which comparisons are valid.
| Situation | Record this state | Next action |
|---|---|---|
| No earlier snapshot | Current observation only | Start the history with this save |
| Later page cannot be accessed | Later observation unavailable | Retain the earlier save and retry |
| Save contains navigation but lacks relevant text | Capture incomplete | Obtain the intended passage before comparison |
| Redirect reaches a different document | Page identity unresolved | Review both addresses and document scope |
| Product version or language differs | Scope changed | Keep the saves separate until reviewed |
| Search returns no useful candidate | Discovery gap | Check known official sources directly |
| Relevant passages match | No wording change observed in those passages | Keep the accepted pair and its limited scope |
“No wording change observed” applies only to the checked passages and interval. It does not mean the whole product stayed unchanged.
Leave missing dates and passages marked missing. Use zero only when an accepted comparison actually supports a zero count. For example, zero accepted changes can describe a completed review. It cannot describe a review that lacked the later page text.
Keep failed observations in the history. Do not replace the last usable snapshot with an empty or incomplete save.
8. Check product evidence and write the brief
Before calling a wording change a feature launch, look for a separate official dated source that supports that claim. Release notes may help, but a nearby date alone does not establish the release date of the exact feature.
If the buyer decision requires tested capability, plan a separate check under the required product version, plan, and workflow. Mark that check as proposed until it occurs. Documented support and tested behavior are different evidence states.
Write the brief around the buyer task. State the observed wording difference first. Then give the page link, both observation times, both passage references, and the relevant scope. Explain why the wording could affect the decision. End with the unresolved question and the next evidence needed.
Review the brief before sharing it:
- Confirm that both saved versions remain available.
- Check that the passages belong to the same page and relevant scope.
- Confirm every quoted word against the retained text.
- Keep observation times separate from claimed edit or release dates.
- Keep current-only pages separate from proven wording changes.
- Remove claims about adoption, performance, or business effects that the evidence does not support.
Sources & further reading
- Public competitor-tracking discussion — observed October 25, 2026; personal wording only, not representative demand or product results
- Google Search Scraper public default build — checked October 25, 2026; build 1.0.15 declared fields and static input validation, no live run
- Competitor SERP Research Task — checked October 25, 2026; exact Task ID and page presence confirmed, saved settings and runtime unverified
By Chronometrica · Updated
Back to top ↑
