# XML, News, RSS, and HTML sitemaps

Configure sitemap ownership, eligible content, media discovery, and the HTML sitemap shortcode.

Configure sitemap ownership, eligible content, media discovery, and the HTML sitemap shortcode.

## How it works

The default sitemap index is `/sitemap.xml`; the base slug is configurable. Internal child files contain no more than 2,000 URLs and are numbered when a provider needs multiple files. Post-type children use `{base}-posts-{post-type}-{page}.xml` and taxonomy children use `{base}-taxonomies-{taxonomy}-{page}.xml`. These explicit namespaces keep both providers reachable when a post type and taxonomy share a WordPress slug, and keep custom object names such as `news`, `misc`, `authors`, or `archives` separate from Cybermaps’ canonical system publications.

### Sitemap publications and index sources

| Publication or source | Content |
| --- | --- |
| Post types | Eligible entries from enabled publishable public post types; attachment rows are excluded |
| Taxonomies | Eligible terms from enabled public taxonomies, with optional empty terms |
| Authors | Public author archives when enabled |
| Archives | Date archives when enabled |
| Miscellaneous | The home page and validated additional page URLs |
| Google News | Eligible recent posts from the last 48 hours, up to 1,000 entries |
| RSS | Optional standalone RSS 2.0 publication with selectable post types and a 1–1,000 item limit |
| External references | Up to 100 unique absolute HTTP(S) sitemap URLs whose path ends in `.xml` |

Additional page entries accept up to 1,000 unique absolute HTTP(S) URLs. Both external sitemap and additional-page fields are validated locally for structure. Cybermaps does not fetch, ping, or perform a remote availability check while saving or generating the index, so a temporary remote outage cannot remove an administrator’s configured reference.

External sitemap URLs remain index references: the Static File Engine never copies or claims ownership of them. Additional page URLs are emitted in the miscellaneous child without fabricated `lastmod` or `changefreq` values.

Media discovery can be disabled, set to Standard, or set to Advanced. Standard records featured and attached images only. Advanced additionally parses inline images, direct `<video>`/`<source>` URLs, and YouTube or Vimeo references from the first 2 MiB of stored post markup, stopping each matcher at the publication budget instead of allocating every possible match. Direct video files are published as content locations; YouTube and Vimeo references are published as player/embed locations. Protocol video entries require a literal representative thumbnail: Advanced uses a `poster` attribute for direct video and YouTube’s deterministic thumbnail, and does not substitute a generic site icon when no video thumbnail is known.

The bulk media rescan refreshes saved media observations for published content in sitemap-enabled post types. Changing modes advances a constant-time audit generation; prior and legacy unmarked rows fail closed until the post is saved or rescanned instead of being synchronously deleted across the whole site. Every publication revalidates saved observations and retains at most 100 media items per post, including no more than 25 videos, so malformed legacy metadata cannot create unbounded XML or on-page schema output. Vendor media hints in the AI sitemap are controlled separately. Eligible singular content can also publish `VideoObject` JSON-LD when an observed video has the required public URL, thumbnail, title, upload date, and page URL.

### Content Discovery Strategy and per-resource controls

Content Discovery Strategy starts with a publishing profile suited to common real-world WordPress structures: news, editorial, store, documentation, portfolio/agency, local/service business, or mixed company content. **Suggest from site structure** can recommend one from public content types and published-item counts. It does not read the site’s content or infer its business goals. The suggestion is shown first and changes nothing until the administrator explicitly applies it. A profile is a starting baseline, not a business classification or content-quality score.

Explicit product/download, documentation, portfolio/project, service, and news/press post types are the strongest profile signals. Without one of those, a post-led inventory suggests Blog / Editorial, or News / Magazine when it has more than 1,000 published Posts. Non-editorial inventories below 50 items use the Local / Service Business starting point; other mixed structures use Company / Mixed Content.

Each post-type or taxonomy row has three independent decisions. The interface keeps explanations beside the relevant labels through mouse- and keyboard-accessible help tips:

*   **Publish** controls global eligibility for Cybermaps sitemap and AI URL inventories. Turning a group off does not add `noindex`, hide, or delete its content. Disabled groups are filtered before bounded XML, RSS, HTML, LLMS, search, AI-sitemap, chunk, and Knowledge Graph inventory work.
*   **Discovery intent** publishes either **Informational** or **Commercial** metadata in AI representations that support it. Commercial covers purchase, booking, contact, registration, download, and similar conversion-oriented content. Its persisted protocol value remains `transactional` for backward compatibility. Explicit row and per-resource values override the profile baseline.
*   **Publication weight** stores a positive `0.1`–`1.0` publishing hint. Higher weights place a group earlier in the sitemap index, and the value is emitted with its URLs in XML and AI sitemap output. It is not a ranking score or crawl guarantee.

The XML Sitemaps workspace groups related controls into Content Scope, Sitemap Paths & Delivery, Media Discovery, News/Feeds/Notifications, and Language & Translation sections. Primary language and WPML/Polylang relationship controls are kept together; external pages belong to content scope, while external sitemap files belong to sitemap-index configuration.

Publication status is stored separately from positive weight, so disabling and re-enabling a group retains its tuned weight. Historical zero-weight exclusions are migrated into the independent disabled map. Profile changes update inherited rows while preserving rows marked Custom; row-level and global reset actions return them to the selected profile.

Post-type and taxonomy rows use explicit kind-aware identities, so a post type and taxonomy with the same WordPress slug retain independent weight, status, and intent controls. The WordPress `post_format` taxonomy is labelled **Post Formats** and described as archive groupings such as image, video, quote, and link—not as a Cybermaps output-format selector. Legacy raw-slug settings remain readable and are canonicalized on save. Individual resources can separately override sitemap priority and change frequency or be excluded from sitemap and AI publication.

Global controls cover post types, taxonomies, post IDs, category slugs, the home page, author archives, date archives, and empty term archives. A sitemap exclusion changes Cybermaps publication; it does not add a `noindex` directive.

### Dynamic delivery, redirects, and caching

Dynamic sitemap responses support:

*   browser-friendly XSL;
*   ETag-based `304 Not Modified` responses;
*   optional 12-hour WordPress transient or object-cache entries;
*   automatic invalidation after relevant content or setting changes;
*   optional post or page modified-time updates when a comment is approved;
*   optional redirects from WordPress core and legacy sitemap locations; and
*   configurable sitemap, News, and RSS base slugs.

The index footer identifies Cybermaps as the generator and states that the sitemap helps search-engine indexing.

### Headless and media-CDN URL rewriting

`frontend_base_url` replaces the WordPress origin in published content URLs for a headless frontend. When enabled, `cdn_base_url` replaces the origin only for same-site image and video URLs written into XML sitemap entries. It does not move XSL, discovery publications, or generated files.

### HTML sitemap shortcode

`[cybermap]` builds a front-end HTML sitemap. Its builder and runtime support:

| Attribute | Default | Purpose |
| --- | --- | --- |
| `only` | empty | Select content groups with `post_type:slug` or `taxonomy:slug` tokens; `post_type:*` and `taxonomy:*` select every eligible group of that kind, and legacy unprefixed slugs remain supported |
| `exclude` | empty | Exclude item IDs, exact slugs, or slug wildcards containing `*` |
| `limit` | `50` | Maximum rendered entries, bounded to 1–500 |
| `depth` | `0` | `0` renders the full available hierarchy, `-1` is flat, and a positive value caps nesting levels |
| `sort` | `asc` | Sort direction |
| `nofollow` | `false` | Add `nofollow` to generated links |
| `display_title` | `true` | Show section titles |
| `layout` | `list` | `list`, `columns`, or `bare` presentation |

The combined post-type query and each selected taxonomy use bounded batches and inspect at most 5,000 candidates. Exclusions and shared publication eligibility are applied before the rendered-entry limit. The `bare` layout is intentionally flat; `depth` controls the hierarchical `list` and `columns` layouts. Namespaced `only` tokens keep a post type and taxonomy independently selectable when they share the same WordPress slug. Kind wildcards select all groups of the requested kind and are still narrowed by the saved Publish state and shared eligibility. Unprefixed tokens retain the historical post-type-first resolution order. The `only` and `exclude` lists are also byte- and item-bounded before they influence queries.