Site Changelog

What Gets Logged

• Policy changes that affect privacy, advertising, corrections, or editorial disclosure.
• Article curation decisions, including pages removed from sitemap, RSS, or site search.
• Major content upgrades such as flagship guides, topic hubs, templates, and tool output evidence.
• Navigation or naming changes that could affect readers, search engines, or external references.

How Content Curation Is Decided

Spec Coding does not treat every published page as permanently equal. A page can be useful as a narrow reference and still not deserve promotion in the sitemap, RSS feed, or site search. The curation decision starts with reader intent: does the page answer a concrete engineering question, produce a reusable artifact, clarify a decision rule, or route the reader to a stronger workflow?

When the answer is weak, the first fix is to improve the page. If the page overlaps with a stronger hub or flagship article, it may be kept for direct visitors but marked noindex and folded into the better topic path. If the page is obsolete, misleading, or no longer useful, it should be redirected or removed. This keeps the visible site focused on pages that can stand up to review.

How Noindex Pages Are Handled

A noindex page is not hidden from readers who already have the link. It remains available as a reference, but the site stops presenting it as a primary content asset. For curated articles, Spec Coding adds a visible note near the top of the page explaining that the article has been folded into a stronger hub. The sitemap generator, site search index, RSS feed, and blog archive generation are configured to skip those pages.

This is meant to reduce low-value discovery paths without breaking legitimate old links. It also makes future review easier: if a page is promoted, it should be strong enough to justify that promotion. If it is retained only for continuity, the page should say so plainly.

Verification After Material Changes

After a material content or policy change, the maintenance pass should regenerate site assets and run quality checks. The expected checks include site metadata, internal links, article depth, generator tests, search ranking, generated file stability, sitemap output, RSS output, and a small browser smoke test for high-traffic pages.

These checks do not prove that every editorial judgment is perfect, but they catch common site-quality failures: broken internal paths, missing search entries, accidental thin pages, unstable generated output, stale sitemap URLs, and layouts that become difficult to use after content changes.

Review Cadence

Core pages are reviewed when the site structure changes, when a related tool or template is updated, or when a page begins to look like an isolated answer instead of part of a useful workflow. Policy pages are reviewed whenever advertising, analytics, newsletter handling, correction handling, or author disclosure changes. Topic hubs are reviewed after major article curation so they remain the best starting point for readers and search engines.

The changelog is updated after those reviews when the change affects reader trust, discoverability, or the way the site presents its best material.

What Is Not Logged Here

Minor typo fixes, punctuation changes, local wording adjustments, and small internal link swaps are usually not logged unless they affect policy meaning, page purpose, or reader trust. The changelog is intended to be useful to readers and reviewers, not a noisy commit history.

Engineering implementation details remain in the repository history. This page summarizes changes that matter to people evaluating content quality, editorial responsibility, ad safety, and navigation clarity.

Current Review Priorities

The next quality pass focuses on keeping the four hubs current, tightening article-to-template paths, and removing pages that no longer answer a concrete engineering question. New pages should add a reusable artifact, decision rule, or review path before they are considered for indexing.