Run an annual site health check

Open SEO Manager (sg-admin/seo/). The SEO Manager loads every page, post, and event on your site into a single table with 18 SEO signals per row. Once a year, export the full table and audit for gaps.

Checks to run:

1. Click Issues to filter to rows missing an SEO Title or Meta Description.
2. Fix each flagged row inline — click the SEO Title or Meta Description cell, type, and press Tab. No separate editor needed.
3. Scroll the Index Status column. Confirm every content page you want indexed shows the toggle active (green). Confirm any page you want excluded (thank-you pages, admin-facing pages) is toggled off.
4. Click Export to download the full table as a CSV. File it with today's date as your annual SEO baseline — useful for next year's comparison.
5. Open Global SEO (left sidebar). Confirm the site-wide title template and meta description are current and accurate.

Pass marker: Issues chip reads zero, or every remaining flagged row is intentional. Export filed.

Open the Redirects list (sg-admin/redirects/). Redirects accumulate every time you rename a page, merge sections, or run a seasonal campaign. After twelve months you typically have a mix of necessary live rules, expired campaign rules, and placeholder rules from an old site structure.

Checks to run:

1. Sort or scan for rules older than twelve months.
2. For each old rule, ask: Is the original URL still linked anywhere? If the source URL gets zero traffic and no external site links to it, the rule is a candidate for deletion.
3. Look for redirect chains — where rule A points to rule B. Collapse chains into a single direct rule where possible.
4. Delete rules with no traffic and no external links using the Delete row action, or select multiples and use Bulk action → Delete.
5. Note any rules you delete in case you need to reinstate one within the next few weeks.

Pass marker: No rules older than 12 months with confirmed zero traffic remain. Chains resolved.

Open the Backups panel (sg-admin/migration/). A backup you have not verified is a backup you cannot trust. Once a year, confirm that a recent backup exists and that it is restorable.

Checks to run:

1. Confirm a backup taken within the last 30 days appears in the list. If none exists, create one now before continuing.
2. Note the file name and size. A significantly smaller-than-usual backup (roughly half the normal size) can indicate an incomplete snapshot — worth investigating before you rely on it.
3. If your plan allows it, run a test restore on a staging instance. Restore the most recent backup to staging, confirm the site loads, and confirm one or two pages render correctly. A backup that cannot be restored is not a backup.
4. Archive the backup file name and creation date in your maintenance notes.

Pass marker: A backup dated within 30 days exists. Test restore on staging confirms the file is valid.

Open the Users panel (sg-admin/users/). Every site accumulates accounts over time — contractors who finished a project, a former staff member, a freelancer who did a one-off content update. Inactive accounts with elevated roles are a security risk.

Checks to run:

1. Filter by role. Start with Admin and Editor roles — these are the highest-privilege accounts.
2. For each account, check the last-seen or last-login date. Any account inactive for the past six months should be evaluated for disabling.
3. Disable (do not delete) accounts you cannot immediately account for. Disabling prevents login but preserves content attribution. You can re-enable if you made a mistake.
4. Review role assignments. Confirm every Admin-role account is genuinely an admin. Editors who only need to read content should be Viewers.
5. Check for accounts using personal email addresses (e.g. @gmail.com) that should have been converted to company accounts. Note them for a separate follow-up.

Pass marker: Every active Admin-role account has a known, active owner. All accounts inactive > 6 months are disabled or have a documented reason for staying active.

Open the Custom Codes list (sg-admin/custom_codes/). Custom Codes is where third-party scripts live: analytics loaders, tag managers, chat widgets, cookie banners, conversion pixels. Over a year, you might add a new analytics platform and forget the old one is still running, or a vendor's pixel gets replaced by a tag manager equivalent. Duplicate or deprecated trackers inflate page-load time and can conflict with each other.

Checks to run:

1. Count the total active snippets.
2. For each active snippet, ask three questions: Is this tracker still in use by your team? Is there a duplicate (two analytics scripts, two chat loaders, two consent banners)? Was this replaced by a tag manager container tag?
3. Disable any snippet you cannot confirm is needed. Disabling preserves the code so you can re-enable it if someone asks. Deleting is permanent.
4. For snippets you keep, confirm the placement is still correct (<head>, Body Start, or </body> End) — some vendors update their recommended placement between script versions.

Pass marker: Every active snippet has a confirmed owner and purpose. No duplicates. No tag-manager-replaced remnants still running directly.

Open the Custom CSS list (sg-admin/custom_css/). Custom CSS snippets support your design system, but they accumulate over time. A snippet written for a now-retired homepage hero stays active until someone removes it. Stale CSS adds rules that no selector can reach and occasionally conflicts with new theme changes.

Checks to run:

1. Read the name and priority of each snippet.
2. For each snippet, open it and skim the selectors. Ask: Does the selector still match anything on the live site? A selector scoped to a class removed from the theme is dead weight.
3. Any snippet tied to a specific page or design that no longer exists: disable it. Rename it with a suffix like — RETIRED 2026-01 so future auditors know its history without opening the code.
4. Check for priority conflicts — two snippets overriding the same class with different values. Resolve by adjusting priorities or merging snippets.
5. Snippets you are certain are no longer needed can be trashed. Trashed snippets move to a recoverable Trash state before permanent removal.

Pass marker: Every active snippet has selectors that match live site elements. No retired-theme CSS still running. Priority list is clean.

Open the Blacklist (sg-admin/blacklist/). The Blacklist blocks specific IP addresses from reaching your site. After twelve months, some blocks may be too aggressive (a shared IP that blocked a legitimate visitor) or stale (a bot that long since moved to a different address).

Checks to run:

1. Count total entries. For sites with fewer than 20 entries, read each one. For larger lists, sort by date and focus on entries older than six months.
2. For each entry, check the Reason field. If there is no reason recorded, add one before evaluating whether to keep or remove — you cannot safely assess an unexplained block.
3. Single-IP blocks added for a specific incident: are they still relevant? If your logs show no further traffic from that IP in the past year, the rule is safe to remove.
4. IP-range blocks (CIDR notation) deserve extra scrutiny — they can cover large subnets with many legitimate users. Confirm the range is still producing abuse before keeping the rule.
5. Use the Test IP tool in the panel to verify that a specific address (such as your own office IP or a customer's reported IP) is not accidentally blocked.

Pass marker: Every entry has a reason recorded. Stale single-IP blocks from incidents more than 12 months ago with no recent traffic have been removed. No legitimate IP ranges mistakenly blocked. Your own office IP tested as not blocked.

Open Tracking Consent → Logs (sg-admin/tracking-consent/). The Logs screen captures every visitor who saw your cookie consent banner — whether they accepted or declined, what page they landed on, and a full decision timeline. Once a year, review the aggregate picture to confirm your consent rate looks healthy and no sudden shift has gone unnoticed.

Checks to run:

1. Note the total session count for the past twelve months.
2. Scan for any month where the accept rate dropped sharply. A sudden drop may mean a banner change broke the Accept button, a browser extension is pre-dismissing the banner, or a traffic spike from a high-decline source arrived.
3. Click into one or two recent sessions and confirm the session detail view renders: the Summary card shows consent decision and timestamp; the Timeline shows the banner-seen → decision flow.
4. Take a screenshot or export the aggregate count for your compliance records.
5. Confirm your current banner copy and the Accept / Decline button labels still match what your privacy policy describes. If you updated the policy this year, confirm the banner version number in the logs matches the current version.

Pass marker: No unexplained rate drop in the past 12 months. At least one session detail view confirmed rendering correctly. Compliance snapshot filed.