RedSkill validation tools

RedSkill Tools for Xiaohongshu Skills

The exact checks we run before publishing a change to RedSkill.org, what each one actually validates on this site, and the limits of what any of them can prove.

How this checklist is used

Every page here is static HTML that is verified before it ships. The checks below are the same ones the site's own regression suite runs, listed with the reason each one exists rather than as a generic list of links. If a check cannot be automated, it is written down here with the manual step spelled out.

The order matters. Crawler access and schema come first, because a beautiful page nobody can index is worth nothing. Content volume and accessibility come second, because those are what a reviewer or a first-time visitor notices. Performance comes last, because it is the easiest thing to measure and the easiest thing to over-invest in.

Search and indexing

  • Google Search Console: this site is verified as a domain property, so coverage is reported for redskill.org and every subdomain at once. After a publish, submit /sitemap.xml and use URL inspection on the pages that changed.
  • Bing Webmaster Tools: verified through the BingSiteAuth.xml file served from the site root. Bing is worth the extra step here because a meaningful share of this site's search traffic arrives from markets where Bing and its partners carry more weight than they do in the United States.

Schema and rich results

  • Google Rich Results Test: validates the JSON-LD graph each page emits. Every page carries an Organization and a WebSite node; guide pages add Article, category pages add CollectionPage and BreadcrumbList, hub pages add ItemList, and the homepage carries the Dataset node describing the published snapshot.
  • Schema Markup Validator: catches structural problems that do not affect rich-result eligibility but still matter, such as an ItemList whose entries all point at the same URL.

Crawler access

Two files decide whether an ad or a search crawler can read this site, and both are checked automatically before a deploy:

  • /robots.txt allows every user agent and must never block a trust page. Blocking a page that also carries a noindex directive hides the directive too, so the page can still be indexed as a bare URL — a worse outcome than either choice on its own.
  • /ads.txt authorises the AdSense seller for this domain. It contains exactly one line, and any drift from the publisher ID configured in site.config.json fails the build.

Performance and accessibility

  • PageSpeed Insights: checks mobile Core Web Vitals. The most common regression here is an image or a font weight added without a size budget, so we check field data rather than only the lab score.
  • WCAG 2.2: we test against specific criteria rather than a general impression. Bypass blocks (2.4.1) is satisfied by the skip link on every page; focus visible (2.4.7) by the focus rings on links and controls; contrast minimum (1.4.3) by a token-level contrast check that fails the build when a pair drops below 4.5:1; target size (2.5.8) by keeping interactive controls at least 24 by 24 CSS pixels, and 44 where a control only exists on mobile; and use of colour (1.4.1) by pairing every risk label with a text value rather than a colour alone.

Local regression checks

Run these three from the repository root before publishing. They are deliberately fast and offline.

  • python3 scripts/build-content.py --check verifies that every generated page and the sitemap are current, so a hand edit to a generated page cannot silently win.
  • python3 scripts/verify-seo.py validates metadata budgets, canonical URLs, hreflang pairs, JSON-LD requirements, asset cache-busting, robots and ads.txt contents, CSS colour token usage, contrast pairs, and the minimum body content on every indexable page.
  • python3 -m unittest discover -s scripts -p "test_*.py" runs the contract suite that keeps shared chrome, page layout and the verification boundary from drifting apart.

What we do not claim

A passing run of these checks means the pages are structurally sound and consistent. It does not mean the content is correct, and it does not mean any third-party skill described here is safe, maintained or still available. Those are separate questions that no automated check can answer, which is why every dataset row on this site is presented as a lead to verify rather than as a verified fact.