Every bonsai care page shares the same skeleton: light requirement, watering pattern, soil mix, USDA hardiness zone, repot interval, fertilizer schedule, and a list of suitable styles (informal upright, cascade, semi-cascade). The differences between a Japanese black pine and a Chinese elm are values in those fields. Hand-publishing each through Gutenberg means retyping the same labels and watching watering instructions drift between 'when dry' and 'every two days' across the catalog within a single growing season.

SleekRank reads one species sheet and renders one URL per row using a single base WordPress page. Light requirement and watering pattern slot into tag mappings, the suitable-styles list renders as proper list items via a list mapping, and soil mix and hardiness zone occupy fixed selectors. The base template handles styling once. New species are rows, not posts.

The library stays scannable for the people who read it: hobbyists comparing two species before buying. Authors correct a watering frequency on the pine row, flush the SleekRank cache, and every page that references the corrected schedule rebuilds on the next request without manual republishing.

Bonsai search is dominated by species-specific care queries. Hobbyists search for 'Japanese black pine watering' or 'Chinese elm hardiness zone', not 'bonsai care'. The pages that win those long-tail queries are the ones where the relevant fields, light, water, soil, hardiness, are visible immediately rather than buried inside species-history intros.

Built one post at a time, those fields drift between authors within a single growing season. Watering schedules stop matching, hardiness zones get implied rather than stated, and the catalog loses the structure that made it useful for the hobbyist comparing two species before buying. SleekRank treats the species as data and the care page as a template.

A new species is a row, a corrected watering schedule propagates everywhere, and the difficulty index updates from the same sheet. The author maintains the data; the developer maintains the base page; the catalog compounds in indexable URLs without the structural drift that kills hand-built libraries over time.