SleekRank only generates the landing page itself. Use your existing gating plugin or download manager — link to its gated URL from the row's download_url column. Common patterns include Easy Digital Downloads for paid templates, MemberPress for member-only access, or a simple email-gate tool for free downloads. SleekRank renders the link; the gate happens at the destination URL you control.

Add a category column with values like "marketing", "personal", "events". Filter on it for tag-style index pages, render category badges via selector mapping, or run multiple page groups with different urlPatterns like /templates/marketing/{slug}/ and /templates/personal/{slug}/ for fully separate URL trees per category.

Not by SleekRank itself. Pair with SleekPixel for branded OG image generation per template, or pre-render previews with a screenshot service like Browserless or a Puppeteer script that runs against your template demo URLs. Store the resulting URLs in a preview column. The combination gives you template-specific previews without a manual design pass per template.

Add Product JSON-LD to the base WordPress page once and inject name, description, image, category, and offers via selector or meta mappings sourced from the row. Every /templates/{slug}/ ships valid Product schema automatically because both the visible content and the JSON-LD read from the same columns. Validate once with the Rich Results Test.

Yes if you record popularity in the sheet. Add a downloads or rank column updated periodically from your analytics, sort the sheet by it, flush the cache, and the order on any list-rendered hub page reflects the new ranking. SleekRank reads the source order, so external sort logic — analytics-driven, manual, or hybrid — flows through to the rendered pages directly.

Two patterns work. Either flatten variants into separate rows with their own slugs like /templates/saas-landing-light/ and /templates/saas-landing-dark/, each with their own previews and meta tags, or list variants as a related_variants list field on a single canonical template page. The first pattern targets variant-specific search intent; the second keeps the catalog smaller for closely related variants.

Yes — that's exactly the JSON-file source pattern. Check a templates.json file into the theme repo alongside the template files themselves. Adding a new template becomes one pull request that includes both the file and the catalog entry. Pull requests review changes; git history audits every catalog edit. Editorial teams who prefer Sheets can use that instead, but engineering-led template projects benefit from in-repo JSON.

Carry a version column and an updated_at column. When a template ships a new version, edit those columns plus any changed description or tag content, then flush the cache. The landing page reflects the new version stamp; the download URL itself can stay the same or point at versioned files like template-v2.zip depending on your download workflow. Major versions can warrant new slugs; minor revisions stay on the canonical URL.