How to Create Reliable Anchor Links With WordPress Blocks

Create a reliable WordPress anchor link by assigning one unique, stable HTML Anchor.

Link to that exact identifier after a hash. Test the published URL and sticky-header position.

Do not rename published anchors casually. External and internal fragment links can depend on them.

Understand anchor-link anatomy

An anchor target is an element carrying a unique HTML id. A fragment link references that id.

The link `#pricing` targets an element with `id=”pricing”`. Both values must match exactly.

The WordPress Link control guide lists same-page fragments as supported URL formats.

Understand what the hash means

The hash separates the page URL from its fragment identifier. It is part of navigation.

Do not include the hash inside the HTML Anchor field. Store only the identifier there.

Add the hash inside the link destination. This separation prevents malformed targets.

Understand block anchor support

Blocks declare whether they support anchors. Supported blocks expose an HTML Anchor field.

The developer anchor-support reference explains that this field creates an element id.

Current support can also expose direct-link copying. Availability depends on block and WordPress version. The mechanics are in the Footnotes block in long-form content.

Choose the target block

Anchor the block representing the destination section. Heading blocks are common and understandable targets.

A Group can anchor a complete section when its heading sits inside. Test resulting scroll position.

Do not anchor decorative separators or empty spacers. Targets should convey meaningful arrival context.

Create a heading anchor

1. Select the Heading block.
2. Open its Advanced settings.
3. Find the HTML Anchor field.
4. Enter a unique stable identifier.
5. Save or update the page.
6. Copy the public URL.
7. Append the matching fragment.
8. Test while logged out.

Use the editor’s direct-link copy control when available. Still verify the public destination.

Create a Group anchor

Select the outer Group owning the section. Add its identifier through Advanced settings.

A Group target can include background and spacing before the heading. That may improve arrival visibility.

Keep only one target for the section. Duplicate nested identifiers create invalid ambiguity.

Create a same-page link

1. Select descriptive source text.
2. Open the Link control.
3. Enter the hash and identifier.
4. Apply the link.
5. Preview the page.
6. Activate the link.
7. Confirm the correct section appears.

For a `pricing` identifier, use `#pricing`. Do not paste the `id=` syntax.

Create a cross-page anchor link

Combine the destination page URL with its fragment. Example: `/pricing/#guarantee`.

Confirm both the page path and identifier. Either part can change independently.

Test from another page, not only the destination itself. Loading and scrolling behaviour can differ.

Choose stable identifier names

Use lowercase words separated by hyphens. Choose purpose-based names likely to survive copy edits.

`refund-policy` is more durable than `section-three`. Position-based names decay after rearrangement.

Keep identifiers concise and understandable. A maintainer should recognise the target quickly.

Avoid spaces and punctuation

Simple lowercase hyphenated identifiers minimise encoding and copying problems. Avoid spaces and decorative punctuation.

Non-ASCII characters can work but may appear encoded in URLs. A simple policy improves maintenance.

Never paste an entire heading sentence automatically without review. Long fragments become fragile.

Match case exactly

Fragment matching can depend on exact character case. Treat `#Pricing` and `#pricing` as different.

Lowercase identifiers remove this avoidable decision. Link text can retain normal capitalisation.

Copy identifiers rather than retyping them. Manual case errors are annoyingly invisible.

Keep every id unique

One page should not contain duplicate ids. Browsers cannot choose two authoritative targets safely.

Duplicated patterns can copy HTML Anchors. Review identifiers after inserting or duplicating sections.

Search rendered source for the id before publishing. Confirm exactly one matching element.

Do not depend on automatic heading ids

Themes or table-of-contents plugins can generate ids from headings. Their rules can change.

Manual anchors provide deliberate stability for important links. They can survive heading wording changes.

If automation owns ids, document that owner. Avoid adding competing manual identifiers casually.

Preserve published anchors

An anchor can receive links from posts, emails, documentation, bookmarks, and external sites.

Changing visible heading text need not change its stable identifier. Preserve the existing fragment.

When the target concept disappears, update known links. Consider keeping a compatible target temporarily.

Treat anchor renames like URL changes

Servers do not redirect fragments separately in ordinary workflows. A renamed id can fail silently.

The page still loads, but the expected section may not appear. Link checkers can miss this.

Inventory dependent links before renaming. Update internal sources and important external documentation.

Account for sticky headers

A fixed header can cover the target heading after navigation. The link technically works but feels broken.

Use a consistent scroll offset through theme CSS. `scroll-margin-top` can help target elements.

Match the offset to real header heights across viewports. One desktop value may fail mobile.

Account for admin bars

Logged-in administrators may see an extra top bar. Logged-out visitors usually do not.

Test both states before adjusting global offsets. A fix for editors can misalign visitors.

Use frontend preview without authentication for authoritative public behaviour. Then test administrative use separately.

Account for responsive headers

Header height can change after navigation collapses or announcements wrap. Static offsets may become inaccurate.

Test narrow widths, zoom, translated labels, and open navigation states. Real layouts reveal edge cases.

Prefer robust theme-level spacing over per-heading empty blocks. Spacers create new maintenance problems.

Account for delayed content

Images, embeds, fonts, and banners can shift the target after initial navigation.

Reserve dimensions and reduce layout shifts. Stable pages preserve reliable fragment arrival.

Test cold loads over slower connections. Cached desktop tests can hide movement.

Account for collapsed content

A target inside closed Details or Accordion content may remain hidden. Browser behaviour cannot reveal everything.

Anchor the visible disclosure heading when appropriate. Then explain which panel needs opening.

Custom scripts can open targeted panels. That enhancement needs keyboard, focus, and failure testing.

Understand scroll versus focus

Fragment navigation usually scrolls toward a target. It does not always move keyboard focus there.

Screen reader and keyboard experiences can therefore differ from visual movement. Test representative technology.

Do not add tabindex values casually. Focus management needs deliberate interaction design.

Use descriptive source text

The source link should name the destination section. “Jump to pricing” communicates more than “here.”

Table-of-contents links can mirror concise heading labels. Keep every label distinct.

Do not expose raw fragments as visible text unless technical readers need them.

Build a manual table of contents

1. Choose meaningful destination headings.
2. Assign stable unique identifiers.
3. Create one descriptive link per section.
4. Keep link order aligned with content.
5. Test every fragment publicly.
6. Update the list after structural edits.

A manual list suits stable pages with few sections. It becomes expensive on frequently changing references.

Evaluate an automatic table of contents

Automatic tools can read headings and generate links. Confirm their id naming and update behaviour.

Check which levels appear, whether labels can change, and how duplicates resolve.

Test plugin deactivation. Existing external fragments should not become meaningless unexpectedly.

Create a “back to top” link cautiously

Long pages can benefit from a return route. Browsers and keyboards already provide navigation tools.

Anchor the main content start or page title. Avoid vague targets above intrusive banners.

Do not repeat a floating control that obscures content. Test zoom and small screens.

Use anchors in navigation carefully

One-page sites may use section fragments in primary navigation. That creates special current-state challenges.

Cross-page visitors need complete URLs plus fragments. Same-page visitors can use shorter hashes.

Test menus from every template and path. Relative fragment assumptions can fail elsewhere.

Use anchors in support links

Support teams can link customers toward one relevant section. Stable ids reduce repeated explanation.

Keep the destination understandable when entered mid-page. Include nearby heading context and direct answers.

Record commonly shared fragments. Those anchors deserve stronger change control.

Use anchors in campaign links carefully

A campaign link can combine query parameters and fragments. Test the exact final URL.

Analytics scripts and redirects may preserve or remove fragments differently. Confirm production behaviour.

Do not expose a target removed after the campaign. Maintain or update shared links.

Avoid empty anchor targets

An empty Group or Spacer can provide a target but no arrival context. That confuses readers.

Anchor a meaningful section container or heading. Visible context confirms that navigation succeeded.

If spacing requires adjustment, fix scroll margins. Do not add invisible target clutter.

Avoid duplicate links beside headings

A heading permalink icon can support copying. Its accessible name must describe the action.

Do not create several identical fragment links in one line. Redundancy adds focus stops.

Choose one visible or discoverable copy-link pattern. Apply it consistently.

Avoid animated scrolling by default

Smooth scrolling can clarify movement. It can also cause discomfort or delay.

Respect reduced-motion preferences. Navigation should still work when animation is disabled.

Do not require JavaScript merely for fragment navigation. Native behaviour provides a dependable baseline.

Test browser history behaviour

Fragment navigation can add history entries. Back and forward controls should return predictably.

Custom scroll scripts may replace or push state differently. Test the intended navigation sequence.

Avoid trapping users between automatic fragment changes. State should reflect deliberate actions.

Test direct page loads

Paste the complete fragment URL into a fresh browser tab. Do not rely on same-page tests.

Use a cold or private session when practical. Cached fonts and images can hide shifts.

Confirm page load, target visibility, focus experience, and usable surrounding context.

Test keyboard navigation

1. Tab toward the source link.
2. Confirm visible focus.
3. Activate it using Enter.
4. Confirm the target becomes visible.
5. Continue tabbing from the new position.
6. Use browser Back.
7. Confirm the source position returns.

Visual scrolling alone does not prove a coherent keyboard experience. Continue after arrival.

Test screen reader navigation

Listen to source link wording and arrival context. Confirm the section heading is understandable.

Check whether focus or reading position changes helpfully. Browser and assistive combinations may differ.

Use native headings as targets where practical. They provide useful structural context.

Test mobile navigation

Activate links with touch at narrow widths. Check header overlap and late layout shifts.

Rotate the device and repeat. Responsive header height can alter target visibility.

Test long translated headings. Wrapped target labels can change the useful offset.

Test copied URLs

Copy the final browser address and share it into another application. Open that exact value.

Some messaging tools can trim punctuation or encode characters. Simple fragments reduce this risk.

Confirm analytics parameters remain intact when required. The fragment should still follow them.

Maintain an anchor inventory

Important recurring fragments deserve a small inventory. Record page, id, purpose, and known consumers.

Do not catalogue every temporary section. Focus on anchors used in navigation, campaigns, support, or documentation.

Assign change ownership. The inventory should trigger review before section deletion.

Audit anchors after structural edits

Moving a block usually preserves its id. Duplicating, converting, or replacing it may not.

Search source and public HTML for known identifiers. Test dependent links afterwards.

Check table-of-contents order after rearrangement. Links should reflect the document’s current sequence.

Audit anchors after pattern changes

Synced pattern updates can add or remove anchors across many pages. Duplicate ids may appear locally.

Avoid fixed ids inside repeated patterns unless each page contains one instance.

Test multiple instances on one page. Reusability assumptions often fail there.

Audit anchors after theme changes

Theme changes can alter sticky headers, margins, smooth scrolling, and target outlines.

The ids may remain correct while arrival becomes unusable. Test representative fragment URLs.

Fix global scroll behaviour at the theme layer. Avoid patching every post.

Diagnose a link that does nothing

1. Confirm the destination includes a hash.
2. Confirm the identifier matches exactly.
3. Check case and hyphens.
4. Inspect the public element id.
5. Check for duplicate ids.
6. Disable scroll scripts on staging.
7. Retest the complete public URL.

WordPress can validate the URL format without confirming the target exists. Inspect the destination.

Diagnose the wrong target

Search the rendered page for duplicate ids. A copied pattern is a common source.

Remove or rename the accidental duplicate. Preserve the established target where external links exist.

Clear caches and retest. Old markup can survive after editor correction.

Diagnose hidden target headings

Check sticky-header overlap, negative margins, collapsed containers, and late page movement.

Use temporary outlines during diagnosis. Confirm the browser reached the correct element.

Apply a stable theme-level scroll margin. Remove diagnostic styling afterwards.

Diagnose fragments removed by redirects

Test the full source URL and observe the final browser address. Some redirect logic may drop fragments.

Fix redirect behaviour where possible. Update internal sources toward the final direct URL.

Campaign services can add another redirect layer. Test the exact published link.

Know when anchor links add little

Short pages rarely need jump navigation. Ordinary scrolling keeps reading linear and predictable.

A table of contents with two links adds more interface than value.

This is the honest weak case. Add fragments only for real navigation needs.

Use the anchor-link checklist

1. Choose a meaningful target block.
2. Use one stable lowercase identifier.
3. Keep every page id unique.
4. Add the exact matching fragment.
5. Use descriptive source text.
6. Preserve published identifiers.
7. Account for sticky headers.
8. Test direct page loads.
9. Test keyboard and screen readers.
10. Test mobile and zoom.
11. Audit after structural changes.
12. Document high-value shared fragments.

Frequently asked questions

The verdict

Core HTML Anchor controls cover ordinary page jumps. Try free tools for complex navigation. Then compare the $299 lifetime suite when several Pro blocks fit maintained sites.