Build a Crawl Map That Reflects the Public Site, Not Every URL WordPress Can Generate
Aegisify SEO 2.9.4 manages the XML sitemap index, dedicated homepage map, post-type and taxonomy child maps, image and supported video metadata, rolling news coverage, HTML sitemap, robots.txt announcement, Search + AI crawler policy, health checks, route repair, and coordination with separate AI discovery files.
XMLImagesNewsAI Map
From Public Content to Verifiable Sitemap Endpoints
Aegisify separates inclusion, indexability, sitemap generation, robots announcement, search-engine submission, and AI discovery so each layer can be checked independently.
Click a stage to expand
01Selectpublic content
02Filterindexable + canonical
03Partitionindex + children
04Enrichmedia + news
05Announcerobots + console
06Verifyhealth + repair
Scale WordPress Discovery Without Building One Unbounded XML File
The sitemap index is the directory; child sitemaps carry the actual URL inventory for supported public content.
When enabled, Aegisify serves /sitemap_index.xml and creates child endpoints for included post types and taxonomies. The child-map size is configurable from 500 to 5,000 URLs. This keeps the sitemap structure practical as the site grows while still giving crawlers a clear entry point.
Aegisify also creates a dedicated /sitemap-home.xml containing the canonical homepage. That newer design prevents the static front page from being duplicated across ordinary child sitemaps and the homepage discovery path. It is a small implementation detail with an important SEO purpose: one canonical home URL should not be represented as multiple sitemap identities.
Include the Public Assets That Help Crawlers Understand the Page
Aegisify adds media or vertical sitemap data only when it can produce valid, supported metadata.
Featured, Inline, Attached & Commerce
XML output can include featured images, inline content images, supported WooCommerce gallery/commerce images, and optionally images attached to public content. This improves media discovery without turning the entire Media Library into a separate index target.
Supported Local + YouTube Entries
Video sitemap entries are added only for supported local or YouTube video evidence with the required title, description, and thumbnail data. The retired standalone video-sitemap endpoint is not brought back; video data is integrated into the current sitemap model.
Rolling 48-Hour News Sitemap
Sites that publish eligible news content can enable /news-sitemap.xml, focused on the recent 48-hour publishing window rather than using a permanent archive of every historical post as news inventory.
Keep Conflicting URLs Out of the Discovery Map
A sitemap becomes weaker when it advertises URLs that the same site says should not be indexed or should canonicalize somewhere else.
Exclude Deliberately Non-Indexable Content
Aegisify respects central indexing policy and content-level noindex state when building sitemap candidates. Sensitive-data detection itself does not remove public URLs; indexability policy remains a separate, explicit control.
Prefer Self-Canonical Sitemap URLs
URLs that intentionally canonicalize elsewhere are not treated as preferred sitemap entries. This keeps sitemap discovery aligned with canonical intent instead of publishing two different preferred destinations.
Preserve Legitimate Archive Pages
Current canonical integrity logic distinguishes valid archive pagination from duplicate static-home pagination. The sitemap and canonical systems are designed to avoid collapsing legitimate page-two archives back to the homepage.
Expose Change Context
Supported sitemap entries carry last-modified information so crawlers have a update signal. It helps discovery systems prioritize work but does not force recrawl timing.
Use One Discovery Policy Instead of Contradictory Robots Rules
The Sitemap tab can coordinate sitemap announcement and a public-content crawler policy through WordPress robots.txt.
Add Sitemap to robots.txt publishes the sitemap location so crawlers can discover the XML index without relying on an external submission alone. Search + AI Crawler Access adds a universal wildcard policy designed to let standards-compliant search and AI crawlers reach public content while blocking sensitive WordPress/application paths.
This newer policy also removes legacy blanket patterns that could unintentionally block public REST or WordPress resource paths. It does not guarantee that Googlebot, Bingbot, OAI-SearchBot, GPTBot, Claude-related crawlers, or another crawler will visit or use the content. Configurations provides the provider-specific readiness check when administrators need to see how actual crawler identities interact with the policy.
Keep AI Discovery Connected to the Sitemap Without Confusing It With Standard XML
Aegisify SEO’s AI discovery system creates additional public artifacts when AI SEO discovery is active.
The AI SEO module can generate /llms.txt, /llm.txt, /ai.txt, /ai-index.json, and /sitemap-ai.xml. These files give machines additional structured discovery references and point back to the site’s public URL inventory. The standard XML sitemap remains the conventional search-discovery mechanism; the AI sitemap is a separate Aegisify discovery artifact.
AI discovery files update on their own schedule and are evaluated by the Configurations tab as part of OpenAI/Anthropic/search-AI readiness. Their presence does not guarantee an AI system will crawl, cite, summarize, or include the site. Their value is clarity: the site can expose a consistent machine-readable inventory rather than relying on hidden prompts or undocumented hacks.
Verify the XML That Crawlers Actually Receive
A sitemap setting is not healthy if the public route returns the theme, a redirect loop, invalid XML, or another plugin’s competing sitemap.
Aegisify protects its sitemap endpoints from the Redirect Manager, supports direct request-path routing when rewrite rules are stale, validates generated XML before returning it, uses the expected XML content type and nosniff behavior, and rejects invalid cached output. Repair Routes & Run Health Check flushes sitemap routes, invalidates the sitemap cache generation, and tests the public endpoints.
The Sitemap tab also detects whether WordPress core or known SEO providers are producing another sitemap. When the Aegisify sitemap is enabled, Aegisify disables WordPress core sitemaps to avoid maintaining two competing native sitemap inventories. Other plugin conflicts are surfaced for administrator review rather than silently overwritten.
Discovery Is a Workflow, Not a Ping Button
Aegisify 2.9.4 retains the old ping method only as a compatibility stub; unauthenticated Google/Bing sitemap ping endpoints are retired.
Publish One Clear Sitemap Architecture and Verify It Publicly
Control what belongs in the crawl map, keep robots and canonical signals aligned, and use Search Console and IndexNow for the notification workflows they actually support.
Common Questions About Aegisify Sitemap 2.9.4
Does submitting a sitemap guarantee indexing?
No. A sitemap helps search engines discover preferred URLs and metadata. Crawling, indexing, canonical selection, and ranking remain search-engine decisions.
Why is there a separate homepage sitemap?
Aegisify uses a dedicated one-URL homepage map so a static front page is not duplicated across ordinary child sitemaps and the site’s primary homepage discovery path.
Did Aegisify remove video sitemap support?
The retired standalone video-sitemap endpoint is not restored. The current Sitemap tab can add valid supported video entries to the sitemap system when required metadata exists.
Are AI discovery files a replacement for XML sitemaps?
No. Standard XML sitemaps remain the conventional search-discovery mechanism. Aegisify’s AI discovery files are separate machine-readable artifacts for additional AI/search discovery readiness.
How can Aegisify AI help?
Ask about Aegisify or WordPress: errors, plugins, security, SEO, compatibility, troubleshooting, comparisons, or launch a free website scan.