How to Create a WordPress URL Inventory with AI

A URL inventory is the factual backbone of most WordPress SEO and migration work. AI can normalize exports and classify patterns, but it cannot infer a complete site from the first page of an API response or a sitemap alone. Build the inventory from multiple named sources and preserve disagreements.

SEO analysis is only as reliable as the supplied evidence. A language model does not independently know crawl status, indexation, rankings, canonical selection or page performance. Treat it as an evidence organizer and hypothesis generator, then verify every finding in the appropriate source system.

In one sentence: Create one stable row per discovered URL, retain every source that reported it and mark conflicts instead of silently choosing a value.

What this guide helps you accomplish

The output should provide a traceable view of public, private, redirected and missing URLs, with WordPress IDs where available. It should support later audits without pretending that one data source represents the entire site.

A useful result is not merely a polished answer. It must show which records or pages were examined, which evidence was unavailable, what the assistant inferred, what a human must decide and what actions remain prohibited.

What a successful output should contain

• One normalized URL record with all observed source variants.
• WordPress content ID, type, status, language and dates where available.
• HTTP, canonical, sitemap and indexation-policy evidence where supplied.
• Source-presence flags showing where each URL was discovered.
• Conflict and missing-data fields.
• A clearly defined inventory scope and extraction date.

Evidence and inputs to prepare

WordPress, sitemaps, crawlers and analytics systems answer different questions. Join them without erasing the differences.

• Complete paginated WordPress post, page and custom-post-type exports.
• All XML sitemaps and sitemap indexes.
• A crawl export with final URL, status and canonical fields.
• Redirect map or server data when available.
• Search Console and analytics page exports when relevant.
• Locale, site section and content-owner mappings.
• URL normalization rules approved for the project.

Record the date, source, scope and known omissions for every input. Remove credentials, personal information and customer data that are not required for the task.

Keep discovery sources as separate evidence

A URL in WordPress but absent from the sitemap is not automatically an error. A URL in analytics but absent from WordPress may be redirected, external, historical or generated. Preserve flags such as in_wordpress, in_sitemap, in_crawl and in_search_data before interpreting them.

Normalize without hiding differences

Case, trailing slash, protocol, host and query normalization can prevent duplicate counting. Keep both the raw value and the normalized key so reviewers can inspect what was changed. Do not strip parameters until their function is known.

A safe workflow

1. Declare included hosts, protocols, locales and content types.
2. Export every source with dates and pagination evidence.
3. Store raw URLs before applying normalization rules.
4. Create a normalized URL key and source-presence flags.
5. Join WordPress IDs, statuses, HTTP results, canonicals and sitemap evidence.
6. Ask the assistant to classify conflicts and missing fields.
7. Review high-impact discrepancies manually.
8. Freeze the inventory snapshot for downstream work.
9. Create separate tasks for redirects, canonicals or content changes.

The workflow intentionally separates analysis from implementation. A later change stage should reference the approved output rather than quietly expanding the permissions of the analytical identity.

Prompt recipe

Before using this prompt, replace every value in square brackets. Do not paste passwords, API keys, private customer records or unrelated personal information into the instruction.

Build a normalized WordPress URL inventory from the supplied source files.

Return one row per normalized URL with:
- Normalized URL and all raw variants
- Host, path, query and locale
- WordPress ID, content type and status
- Publication and modification dates
- Present in WordPress, sitemap, crawl, Search Console, analytics and redirect map
- HTTP status and final URL when supplied
- Declared canonical when supplied
- Conflict class and missing evidence
- Review priority and rationale

Rules:
1. Do not assume any one source is complete.
2. Preserve raw values and source dates.
3. Do not strip parameters without an approved rule.
4. Do not invent HTTP, canonical or indexation data.
5. Do not change WordPress, redirects or sitemaps.

Why this prompt is structured this way

The source-presence model creates an auditable join instead of a flat spreadsheet that hides contradictions. Raw variants and normalized keys allow deduplication to be challenged.

Recommended access boundary

Use a Read Only identity. The assistant may inspect the WordPress records included in scope, but attempts to create, edit, delete or publish content should be refused.

The recommended workflow is low risk when the source data is scoped and no write permission is granted. Low risk does not mean zero review.

What must remain outside this task

• No redirects, canonicals, noindex changes or deletions.
• No claim that sitemap absence means deindexation.
• No assumption that API pagination is complete without evidence.
• No removal of query parameters before their role is known.
• No inferred HTTP status or final URL.

The access level is a starting recommendation, not a universal entitlement. The exact capabilities available to an identity must come from the installed product version and its published coverage.

How WP Agent Control fits

This is a general WordPress workflow, not a promise that Agent Control can edit every object or integration discussed here. For the guided path, start with public pages; plugin, theme, user, setting, file, deletion, WooCommerce, ACF and builder operations are not native guided tasks. Use separately qualified tools and permissions where required.

Get structured site information and inspect selected published pages after connecting. No temporary task is needed for this public reading. You can also browse public pages without the plugin; Agent Control adds structured access and a path toward authorized WordPress work.

Connect your AI: docs first profile · See features and compatibility: coverage

Verification checklist

• ☐ Every source has a date and scope.
• ☐ Pagination completion is documented.
• ☐ Raw and normalized URL values are both retained.
• ☐ Source conflicts remain visible.
• ☐ WordPress IDs are preserved where available.
• ☐ No URL state changed during inventory creation.

Common failure modes

• Sitemap equals site: The inventory excludes valid URLs not listed in the sitemap.
• First-page API export: Pagination is missed and the result is falsely called complete.
• Destructive normalization: Parameters or path differences are discarded before review.
• Conflict erasure: One source silently overwrites another.

Advanced note

Use immutable inventory snapshots with stable URL IDs. Later crawls and migration maps can reference the same identity, allowing the team to observe state transitions without rewriting historical evidence.

Related guides

• How to Inventory WordPress Content with AI
• How to Run a Read-Only WordPress SEO Audit with AI
• How to Find Orphaned WordPress Pages with AI
• How to Find Duplicate or Overlapping WordPress Content with AI

Next step

Use the frozen inventory for orphan analysis, overlap review and the broader SEO audit.