Build an internal linking strategy with Claude or ChatGPT

Publishing a useful page does little for visitors who cannot find it. The same problem appears when a guide attracts search traffic but gives readers no clear route to the comparison, explanation, or product they need next.

An internal linking strategy connects those steps. It helps people move through your site and helps search engines discover pages and understand relationships between them. The objective is a useful structure, not the largest possible link count.

Use Claude or ChatGPT to review the page inventory and propose contextual paths, with RankParse checking the public pages behind the recommendations. Start with one valuable topic or customer journey. Map its pages, repair missing connections, and check whether the resulting paths work. Once you can maintain that small system, expand it across the site.

Bring the agent an inventory, not just a domain

Use the RankParse connector setup for Claude or ChatGPT, then attach a crawl export containing source URLs, destinations, and anchor text, plus your CMS page inventory. Include page titles and the relevant source text or browsing access where available. A sitemap can help identify URLs, but it does not describe all internal links.

The distinction matters: RankParse's get_page_seo checks individual public pages, including canonical information and link counts. It does not supply a complete internal-link graph or prove that a page has no incoming internal links. The crawl export provides that working map; the agent's job is to compare it with the inventory and propose useful connections.

Give the assistant a bounded assignment:

Use my attached CMS inventory and crawl export to improve internal
linking for [topic]. Start with these ten priority destination URLs.
Find candidate source pages that answer an earlier or related reader
question. Use RankParse page SEO checks to verify the candidate URLs'
current canonical and page signals. Use supplied text or available
browsing to verify context; if you cannot read it, mark context unverified.

Return a table: source URL, reader need, destination URL, proposed anchor,
exact suggested sentence and placement, evidence, and confidence.
List possible orphan pages separately, with the limits of the crawl.
Do not invent existing links from link counts or backlink data.
Do not publish edits. Flag redirects and canonical mismatches for review.

Validate two or three suggestions before reviewing the entire batch. Open the source paragraph and destination together. Reject links whose context the assistant cannot substantiate, anchors that promise more than the target delivers, and links proposed only because two pages share a keyword.

Once the suggestions meet that standard, use the workflow below to finish the map. Your output is an editorial change list a page owner can implement, with an evidence trail for each link. You can ask the agent to draft the changes, but the read-only connector does not publish them to your CMS.

Turn the inventory into a checked editing queue

The most useful RankParse call happens after the assistant has found a plausible source and destination, but before an editor spends time rewriting the sentence. It can reveal that the proposed destination moved, declares another canonical, or currently returns an error page.

Build a packet with two different kinds of rows

Attach a page inventory and a link-edge export as separate files. For one topic, start with ten destinations and no more than twenty candidate source pages. Include:

Save crawl scope, exclusions, JavaScript settings, and whether navigation links are included. If the export separates body links from navigation, retain that column. A source already linking through the menu might still benefit from a contextual link, but the agent should explain the distinct reader benefit.

Use get_sitemap only when you need an additional inventory cross-check. It returns URLs declared in sitemap files, not edges between pages. Preserve truncated and the list of fetched child sitemaps so an incomplete response does not become a false orphan diagnosis. On a larger site, a CMS export scoped to the topic is often a better starting inventory than a limited domain sitemap response.

Stage 1: select candidates from supplied context

From the attached topic inventory, link edges and excerpts, propose up to
five source-destination pairs. For each, cite a source paragraph and the
reader question the destination answers. Check whether the supplied
crawl already contains that exact edge. Classify each pair as new,
existing contextual link, navigation-only, or unknown from this export.
Do not draft a sentence for a source with no verified excerpt.

Keep URLs as observed until a redirect or canonical check establishes a relationship. Do not silently collapse query parameters, languages, or trailing-slash variants while joining files. Preserve both the original URL and any proposed preferred URL in the queue.

Stage 2: use RankParse to check both ends

For the unique source and destination URLs in those five pairs, call get_page_seo. Reuse one result when several pairs share the same page. Ask the assistant to retain the documented response fields, not just a “healthy” label:

Use get_page_seo for the unique URLs in the candidate pairs. Return
status_code, final_url, canonical.url, robots.raw, title.text, headings.h1,
and links.internal. Compare them with our inventory and supplied excerpts.
Hold pairs with unexpected responses, redirects or canonical mismatches
for review. Do not interpret links.internal as a list of destinations.
Do not treat meta robots alone as proof of full indexing eligibility.

The title and headings help confirm that the fetched page matches the intended resource. They cannot establish that the full article answers the promised question: headings.h2 contains only the first ten H2s, and the checker does not return full body copy. Use the supplied excerpts or browser inspection for that judgment.

A robots.index value describes the parsed meta tag, not Google's indexed state or all possible HTTP-header directives. An intentionally excluded utility page can still be a useful destination. Label its role accurately rather than excluding every such link automatically.

Stage 3: draft only the cleared changes

For the reviewed pairs, return an editor-ready change sheet. Include the
original source paragraph, replacement paragraph, exact anchor text,
preferred destination, reason for the link, owner and verification step.
Keep blocked pairs in a separate hold queue with the missing evidence.
Reuse existing wording where possible. Do not invent product capabilities
or promise a download unless the destination actually provides one.

Scope instructions help the assistant stay focused; they are not an enforced spending cap. Review its proposed URL list and tool activity before expanding the batch. With a small team, the page owner can approve the five rows in one sitting. For a large library, assign batches by topic and have an editor approve the first few rows before processing another batch.

Worked example: a plausible link that needs correction

This is an illustrative packet and outcome, not a measured RankParse run. A payroll deadlines guide contains the supplied sentence, “Keep recurring payment and filing dates in a shared calendar.” The inventory proposes /resources/payroll-calendar-2025 as its next step, while the crawl export shows no observed edge from this source to that URL.

After the editor confirms the resource, the change sheet can say:

Source: payroll deadlines guide, “Recurring deadlines” section. Replacement: “Use the payroll calendar template to keep recurring payment and filing dates in one place.” Anchor: “payroll calendar template.” Destination: the verified current calendar URL. Acceptance: the published paragraph contains an ordinary anchor to that URL, and the template opens successfully.

Keep the redirect finding in the evidence notes. It explains why the destination changed between the initial proposal and the final edit. If the resource turned out to be a product signup instead of a usable template, hold the row and revise the promise; a matching title would not rescue a misleading link.

Give each important page a distinct job

List the pages involved in a single topic. For each, write a sentence describing the reader's task and the page's role.

A payroll software company might have a guide to payroll deadlines, a payroll calendar template, a software comparison, and a product page. These pages support different decisions. Linking them thoughtfully makes sense; forcing the same product pitch into every paragraph does not.

Before adding links, check whether two pages do essentially the same job. Similar keywords alone do not prove duplication. Two guides may serve different audiences or different stages of a task. Read them and inspect the search results they target. If they provide interchangeable answers, decide which page should own the topic and whether consolidation is justified.

Your SEO competitor analysis can help identify missing reader needs, but competitors' folder structures are not automatically a good fit for your business.

Make the inventory practical. Record the canonical URL, reader task, page owner, current internal links, and likely next step. A simple spreadsheet is enough for a small site.

Find pages your crawl cannot see

Run a crawl from the homepage and compare the discovered URLs with an independent list from the CMS, sitemap, or analytics. URLs present in the inventory but absent from the crawl are candidates for orphan-page investigation.

Check those candidates manually. A crawl can miss pages because of its settings, authentication, excluded directories, or JavaScript handling. Some pages intentionally sit outside public navigation, such as campaign landing pages. Absence from one crawl does not establish that a page has no internal links anywhere.

For pages that should attract search traffic, ask:

• Is there a relevant category or topic page that should link here?
• Do existing articles raise a question this page answers?
• Is the page linked only from another forgotten page?
• Does navigation require an interaction that hides the destination from a basic crawler?

Resolve discovery issues alongside the technical SEO audit checklist. An internal link cannot compensate for an accidental noindex, a broken destination, or a canonical pointing somewhere inappropriate.

Crawl depth can identify inconvenient paths, but avoid a universal rule such as “every page must be within three clicks.” A large reference library has different needs from a small service site. Important, frequently needed pages should be easy to reach from relevant starting points.

Choose source pages by relevance before traffic

A high-traffic page is useful only if its readers have a reason to follow the proposed link. Begin by finding pages where the destination naturally answers an unresolved question.

Search your own site for relevant terms and synonyms. Review the surrounding paragraphs, not just the matching phrase. A page mentioning “payroll” in passing may be less useful than a low-traffic guide explaining how to set a payroll schedule.

Evaluate each candidate using three questions:

1. Context: does the source explain why someone would need the destination?
2. Continuity: does the destination deliver on the link's promise?
3. Visibility: can readers encounter the link at the moment it becomes useful?

Use existing traffic and the source page's visibility as secondary prioritization signals. A frequently visited page can expose the new path to more people. A modestly visited page may provide the better contextual connection.

Do not assume you can calculate the exact ranking value passed by an individual link. Third-party authority metrics and internal link counts are imperfect planning aids, not a precise model of Google's weighting.

Write anchors that tell readers what happens next

Anchor text should describe the destination in the surrounding sentence. “Download the monthly payroll calendar” communicates more than “click here.” It also establishes an expectation the destination must meet.

Natural wording is more useful than forcing every link to use an exact target keyword. Different sentences may call for “payroll deadline checklist,” “check the filing dates,” or the name of a specific resource. The language can vary while remaining accurate.

Avoid these common shortcuts:

For accessibility, inspect links in context and consider whether their purpose remains understandable when scanned. Avoid relying only on color to indicate that text is clickable. Those design checks belong with the site's accessibility work, but they directly affect whether people can use the paths you create.

Build a small, useful set of paths

Use navigation, topic hubs, and contextual links for different jobs. Navigation exposes stable destinations people repeatedly need. A topic hub organizes a substantial collection. Contextual links answer a question at the point where the reader encounters it.

You do not need a hub for every handful of posts. Create one when the collection needs an overview, sequence, or meaningful grouping. A useful hub explains how the resources differ; a page containing only a long undifferentiated list can be hard to use.

Consider this illustrative linking plan for a payroll website:

An agent can draft this table from the inventory, then check the source paragraphs before you approve each row. These are proposed paths, not measured results. Notice that some links lead to education and others to a commercial page. Choose the destination that answers the next question.

Check the reverse journey too. Someone landing on the template may need the underlying explanation. A concise link back to the deadlines guide can provide that context without duplicating the full guide.

Implement links in a way crawlers and people can use

For ordinary navigation, use standard anchor links with an href. Point to the preferred destination URL directly when practical, avoiding unnecessary redirect chains and broken URLs.

Check the destination's current state before publishing. A link to an intentionally excluded utility page can still serve users, but it should not be counted as a link to an indexable search landing page. Links to noncanonical variants can also make your preferred URL signals less consistent.

Do not add nofollow to normal internal links as a routine attempt to channel ranking signals elsewhere. Design the structure around meaningful pages and relationships. Neither hiding useful paths nor adding dozens of repetitive links gives you precise control over ranking outcomes.

For a large site, automated suggestions can locate candidates. Require an editor to check the source sentence, anchor, destination, and reader need. Bulk insertion based only on matching words can create misleading links at scale.

Recover when the assistant cannot verify the map

If you have no crawler export, supply a manually checked list of source-destination links for the small topic. The assistant can still propose additions from page excerpts and RankParse checks. Mark existing-edge status unknown until a person checks it, and avoid sitewide orphan or depth claims.

If a public-page fetch returns a challenge or thin JavaScript shell, keep the result as a fetch limitation. Supply the visible paragraph and confirm the destination in a browser; do not let the assistant rewrite around the challenge page's title. Private previews cannot be checked through the public-page tool, so use an editor's preview review and repeat public checks after publication.

If the assistant proposes get_internal_links, redirect it to the supplied crawl. That API-key tool is currently a placeholder returning not_yet_available, and it is not part of the secure OAuth connector. Neither backlink reports nor internal-link counts replace the source-to-destination map needed here.

When a recommendation duplicates an existing link, ask whether the new placement serves a different task. If it does not, remove the recommendation. This is a useful reduction in the edit queue, not a failed audit.

Verify the path, then evaluate the result

After publishing, recrawl the affected source pages. Confirm that links exist, resolve successfully, and point to the intended URLs. Open representative pages on mobile and desktop to check placement and usability.

Keep a small change log: source, destination, anchor, reason, implementation date, and owner. This makes later cleanup possible and helps avoid attributing every search movement to a linking change.

Measure two different outcomes:

• Structural outcome: fewer unintended orphans, direct links to preferred URLs, and clearer paths from relevant sections.
• Visitor and search outcome: use of the links, destination engagement or conversions where measurement permits, and changes in search visibility over a suitable period.

A ranking increase after adding links is an observation, not proof that links alone caused it. Other content changes, competition, seasonality, and Google updates may coincide. Use Search Console content analysis to examine query and page groups without relying on one average position number.

Publish the first reviewed batch, verify its exact source-destination edges, and assign ownership. Add the same check to publishing and retirement workflows so new pages enter the structure and removed pages leave it cleanly.