Introduction — sitemap, crawling, and indexing: why it matters
A sitemap is a file (most often in XML format) that lists a website’s URLs and helps search engines understand its structure, hierarchy, and updates. In practical terms, it influences how a site is crawled and, indirectly, how its pages are taken into account for indexing.
Often treated as a simple technical automation, the sitemap actually plays a central role. When poorly controlled, it can generate noise, weaken the coherence of freshness signals, expose unnecessary — sometimes sensitive — information, and make diagnosis more difficult in tools such as Google Search Console.
This article is a first-hand experience report, born from a real issue encountered while managing my author website. It does not aim to replace official documentation; it simply shows what happens when principles of rigor are applied in a concrete editorial context.
Why this article exists — a real editorial issue
This article was not planned.
While working on a different topic, I was confronted with a very concrete question: how to manage the sitemap of my author website. Not a minor technical detail, but a matter of editorial coherence and clarity of the signals sent to search engines.
When you publish infrequently but with intention, there is no room for approximation. Yet sitemaps are often activated once and then forgotten. I chose to turn this diagnosis into a useful piece of content — not to “do SEO,” but to explain why certain common practices become counterproductive as soon as one builds a structured editorial site.
Default WordPress sitemap: useful, but generic
WordPress automatically generates a sitemap. For many websites, this is sufficient. However, the system is designed for general-purpose use.
In an author or editorial context, its limitations quickly become apparent:
- the editorial structure is not always clearly readable (pages, posts, pillar content, secondary content);
- the site’s organizational logic is not always reflected in the signals sent;
- update information may lack nuance, creating ambiguity about the actual freshness of content.
The point is not to blame WordPress, but to recognize that a generic sitemap is not always suited to a rare, stable, and highly intentional publishing strategy.
Security: possible exposure of author-related information (configuration-dependent)
Beyond editorial limitations, there is a more serious and often underestimated risk: the unnecessary exposure of information related to author accounts.
Depending on site configuration (settings, plugins, URL structure), it may become possible to infer or expose:
- author slugs (the part of the URL identifying an author);
- author identifiers, directly or indirectly;
- the correspondence between published content and user accounts.
This information provides no value for crawling or indexing. On the other hand, it can facilitate automated attack attempts by reducing uncertainty about which account name to target.
The sitemap is only part of the issue. By default, on a WordPress site, clicking an article’s author name — in this case, myself — leads to an author archive, a page listing all content associated with that account.
The URL of this archive relies on the user slug, which corresponds to a valid login identifier and is therefore publicly exposed.
For this reason, on this site, the author archive has no standalone editorial purpose: any attempt to access it is redirected to the author presentation page. This limits unnecessary exposure and reflects a simple reality: there are not multiple voices to distinguish, but a single, clearly assumed identity.
Both a sitemap and an author archive are public. Any information they expose must be considered visible to anyone — humans and bots alike.
An important nuance: this risk depends on the site and its configuration. But in a professional context, one rule applies consistently: everything that is public must be strictly useful.
Minimal measure — separating editorial identity from user identifier
Before touching the sitemap at all, there is a minimal safeguard: separating editorial identity from the user identifier.
In WordPress account settings, the publicly displayed author name should never match the actual login identifier. Ideally, it contains spaces, which mechanically prevents it from being used as a technical username.
On this site, as with the publication of my isekai saga L’Héritier de l’Autre Monde, I chose to appear under my real name, “Jean-Louis Vill.” I am both the author of the articles and the site owner: my editorial identity is public, while my user identifier remains distinct and never exposed.
This separation serves two clear purposes:
- explicitly identifying who writes and speaks;
- reducing the exposure of exploitable information, both in public display and, indirectly, through technical mechanisms such as the sitemap.
This does not replace sound sitemap management, but it is a minimal safeguard that would be imprudent to leave open.
The real SEO issue: signal, freshness, and noise in the sitemap
A sitemap is an instruction. It helps search engines decide what to crawl, when, and with what implicit priority. The problem begins when the sitemap claims, without justification, that “everything is constantly changing.”
Common examples of noise — that is, useless or misleading signals — include:
- dates modified for minor corrections that do not change the actual content;
- automatic regenerations triggered by purely technical actions;
- lastmod variations with no correlation to a real editorial update.
Search engines have long indicated that modification dates should reflect genuine content changes. Otherwise, crawling is not improved — it becomes less reliable. From a diagnostic standpoint, this also complicates analysis in Google Search Console, because it becomes difficult to distinguish meaningful changes from artificial ones.
The issue is not sending too few signals, but sending incoherent signals.
Simplified example
“Noisy” sitemap
- an unchanged page appears as modified;
- the date changes on every regeneration;
- the freshness signal becomes misleading.
Clean sitemap
- the date remains stable as long as the content does not change;
- an update appears only when a real editorial change occurs;
- crawling focuses on what truly matters.
Why I did not modify existing articles
My published articles have a history, a context, and an intention. I did not want to republish them or alter their metadata to provoke a technical effect.
Artificially modifying content to “test” a system distorts the signal and contradicts a simple rule: an article should change only when there is an editorial reason to do so.
To test correctly, I needed a new, genuine article, deliberately published. This article is the result — but the test itself is not the subject; it is merely the context.
What I put in place — control, stability, measured automation
I will not detail the code here. What matters is the logic:
- clear separation (pages / posts, languages);
- controlled dates (stable by default, modified only when a real change occurs);
- deferred automation (no instant reaction, measured verification).
Core principle:
The sitemap does not react to an action, but to an established fact.
Doing things right rather than fast — the long-term sitemap logic
The goal of a sitemap is not to manipulate search engines or to “force” indexing. It is simpler: to honestly describe the reality of a website and preserve signal coherence over time.
A sitemap is not a marketing lever.
It is not a growth tool.
It is a document of truth.
This article shows why a poorly managed WordPress sitemap can harm crawling, indexing, and signal coherence — and why stability and precision are preferable to reactivity.
In summary
- a sitemap is public: it should expose only what is essential;
- dates must reflect real changes;
- noise complicates crawling and diagnosis;
- coherence and stability matter more than reactivity;
- it is better to have no sitemap at all than a reactive, incoherent one that sends misleading signals.
This article was not planned. But it reflects how I work: understanding, structuring, and leaving nothing to chance.
Note: it also served to validate an automated system I recently put in place — one that triggers only when a new article is genuinely published.