Stop a planned URL that is already live
Match normalized planned paths against the pages retrieved from the target site and keep the conflicting live URL attached to the decision.
Pre-publish live-site collision checkAvailable now
Your next page may already exist.
A page can look unique inside a spreadsheet and still collide with a URL or body already live. Existing Site Guard checks the pages it can retrieve before the new batch reaches publishing.
The pSEO Guard differenceQuality before volume. Evidence after publish.
Keep the plan, approval, publishing result, and next decision connected to the same URL.
What changes
Protect the pages that already earned their place
A clean page matrix only proves that the proposed rows differ from each other. The live site is the evidence for whether a planned URL, title, or body is already owned by another page.
Review a title another page already owns
Surface exact title collisions before two pages are asked to make the same promise in search results.
Catch a new page that repeats live content
Compare supplied page-plan content with the main text retrieved from live pages and flag close copies before publishing.
Know what the scan did not see
Keep the scan time, target site, discovery method, retrieved pages, skipped pages, robots exclusions, and Fresh, Stale, or Not measured state visible.
The failure modes
A new batch can damage pages that are already working
The page plan does not know what the website has accumulated through older campaigns, manual publishing, redirects, or CMS changes. That missing context is where avoidable collisions begin.
A planned path already resolves to a live page
Creating another object for the same path risks overwriting, redirect confusion, or a publishing failure that should have been caught before the CMS step.
Two pages make the same promise
A repeated title is a reason to review whether the planned page needs a distinct job, a merge, or no new URL at all.
A new template repeats an existing page
Different slugs do not make repeated body content useful. Compare the actual main text before another near-duplicate joins the site.
A partial crawl looks like a clean result
Retrieved, skipped, blocked, and undiscovered pages stay separate so missing evidence is never presented as a pass.
How it works
Compare the plan with the site before approving either
Existing Site Guard uses the same planned-page records and the same page-level decisions as the audit. The live scan adds evidence; it does not create a second review system.
- Plan
Audit the proposed page set
Import the URLs, titles, hierarchy, declared intent, and body content that define what the new batch is meant to publish.
- Target
Name the site that already owns the space
Enter the public target origin so the scan stays bound to the site the plan is intended to change.
- Scan
Retrieve a bounded set of live pages
Use sitemap discovery when available, fall back honestly when it is not, respect robots rules, and report the coverage that was actually retrieved.
- Decide
Review collisions with both pages in view
Fix the planned URL, differentiate the page, merge the intent, or skip the new page before the publishing queue is created.
Questions
What buyers usually need to know
What does Existing Site Guard compare?
It compares planned URLs, titles, and supplied body content with the live pages retrieved from the target site. Existing URL and close body collisions can block a row; title overlap requires review.
Does a clean result mean the whole site was checked?
Only when the coverage says so. The result shows how pages were discovered, how many were retrieved, what was not scanned, and what robots rules excluded. Missing coverage remains visible rather than becoming a pass.
Can it detect keyword cannibalization from live pages?
A public page does not normally declare the target query it was created for, so target-intent collision remains Not measured unless a real source provides that field. URL, title, and body-content comparisons still run on the evidence retrieved.
Does the scan write anything to the target site?
No. Existing Site Guard reads public robots, sitemap, and page responses within a bounded request budget. WordPress writes remain a separate, authenticated publishing workflow.
Quality before volume
Check a page planCheck the live site before adding another URL
Run the page-plan audit, name the target site, and keep every collision tied to the planned page that needs a decision.