Japanese with Manga — Site & Content Review

TL;DR

The biggest issues are all in the kanji section's scale outrunning its content: 2,081 of 2,139 kanji pages are live-but-empty "coming soon" placeholders that are indexable, 1,721 kanji pages have zero manga examples, and 96% of dictionary entries are flagged todo: update. The highest-leverage work is (1) noindexing/hiding placeholder pages, (2) a published-content-first triage of the dictionary backlog, and (3) navigation for finding kanji by character rather than English keyword. The best new features build on data you already have: an RSS feed, kanji lookup by character/component, JLPT-ish difficulty tags, and Anki/Migaku export from your structured front matter.

2. Concept Assessment — What's Working

StrengthFunction-based grammar taxonomy. JLPT tags could be added as metadata without reorganizing.

Concept-level risks worth acknowledging

Panel imagery and copyright. ~1,700 image files (~80 MB) of scanned manga panels. Educational commentary with attribution and purchase links is a reasonable posture, but there is no visible fair-use / takedown statement. A short policy page ("panels are low-resolution excerpts used for commentary; links to purchase every series; contact for removal") would formalize the good-faith position you already practice via the series purchase links.

3. Existing Data — Improvement Opportunities

HighDictionary backlog: 9,556 of 9,960 entries flagged `todo: update`

96% of _data/dictionary.yml awaits review. Since these summaries surface on published kanji pages and in definition popovers, unreviewed text is user-visible.

Suggestion: triage by exposure rather than working alphabetically — a script that cross-references words: front matter on published pages against flagged entries would give a priority list of the few hundred entries readers actually see. (You already have add_vocabulary_todo.py and the build-index machinery; this is a small addition.)

HighKanji example coverage: 11,845 of 12,588 word slots lack an example

1,721 kanji pages have zero manga examples across all their words. For the ~58 published pages this matters directly; for the rest it defines the publishing runway.

Suggestion: define a publish threshold (e.g., "at least N words have examples") and drive it from data. Your _ocr/ corpus is the untapped asset here — a script that greps OCR text for words flagged todo: Need an example. and reports series/volume/page candidates would turn example-hunting from re-reading into lookup. (One kanji file already contains a related idea: "show a list of additional examples with words using this kanji.")

Medium450 example pages flagged `todo: add vocabulary`

These examples don't yet cross-link their words into the dictionary/kanji system, so they're invisible to kanji word sections that would otherwise reuse them. Working this list down multiplies the value of examples you've already written.

MediumNo RSS/Atom feed

The homepage has a "Recent Additions" section and content ships near-daily (2,301 files dated 2026), but there is no feed and jekyll-feed isn't in the plugin list. For a site with steady output and a Discord community, a feed is the cheapest retention feature available.

MediumKanji index is a flat English-keyword list

kanji.md renders one alphabetical bullet list of titles like "Ability and capability with 能." There's no way to look up a kanji by the character itself, by reading, or by component — the natural lookup modes for someone who just met a character in a manga. This gets worse with every batch published.

Suggestion: add a compact character grid (the char itself, linked) and/or group by first English keyword letter with a jump bar; longer term, see the component-browsing feature below.

MediumSocial/share metadata gaps

No og:image or twitter:image anywhere, so shares render textless; og:type is hardcoded to article even on the homepage; the WebSite schema lacks a SearchAction despite Pagefind existing at /search; no BreadcrumbList schema (already noted in your own SEO doc). A single default site card image would fix the biggest share-appearance gap without touching copyrighted panels.

MediumAging early content vs. current format

Older explanations (e.g., "Conjecture with 〜らしい," dated 2018, untouched since) predate the current format: no formation: table, sentence patterns left in an HTML comment, sparse related: links. Only 39 grammar files have related: at all, while newer pages (the 〜だけじゃなくても page) show how good the current format is. A modernization pass over the pre-2023 explanations — prioritized by search traffic if you have analytics — would raise the floor.

LowSmall hygiene items

_grammar/Unsorted/ (8 items, including one named test) and _grammar/Unused/ ship inside the source tree; worth either sorting or moving to _drafts.
No 404.html found at the site root.
common_points.yml holds only 5 reusable key points despite a dedicated resolver plugin — recurring points (さん/ちゃん/くん honorifics, contracted forms, sentence-final particles) are being rewritten per page instead of reused.
10 of 57 series pages lack an english: title even though the layout supports it.
Google Fonts is an external dependency (privacy + render-blocking); self-hosting the three families is a small, one-time win.
Series concentration: 114 of ~460 examples come from ごちうさ and 64 from 名探偵コナン; many of the 57 series pages show "No examples yet." Fine editorially, but the series index could sort by example count so visitors land on rich pages first.

4. Feature Recommendations

Quick wins (days, mostly leveraging existing data)

RSS/Atom feed via jekyll-feed or a hand-rolled template over build_indexes.recent_content (which already exists for the homepage).
Default og:image site card + BreadcrumbList and SearchAction schema (your SEO doc already contains the snippets).
Kanji index jump navigation — a character grid at the top of /kanji.
"Random example" button — a static JSON index of published example URLs plus a few lines of JS; great for the "just show me something" visitor and encourages exploration.
Fair-use / attribution page linked from the footer.

High-value (weeks, strong fit with the site's data model)

Kanji lookup by component. Etymology text already names components ("能 shows two paws… also the central part of 熊"). Making components a structured front-matter field would enable browse-by-part, "kanji containing 力," and visual family pages — a feature almost no manga-learning site has, and it's your data model's natural strength.
Difficulty metadata. Add an optional jlpt: or level: field to grammar/vocabulary explanations and expose it as a filter on index pages. Keeps the function-based taxonomy as the primary organization while serving the very large "I'm studying for N4" audience. (Currently JLPT appears only incidentally in ~30 body texts.)
Anki/Migaku export. Dialogue lines, marked target words, literal/natural translations — everything needed for high-quality cloze cards already sits in front matter. A per-explanation "Download deck (TSV/apkg)" link would be a signature feature, and it aligns with the Migaku workflow you already recommend on the About page.
Per-series learning profile. You have examples-by-series, OCR text, and Manga Kotoba links. A series page section like "grammar points covered on this site from this series" (already derivable from the index) plus a difficulty note would make series pages genuine landing pages for "is ○○ readable for me?" searches — a query people actually make.
OCR-powered example finder (internal tooling). As in Finding 3: grep the OCR corpus for wanted words, output candidates with volume/page. This attacks the single biggest content bottleneck (11.8k missing examples) at its root.
Explanation ↔ example navigation. Previous/next links among an explanation's examples, and "more examples from this series/volume" on example pages, would increase pages-per-visit with data already in the indexes.

Ambitious (worth doing only if the site grows an audience)

Local progress tracking. localStorage "mark as known/learned" on grammar/kanji pages with a personal dashboard — no backend needed, consistent with the existing theme/furigana persistence pattern.
Study mode on example pages. A toggle that hides English (and optionally furigana) so readers attempt the panel first, then reveal. Cheap to build on the existing markup; pedagogically it converts every example page into an exercise.
Smarter furigana modes. Beyond hover/always: "first occurrence per page" or "hide readings for kanji I've marked known" (pairs with progress tracking).
Grammar comparison pages. The related: notes already contain sharp contrastive one-liners (らしい vs そうだ). Dedicated "X vs Y" pages are among the highest-search-volume grammar queries and you have the raw material.
Community example submission. submit.html exists as an internal authoring tool; a public-facing flow (form → Discord webhook → your review) could scale example collection while keeping editorial control.

5. Suggested Priority Order

Noindex/hide the 2,081 placeholder kanji pages (protects everything else's SEO).
Ship RSS feed + og:image + breadcrumb/search schema (cheap, compounding).
Build the OCR example-finder script and the exposure-ranked dictionary triage list (attacks both giant backlogs with tooling rather than grind).
Kanji index navigation and character lookup.
Difficulty tags, then Anki export, then series learning profiles.
Fix the small hygiene items (permalink typo, duplicate key, Unsorted/test files, 404 page) in one pass.

Other Considerations

update lint for things like example words list containing a word that has "todo" in the vocabulary data file.
add a kanji section to the example page. This replaced the "see also" kanji with a list of kanji and brief information, with a link to the full page.