---
name: verify-footer-includes-social-links-and-secondary-nav
description: "Give readers useful links at the end of a page. Check the footer on a phone and a large screen."
category: Website QA Audit
stage: —
definitive_article: /website-qa-audit
status: complete
---

# Verify footer includes social links and secondary nav

People who reach the end of a page still need a next step. This guide helps you check the links in the footer. Start with the pages and public profiles your visitors should be able to find.

**The path:** Expected destinations → Template coverage → Link and phone checks → Verified footer.

**Use this when:** A site launch, footer redesign or navigation audit needs its shared footer reviewed.

## Inputs
- The canonical site, known page templates and any deliberately distinct landing-page footers.
- The actual key pages and approved public-profile inventory, with person/company identity.
- Desktop/phone views, supported menu/theme/builder access and authorized changes.
- A footer map recording templates, link text, exact destinations and justified exceptions.

## First-run prompt

> Use the supplied template and destination map. Check the footer’s real links, labels and desktop/phone layout on each template, make authorized shared-source fixes, and return exact coverage and exceptions without inventing pages or profile identities.

## Steps
1. List the site’s useful secondary destinations, such as about, services, articles and contact, plus applicable existing policy links. Do not create a nonexistent service page or legal text simply because a generic checklist names it.
2. Inspect the footer on the home page and representative examples of every actual template. Record intentional landing-page differences rather than assuming one home-page check covers all pages.
3. Check that navigation labels and social links are visible and understandable. Use meaningful accessible names for icons, and separate the person’s public profile from the company’s where both are shown.
4. Read each ordinary target and confirm the intended canonical page/profile. Check named anchors and redirects. Do not place calls, send messages or follow accounts merely to test a footer link.
5. Review the relevant identity map without forcing every footer profile into one Person sameAs array. A company footer destination can belong to an Organization node while remaining a useful navigation link.
6. Repeat at 1440×860 and 390×844 after scrolling to the footer. Check wrapping, tap usability, collapsed sections and overlaps with sticky banners. Record which template and width fail.
7. Repair authorized menu, label or layout issues through the supported shared source, and check for effects on all affected templates. Preserve intentional variations and unrelated site settings.
8. Reopen normal canonical pages and save per-template results with exact remaining link or layout gaps. One shared menu definition does not prove every template actually renders it.

## Definition of done (QA checklist)

- [ ] Applicable key destinations and approved public profiles are easy to find in the actual footer.
- [ ] Each checked link resolves to the right page or entity, with limitations stated.
- [ ] Every known template is represented or explicitly untested.
- [ ] Desktop/phone wrapping and controls work without overflow or overlays.
- [ ] Intentional exceptions and authorized changes are documented and publicly rechecked.

## Example(s)

**Fictional teaching example — no footer was changed.** Maple Cycle’s home and article templates share one footer, but its quote landing page uses another. The home footer works on a phone; the landing footer hides the contact link under a sticky bar.

The audit records a landing-template phone failure instead of passing the whole site from the home page. The teaching fix adjusts that supported footer’s spacing and rechecks it. The company social link remains labeled as the company, not inserted into the founder’s personal identity array.

## Handoff and Content Factory context

The site owner receives the template/link map. [Review public profile links](https://local-service-spotlight.github.io/task-library/?task=check-social-profiles-linked-and-prominent#task-check-social-profiles-linked-and-prominent) verifies broader profile discovery; [Check broken destinations](https://local-service-spotlight.github.io/task-library/?task=check-for-broken-links#task-check-for-broken-links) can supply current response evidence.

This is a supporting quality check for the [Content Factory](https://blitzmetrics.com/content-factory/). Produce gathers real source material; Process makes useful assets; Post places and checks them; Promote distributes suitable work within its own scope. This check does not automatically execute all four stages. Use the actual next step above; catalog neighbors are not prerequisites.

## When this runs

Run at launch and after shared menu, template or destination changes. Recurrence uses an actual defined site review, not a model’s assumed memory.

## First-run setup and continuity

Open the supplied task file and its linked source. Verify the project’s real inputs, account, access and output folder before work. This Markdown file is a guide; it does not install an app, connect an account, supply a subscription or create a schedule. Carry out work already authorized; do not ask for the same approval again. Keep any unsupplied destination or new action outside that scope clearly pending.

Save source IDs, versions, decisions, checked outputs and next owner in the project tracker. Before a retry, check the saved state and other workers’ changes. A model name does not guarantee memory or a running timer. Repeated work needs an actual configured trigger and durable state; one-off work can be started by the prompt above.

Keep agent media muted with volume zero before playback. If mute cannot be verified, use captions, metadata or still frames. State the limit: silent visual checks do not prove spoken-word accuracy or audio quality. Do not start sound through the user’s speakers unless explicitly asked.

## Write up the real run

For every actual attempt, [write its meta article](https://blitzmetrics.com/meta-article-prompt/) with this recipe and revision, trigger, steps performed, output evidence, measured result, gaps and next owner. Failed, blocked and partial attempts also get a written record. A draft can satisfy writing; publishing it follows the existing job scope.

Keep one stable execution ID across retries and edits. A separately scoped child task may have its own ID linked to its parent. Writing the parent’s meta record is part of that run, not an endless new chain. The [recipe and meta-article guide](https://localservicespotlight.com/meta-articles/) explains this distinction. Teaching examples are not real executions and must not enter the run count.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 2, gating 3 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- Canonical article: https://blitzmetrics.com/website-qa-audit
- Exact task: [Verify footer includes social links and secondary nav](https://local-service-spotlight.github.io/task-library/?task=verify-footer-includes-social-links-and-secondary-nav#task-verify-footer-includes-social-links-and-secondary-nav)
- Writing standard: [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Website QA Audit](https://blitzmetrics.com/website-qa-audit/)
- [Entity linking](https://blitzmetrics.com/entity-linking/)

## Review and evidence still needed

The source contributor status is preserved. It is not certification of this draft or proof of account access, completed work or a live outcome. The worked example teaches the method and is explicitly fictional.
- The actual template inventory and approved navigation/profile destinations require the project.