SleekRank can read from any REST API or JSON file. Common feeds are the NOAA solar calculator export, the Sunrise-Sunset API, or precomputed CSVs generated from a small Python script that runs once a day and writes back per-city rows. Whichever source you pick, the page group caches the response at the configured interval and rebuilds pages from cache.

Store the IANA time zone per city row (Europe/Reykjavik, Africa/Cape_Town, America/Anchorage). The astronomy calculator returns UTC times, and the row stores both UTC and local clock time so the page can render either or both. Hreflang variants for the same city under different languages can share the row but emit different meta descriptions in the page-group mapping.

Edge cases need explicit handling in the row. Tromso in summer reports 'Midnight sun' instead of clock times for the affected days. The source script should detect when day length exceeds 24 hours or drops to zero and emit a label instead of a number. The list mapping treats that label as a string and renders it cleanly without breaking the table.

Yes. Civil, nautical, and astronomical twilight bounds are all standard fields in solar calculators. Selector mappings can inject each phase start and end into a dedicated section of the base page, which is particularly useful for photography hubs targeting blue-hour and golden-hour searches.

Daily is the right cadence. A cacheDuration of 86400 refreshes today's row at the start of each day, and the seven-day table rolls forward naturally. Hourly refresh is overkill because the math is deterministic for a given date and location and does not change throughout the day.

Yes. SleekRank registers every generated URL with the sitemap and noindexes the base template page so only city URLs get crawled. New cities added to the source appear in the sitemap on the next cache refresh, which is useful when expanding into new regions or covering events that suddenly surface a new destination.

Yes. Either expand the source row to include moonrise, moonset, and tide data, or run a separate page group at /moonrise/{slug}/ and /tides/{slug}/ sharing the same slug across groups. Internal links between the three pages compound topical relevance for each city, especially in coastal and astronomy-tourism markets.

Store localised strings per row (titleEn, titleEs, descriptionEn, descriptionEs) and switch the mapping field based on the active language. For a single-language site, just keep title and description in the row and update the page-group mapping when the locale changes. Tag mappings handle any string field, so localisation is a matter of source data, not template forking.