--- title: "Check what a site change actually changed" url: "https://yanivgoldenberg.com/ai-agents/search-change-qa/" language: en description: "Search change QA for URLs, rendered content and customer paths. Yaniv personally builds the checks, investigates exceptions and tests agreed repairs." lastmod: "2026-10-29" --- # Check what a site change actually changed AI agents for search-change QA Check what a site change actually changed A redirect report passes, but a product page now points to the wrong canonical. The page responds, but its buying information or contact path is missing. I build agent-assisted review workflows that compare the agreed site versions, explain the exceptions and leave a clear repair or release decision. I personally design, implement and test the work within your project scope. [Discuss your workflow](https://yanivgoldenberg.com/contact/) Make the next site decision with the evidence beside it This workflow is for a team making repeated content, template, URL or platform changes. The useful output is a change-specific review: what was checked, what differs from the accepted expectation, who must resolve it and which repair was retested. It can support a migration, but also a smaller release that changes a shared template or language relationship. Choose the work the change needs | Situation | What I build | Decision it supports | | Repeated template releases | A repeatable comparison with affected-page coverage and a review queue | Accept the tested change or name the unresolved defect | | A URL or CMS move | Checks against the approved mapping, content and customer journeys | Repair, hold or release with a named owner | | A disputed crawler finding | A source-bound comparison of response, rendered page and expectation | Confirm a defect, accept an intentional change or keep it unresolved | For the broader implementation mandate, see [technical SEO](https://yanivgoldenberg.com/seo/technical-seo/) or [site migration work](https://yanivgoldenberg.com/seo/site-migration/). This workflow organises repeated change review; it does not replace the project’s architecture, content or release ownership. For deciding which existing answer to improve or whether a new brief is justified, use [search opportunity and visibility review](https://yanivgoldenberg.com/ai-agents/search-opportunity-review/). It maps observed questions to buyer intent and the current library. This change-QA workflow checks the specific accepted candidate and repairs; neither a query report nor a source-only check is public release proof. Keep exact checks exact; use interpretation for the disputed finding Status codes, expected destinations and required fields can usually be compared with rules. An agent can help explain a changed page, relate a finding to the approved change or prepare a repair task with its source. It should not invent a replacement URL, accept a missing crawl result as a pass or decide that every content difference is a defect. I first compare the ordinary checks with an agent-assisted review. Where interpretation earns its cost, the output names the source version, observed difference, expected behaviour and proposed next step. Your release owner accepts the expectations and any intentional exceptions. Website content is material to inspect, not authority to change the workflow’s instructions. Worked example: a language page moves, but its destination is wrong Illustrative scenario, not an executed customer test: a Hebrew product page moves to a new path while its English counterpart stays in place. The approved mapping names the Hebrew destination and language relationship. The candidate returns a page, but the old URL redirects to a category and the new product page names an unrelated canonical. What the review should record | Observation | Useful finding | Next action | | Old product URL reaches a category | Destination differs from the approved product mapping | Check the mapping and implement an authorised redirect repair | | New page has the wrong canonical | Observed metadata conflicts with the accepted page identity | Repair and reread the actual candidate page | | Rendered buying details are absent | A response code did not establish content preservation | Inspect the template and retest the missing information | | The inquiry path cannot be tested | Customer-path acceptance is still missing | Keep that check open with its owner; do not infer success | The agent prepares the explanation and linked evidence. I investigate and implement the agreed repairs, then rerun the affected checks. A release recommendation refers to the repaired version and remaining exceptions. Deployment and the later public readback are separate steps under the assigned release authority. Sample version-by-version release review Illustrative specimen. All example records, product details, messages and amounts below are invented for this demonstration. This is not client work, a live integration or a measured result. This fictional review concerns a moved Hebrew product page and its English counterpart. R1, R2 and R3 are example version labels, not this website's releases or actual crawl results. | Check | Baseline R1 | Candidate R2 | Repaired candidate R3 and next decision | | Old product destination | Accepted Hebrew product mapping recorded. | The old path redirects to a category instead. | Repair the redirect and reread the complete chain against the approved product destination. | | New-page canonical | The product identity and expected canonical are recorded. | The product page names an unrelated canonical. | Retest the actual R3 page for the accepted self canonical. | | Language relationship | The Hebrew and English pair is named. | The selected alternate points to an unrelated page. | Reread both intended pages and their reciprocal language relationship; a source edit alone is insufficient. | | Buying information | Required product facts are captured. | A response exists, but required information is missing. | Compare the repaired rendered content with the agreed facts. | | Inquiry journey | The agreed contact path is named. | The interaction check could not be completed. | Still unresolved. The release owner names the missing check and decides whether the candidate can proceed. | | Public follow-up | An accepted recovery reference is retained. | Not released in this illustration. | After an authorized deployment, identify the actual public version and repeat the affected checks. | Review decision: the release owner receives the tested version, repaired findings and the unresolved inquiry-path check. Passing selected redirect or metadata checks does not close that missing interaction, prove public deployment or establish indexing and revenue gains. The review follows a named version from baseline to readback 1. Agree the affected URLs, shared-template reach, language pairs and important customer paths. Record any scope that cannot be covered. 2. Capture the permitted baseline and candidate evidence, with version, environment and time. Compare responses and redirect chains separately from rendered content and interaction checks. 3. Classify findings as confirmed defects, accepted intentional changes or unresolved cases. Keep each observation attached to the expectation it tests. 4. Personally implement the authorised fixes and retest their affected pages and sibling paths. A changed candidate requires a new check of the relevant evidence. 5. Give the release owner the tested version, exceptions, recovery reference and recommendation. Check the selected public version after release where that follow-up is in scope. The team receives the URL population, comparison results, issue queue, repair receipts and operating instructions. If you only need a focused investigation, I can personally perform it read-only. A later build or continuing review service is agreed explicitly. When evidence is missing, the decision stays open An unavailable page, incomplete export or rendering failure is not evidence that the change passed. I build the agreed handling for those cases, including who receives the exception and when a rerun is appropriate. A repaired source file is not a receipt for the version a customer sees. Recovery begins by identifying the actual version and the affected action. Retain the baseline and approved recovery point; do not overwrite a later valid change with a blind rollback. I document the stop, repair and escalation procedure and test the agreed failure cases. The release owner decides whether to deploy or recover. Measure review work before claiming a search benefit Record the selected URL and journey population, checked coverage, confirmed defects, unresolved findings and time spent reviewing and correcting them. After the pilot, use the same definitions and include false alarms, maintenance and the receiving team’s effort. A lower scan duration alone does not establish a useful workflow. Acceptance means that the agreed checks have evidence and unresolved cases have owners. Indexing, rankings, qualified inquiries and revenue require their own sources and observation windows. I do not promise zero traffic loss or a fixed ranking result. Google’s [site-move guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) covers mapping, testing and monitoring. It is a reference for relevant checks, not evidence that a particular release is correct. Build once for a defined review, or keep me operating it I’m Yaniv Goldenberg, Fractional CMO & Head of Growth. I lead the strategy and personally build the agreed connections, comparisons, exception handling and repair work. We choose the tools after checking your workspace, CMS, permitted evidence and release process; a specific integration is confirmed before it becomes a commitment. Scope, time commitment, delivery milestones, fees, source access and the receiving owner are agreed per client or project. You can receive a documented build, include my continuing review or combine them. Separate Advisory is the advice-only option. Bring one change you need to assess, its expected behaviour and the people responsible for implementation and release. We can use a redacted example to define the first useful review. Questions before the build Do you personally build the workflow and fix findings? Yes. I personally design, build and test the workflow in the agreed scope. I investigate findings and implement the repairs included in that mandate. A focused read-only investigation does not automatically include a later build; we define that work and its dependencies separately. How is this different from an SEO crawler? A crawler supplies observations. This workflow connects the selected change and accepted expectations to response, rendered-content and customer-path evidence, then routes disputed findings and retests approved repairs. Rules remain useful for exact checks; an agent is used where interpretation adds value. Does it replace a migration or technical SEO project? No. It is a recurring change-review workflow that can support those projects. URL mapping decisions, architecture, implementation and release authority must still have owners. The broader migration or technical SEO scope can be agreed with me separately. Can an agent approve a release or rewrite redirects on its own? Actions follow the agreed permissions. The workflow can prepare findings and a recommendation; fixes and deployment require the assigned authority. Routine checks may run automatically without granting open-ended source or production access. What happens if a crawl or render is incomplete? The affected checks remain unresolved with a named owner and the missing evidence recorded. I implement the agreed rerun and exception procedure; an unavailable page is not marked passed. A source repair must be retested against the relevant version. Does passing the checks guarantee rankings or prevent traffic loss? No. The checks establish bounded evidence about the tested change. Search processing and commercial outcomes are later observations. We agree the relevant monitoring and review horizon separately. Personal strategy and execution Bring one site change that needs a clear decision Share the change, the expected customer path and the evidence you can provide. We will define what I personally build or investigate, which repairs are included and who accepts the release. [Scope your project](https://yanivgoldenberg.com/contact/) Related work [AI-agent build and operation](https://yanivgoldenberg.com/ai-agents/) [Technical SEO implementation](https://yanivgoldenberg.com/seo/technical-seo/) [Site migration](https://yanivgoldenberg.com/seo/site-migration/) [Funnel analytics workflow](https://yanivgoldenberg.com/ai-agents/full-funnel-analytics/) [עברית](https://yanivgoldenberg.com/he/ai-agents/search-change-qa/)