No. SleekRank does not generate plant content of any kind. You provide the care sheet — light, water, soil, propagation steps, and so on — and SleekRank renders one page per plant. All editorial responsibility for accuracy, watering schedules, light tolerance, and pest susceptibility stays with you. SleekRank's role is purely the rendering and routing layer between the care data and the live site.

Yes. Add an image_url column to the sheet and map it into the page via a tag or selector mapping that injects an tag. For Open Graph cards, use a meta mapping for og:image with the same column, or pair SleekRank with SleekPixel for dynamic OG images that take the slug as a parameter. SleekPixel renders branded cards with per-page text from a designed template.

Use a list mapping against a propagation array column so each step becomes a list item on the rendered page. Store steps as an array of strings (or objects if you need richer data per step like "week 1: place cutting in water"). The list element on the base page becomes the target; SleekRank fills it with one item per array entry, preserving order from the sheet.

Update the urlPattern in the page-group config (say, from /plants/{slug}/ to /houseplants/{slug}/), flush rewrites, and add redirects from old URLs if any are already indexed. WordPress core or a redirect plugin handles the redirect side. The page-group change itself is one config edit; the redirects are the work that protects existing backlinks and indexed URLs.

SleekRank caches the source per cacheDuration — set in seconds on the page-group config. Edit the sheet, clear the SleekRank cache (via WP-CLI or admin), and the next request rebuilds the page with new data. For plant care (a slowly changing domain), set cacheDuration high so the sheet is not constantly fetched. Bulk updates land everywhere on a single cache clear.

Yes. Each generated URL is a real WordPress page included in the sitemap, suitable for indexing. The base template is excluded automatically so the scaffolding does not compete with real plant pages. Standard SEO plugins still handle canonicalization, schema, and per-page meta. Run a rewrite flush after adding new plant slugs so the routes resolve immediately on production.

Yes, but that's a different page rather than the per-plant URL. Build a /plants/ index page that pulls from the same dataset and filters by light, water, or difficulty. SleekRank handles the per-plant detail pages; the hub or filter pages can be built with a Twig template or a query block on top of the same data source. The single source of truth is shared across both.

Pick one canonical slug (typically the most-searched common name, like monstera-deliciosa or snake-plant) and store alternate names as an array column rendered as "also known as" on the page. Add redirects from /plants/swiss-cheese-plant/ to /plants/monstera-deliciosa/ so alternate-name searches land on the canonical page. The dataset stays the source of truth for naming.