No. SleekRank renders pages from data you provide. Dynamic horoscopes — daily, weekly, monthly — would need to be written elsewhere (an editorial workflow, an LLM pipeline, an astrologer's CMS) and pulled in via a JSON or REST source. SleekRank handles publishing the structured reference content; the horoscopes are a separate content track.

Define separate page groups for signs and planets. Each group has its own dataset and urlPattern — /astrology/signs/{slug}/ and /astrology/planets/{slug}/. The base WordPress page can be shared if the layout is similar, with conditional sections that show planetary domiciles for planets and traits for signs, controlled by tag mappings.

Store compatibility as an array of slugs in the sheet (aries, leo, sagittarius for fire-sign affinity), then use a list mapping to render them with linked labels in the template. The slug-based approach means linking is automatic — clicking 'Leo' on the Aries page goes to /astrology/signs/leo/. Editors only ever touch slugs, not display names.

SleekRank doesn't generate chart images. Reference an image URL — a glyph SVG, a sign symbol, a planetary glyph — in the data row and inject the src via a selector mapping. Most sites store SVG glyphs in the WordPress media library and reference URLs from a glyph_url column. Pair with SleekPixel for dynamic OG cards per sign.

Yes. Add a shadow_traits array column in the sheet, add a list mapping pointing to a target element on the base page, flush the cache, and every sign page picks up the new section. Conditional rendering in the base template means signs without shadow data yet don't show an empty heading.

Yes. SleekRank registers every generated URL with the sitemap and noindexes the base template page. The sitemap stays clean — twelve sign URLs, ten planet URLs, twelve house URLs — with no risk of the base template ranking instead of the structured per-sign pages.

Yes. Add columns for both tropical and sidereal date ranges and use tag mappings to render whichever the page emphasizes. For deeper splits, define two page groups — /astrology/western/{slug}/ and /astrology/vedic/{slug}/ — each pointing at its own dataset with system-specific traits, rulers (Vedic gives Saturn rulership of Aquarius), and aspect rules.

Store both ruler_traditional (Aquarius = Saturn) and ruler_modern (Aquarius = Uranus) columns and render both via tag mappings, with the base template explaining the distinction. This is one of the highest-frequency editor drift points in manual astrology directories — having both columns with documented vocabulary settles the question once.