On this page
Theaimart's blog publishes MDX files through one shared Next.js article template. Frontmatter supplies metadata and category membership; an index supplies listing data; the article body is loaded for its route. Category hubs organize discovery while individual URLs remain flat under /blog.
This is a source-based engineering explanation of the public repository as reviewed on 9 November 2026. It makes no claim about an unseen inference backend, hardware fleet, traffic scale or benchmark. The scope is the publishing system readers are using here.
Content lives beside the application
Each article is a file in content/blog/. The folder's README documents required fields and supported Markdown/MDX components. An author supplies a title, description, real publication date, category and body. Optional fields cover social images, SEO overrides, meaningful updates and visibility.
Keeping content in the repository makes a publication reviewable with its metadata and links. A change can be inspected as a diff and validated with the same source revision as the renderer. The trade-off is that publishing participates in the application's build and deployment process; a file edit is not an immediate live update.
This explanation describes the current filesystem source. It does not propose another CMS, database or duplicate article framework.
A shared parser defines the contract
src/lib/blog/parse.ts parses the article and validates metadata. The scan/index code checks article files and slug ownership. Invalid categories, conflicting slugs or malformed required fields should fail visibly rather than produce silently inconsistent pages.
The repository content guide is the authoritative authoring reference. The page template owns the H1; article sections use H2 and H3. Supported components provide consistent rendering without permitting arbitrary article JavaScript.
That separation keeps authors focused on content while the template controls navigation, metadata and related articles. It also makes a renderer change a shared responsibility: a component regression can affect many posts, so production validation matters.
The metadata index avoids reading every body for a listing
The build generates a blog metadata index from source files. The runtime source adapter exposes summaries for listing pages and reads a body when an article is requested. In production, content is treated as immutable for the lifetime of a deployment process.
The adapter checks the generated index version and a filename-list hash, rebuilding from content when that check fails. That is a deliberately cheap guard; it is not a cryptographic verification of every body edit. The production build regenerates the index, which is the appropriate publication path.
Explicit runtime file tracing in the Next.js configuration includes the content and generated data needed by server functions. Without the correct deployment files, a local development preview would not prove the production adapter can read an article.
Flat article routes preserve URL ownership
An article's canonical path is /blog/<slug>. Its category determines membership in a hub such as /blog/aix or /blog/research; it does not insert an extra directory into the article URL.
That distinction allows a category adjustment without unnecessarily moving the article. A slug change is a URL migration and needs deliberate redirect and internal-link work. The editorial workflow therefore prefers expanding an established page when it already owns the reader's intent.
The six hubs—AI Apps, AIx, ADX, Engineering, Research and Company—share the category registry. Tags provide narrower groupings without multiplying top-level categories.
Publication and indexing are separate decisions
A draft is not ordinary published content. A future publication date is not a signal to display the article early. A published noindex article can remain readable while being excluded from indexing surfaces according to the site's policy.
Central helpers coordinate visibility across listings, category pagination, sitemap and feed. This reduces the risk of independently written filters disagreeing about whether a page is published. Tests still need to exercise each output, because shared intent does not prove every caller uses it correctly.
Publication and meaningful-update dates serve different purposes. The original date is preserved during an expansion; an update date is added only for substantive changes. Sitemap and feed freshness should reflect actual content changes rather than fabricated daily freshness.
Metadata and structured data have one owner
The blog SEO helpers generate article titles, descriptions, canonical URLs, social metadata and structured data. The article template renders the corresponding visible content. Authors can supply supported overrides without introducing competing head tags inside the body.
BlogPosting and breadcrumb data should describe the actual page, author and dates. It is descriptive metadata, not a promise of a search result treatment. Articles without a dedicated cover can use the existing generated social image system.
The engineering goal is consistency: the canonical, main entity URL, Open Graph URL and sitemap entry should identify the same article. Duplicate schemas or contradictory canonicals would undermine that consistency even if the page looked correct.
Validation covers source and rendered output
The content audit checks metadata uniqueness, editorial keyword ownership, headings and local link destinations. It records an inventory containing source links, word counts, dates, categories and indexing state. That register makes a content expansion auditable without inventing search measurements.
Source checks are followed by type checking, linting, SEO tests and a production build. Rendered-output checks then inspect article HTTP responses, canonical/structured data, category integration, sitemap, feed and robots behavior. Browser checks cover narrow and desktop layouts, anchors, tables and related links.
These are finite checks with explicit scope. A passing build does not prove every external factual claim, and a screenshot does not prove metadata correctness. Editorial review, source verification and engineering checks complement each other.
The architecture supports an evidence-based editorial process
Existing URLs should own distinct search intents. A new article needs a user problem and differentiated value; a near-duplicate should usually become an expansion of its established page. Research content should identify whether it is a method, analysis or actual experiment.
For example, the latency methodology describes a reproducible study without claiming results. The FastAPI tutorial identifies the exact local test boundary and distinguishes mocked calls from live provider evidence. That precision belongs in the content, not only in an internal checklist.
Where to go next
For publishing software rather than blog content, use the developer publishing guide and platform overview. Those describe a separate app-listing workflow and should not be confused with this repository-based editorial pipeline.
For the blog, the useful next improvement is usually a stronger article, a better verified example or a clearer internal link—not another publishing framework. The current system already provides the routing, shared presentation and metadata foundation; careful content and reproducible validation make that foundation useful.