Practical use and limits
Use it for: Run the six scenarios before release, then pair the source audit with a production build and HTTP checks of one English page and its Chinese counterpart. Add a fault only when it protects a real publishing invariant.
Limits: The suite verifies selected repository and rendered-output contracts. It does not prove factual accuracy, translation quality, production crawlability, indexing, Google's selected canonical, rankings, or advertising approval.
The question behind this experiment
A bilingual publishing rule is easy to write and surprisingly easy to break. A new English article may have no Chinese entry, a translation may retain the wrong metadata, a date may be set in the future, or a preview hostname may leak into canonical URLs. A normal audit reports green when the current repository looks healthy, but that alone does not show whether the checks detect the failures they claim to cover. This experiment asks a narrower question: can controlled faults make the audit fail for the expected reason?
The system under test
Before this report was added, the site had 36 English records and 36 matching Chinese entries. Next.js App Router generates article metadata from the localized record and publishes language-specific URLs under /articles and /zh/articles. Each page declares its own canonical URL and reciprocal English, Simplified Chinese, and x-default alternates. The content audit also checks section alignment, sources, dates, visuals, structured-data identity, crawl files, and publisher pages. The regression suite targets a few high-impact invariants rather than pretending to test every editorial judgment.
Build disposable fixtures instead of damaging the repository
The test script creates a unique temporary directory and copies only the app, lib, and public trees needed by the audit. It runs the healthy copy first, then creates a fresh copy for each negative scenario. Every mutation is explicit and must actually change its target file; the fixture is removed after the result is recorded. The SEO audit was refactored into a callable function so the tests can run in the same constrained process while preserving the existing command-line interface. No fault is written into the working content source.
Failure 1: remove one Chinese mapping
The first negative test changes the key for one Chinese article while leaving its English slug intact. The expected result is a nonzero audit outcome containing the exact missing-translation slug. This verifies the data-layer contract before Next.js reaches static generation. The runtime loader supplies a second boundary: when a Chinese mapping is absent or the section count differs, it throws instead of silently reusing English. That fail-closed behavior matters because Google determines language primarily from visible page content, not merely from a lang attribute or language-looking URL.
Failures 2 and 3: future dates and thin sections
The date test moves one publication date to 2099 and expects the audit to reject future publication or review dates. This prevents automation from making an unfinished page appear current and protects feed and sitemap timestamps from a simple scheduling error. The thin-section test replaces a real paragraph with a deliberately short fixture and expects the per-section completeness rule to fail. Neither assertion proves usefulness—Google does not prescribe a preferred word count—but both expose incomplete records that require a person to review the underlying substance.
Failures 4 and 5: hostname and navigation drift
The canonical-identity test replaces the production www.aifincode.com value with an invalid preview host and expects the shared-site-URL guard to fail. The navigation test changes the privacy-page link and expects the global trust-page check to fail. These scenarios protect details that may not cause a TypeScript or Next.js build error but can create confusing search signals or incomplete publisher journeys. Google describes rel=canonical as a strong canonicalization signal and recommends separate URLs plus hreflang annotations and explicit language links for multilingual pages.
What the six passing scenarios establish
The final run verified one healthy baseline and five injected failures: a missing Chinese mapping, a future date, a thin English section, a non-production canonical identity, and missing privacy navigation. All six produced the expected status and diagnostic text. This is useful evidence that the named guards execute, not evidence that every page deserves to rank. The suite does not judge factual accuracy, translation nuance, reader satisfaction, backlink quality, production crawlability, or Google's selected canonical. Those require source review, rendered-page inspection, deployment checks, Search Console, and reader evidence.
Join source checks to App Router output
The release sequence now runs candidate scoring, the six fault-injection scenarios, the healthy SEO audit, the site inventory, and a full production build. After the build, a representative English page and its /zh/ counterpart are requested over HTTP to verify status, visible title, html language, canonical URL, and reciprocal alternates. This division is deliberate: AST-based checks diagnose content records quickly, Next.js build validation confirms static route integration, and HTTP inspection confirms emitted metadata. A green result at one layer cannot substitute for the next layer.
How to extend the test without gaming the metric
Add a regression scenario only when it represents a failure the site would genuinely want to block. Good next cases include mismatched bilingual FAQ scope, a missing source for a research report, an absent visual asset, or a rendered alternate pointing to a nonexistent route. Keep each mutation small, require a precise diagnostic, and preserve one healthy baseline. Do not add word-count rules merely to make pages longer or tests merely to inflate coverage. The purpose is to turn editorial promises into observable failure behavior while leaving usefulness, evidence quality, and final publication with a human reviewer.
Frequently asked questions
Why test intentional failures instead of only running the normal audit?
A healthy run shows that current files satisfy the rules. Intentional failures show that specific guards execute and produce actionable diagnostics when those rules are broken.
Does hreflang replace a canonical URL?
No. They communicate different relationships. This site gives each language page its own canonical URL and adds reciprocal language alternatives, then verifies both in rendered HTML.
Do these tests prove that Google will index both languages?
No. They verify declared source and output invariants. Crawling, selected canonicals, indexing, and search presentation still need production observation and Search Console evidence.