Each January, duplicate the previous year's rows in your sheet, update the year column, refresh the highlights and headline stats, then flush the SleekRank cache and rewrites. The new /year-in-review/wordpress-2025/ URL resolves immediately while wordpress-2024 and earlier stay live and indexable. The pattern scales linearly — one row per topic per year, no editor sessions.

You have two options. Keep them live indefinitely — that's usually the right call because they keep earning links. Or, if you want to consolidate, remove the rows from the source, add 301 redirects to a hub page, and let the link equity flow forward. Use a deprecated_to column to make the redirect target part of the data rather than a manual list.

Build a separate /year-in-review/ hub page that reads the same source, filters to the current year, and renders a grid of links. It can be another SleekRank page group with a single row, or a normal WordPress page with a custom query. The hub itself stays static while the data underneath rotates each January.

Yes if you compute the deltas in the sheet and store them in columns — releases_yoy_pct, contributors_yoy_delta. SleekRank renders whatever your sheet provides via tag mappings. For richer comparisons, link from each year's recap to the previous year via the related_slugs column so readers can navigate the timeline themselves.

No. SleekRank places existing content into the template. The narrative — what mattered, what shipped, what changed — comes from your team. The structured approach means the writer focuses on highlights and lookahead rather than re-inventing the layout each January, but the editorial work itself stays human.

Use a next_slug or related_slugs column. After publishing wordpress-2024, edit the wordpress-2023 row and add wordpress-2024 to its related_slugs. Map that column to a list of links so wordpress-2023 automatically points to its successor. New years inherit the pattern as you add them.

The template overlaps but isn't identical — monthly recaps have different cadence, different stats and a different navigation pattern. Run /year-in-review/ and /recaps/ as separate page groups with their own URL patterns, but keep the design language consistent so readers recognize the format. Both can live on the same site without conflict.

Article JSON-LD with the year as part of the headline and datePublished aligned to the publication date works well. Add about with the topic for context. If you publish stats, layer Dataset schema on the same page for the headline numbers. Inject the values via selector and meta mappings on the base page so each row gets accurate structured data.