Internal Link Decay After a Redesign: A Before-and-After Diagnostic

A practical method for finding valuable live pages that lost internal-link support after a redesign, using graph deltas, template cohorts, performance data and crawl evidence.

A redesign can leave a page live, indexable and technically accessible while quietly removing much of the internal support that helped users and search engines reach it. A category template changes, a navigation module is simplified or a related-content component disappears. The affected URLs still return 200 responses, but their position in the site’s internal structure has weakened.

That problem is easy to miss if the investigation only looks for orphan pages or counts links in the current site state. The more useful question is: which valuable pages lost meaningful internal-link support between the old and new versions of the site?

This article sets out a before-and-after diagnostic. It treats internal linking as a changing directed graph, compares matched pre- and post-redesign crawls, segments affected URLs into meaningful cohorts, and reconciles structural changes with traffic, search visibility, crawl activity and implementation evidence. The aim is not to restore every historical link or maximise link counts. It is to identify material losses and restore appropriate support for pages that still matter.

Define internal-link decay as a change, not a current-state condition

A page with two internal links is not automatically weak. It may be a valuable destination linked from a strong, relevant hub. A page with 50 links may have poor support if those links come from repeated utility modules or irrelevant pages.

For this investigation, define internal-link decay as a material reduction in a live page’s internal support between two site states. That support can include:

• the number of unique internal source pages;
• the diversity of referring templates, page roles, taxonomies or locales;
• access from relevant category or editorial hubs;
• the page’s position in important navigation paths;
• the number and quality of contextual or related-content links;
• changes in link destinations, anchors or link classes.

This definition matters because a page can experience meaningful decay while remaining technically non-orphaned. A reduction in links may also be harmless if the old links were duplicated or low-relevance and have been replaced by stronger routes.

Google describes crawlable links as one way it discovers pages and understands the relationship between linked pages. That supports treating link changes as a discovery and structure question, but it does not establish a universal link count or prove that losing a particular link will reduce rankings. See Google’s documentation on crawlable links.

Start with a controlled comparison window

The quality of the diagnosis depends on defining what “before” and “after” mean. A redesign is often released in stages, and the release date may not match the date when search engines recrawled the relevant templates.

Record four dates where possible:

• Baseline crawl: the last comparable crawl before the change.
• Release or transition period: the date range during which templates, menus or categories changed.
• Post-release crawl: a crawl after the relevant templates have been deployed and rendered.
• Performance windows: the pre- and post-periods used for traffic, search and crawl comparisons.

Do not choose a window simply because it produces the clearest apparent decline. Check whether promotions, seasonal demand, algorithm updates, pricing changes, inventory changes, content edits, platform releases or rendering incidents occurred at the same time.

A useful design often includes a longer pre-period and post-period rather than a single week on either side of launch. The correct length depends on site size, crawl frequency, seasonality and how quickly the redesign was rolled out. If the release was staged, retain the treatment date for each affected cohort instead of treating the whole domain as exposed on one day.

Before interpreting performance movement, plot the affected cohort’s pre-period trend. If clicks or rankings were already declining before the redesign, a post-release fall should not automatically be attributed to internal-link loss.

Build comparable pre- and post-redesign graphs

Represent each crawl as a directed graph:

• each normalised, stable URL is a node;
• each internal source-to-destination relationship is a directed edge;
• edge attributes describe the link’s location, anchor, rendered state and other available properties;
• node attributes describe the page’s template, type, role, locale, taxonomy and commercial value.

Where several identical links occur on one source page, decide whether to represent them as one source-to-destination relationship with an occurrence count or as separate observations. Keep that decision consistent between crawls.

The graph is an observation of the site, not a transparent copy of the graph processed by a search engine. Coverage, rendering, canonicalisation, blocked resources and extraction rules all affect what appears in the dataset. The pre- and post-crawls therefore need compatible settings.

At minimum, standardise:

• URL normalisation, including trailing slashes, parameters, fragments and protocol;
• canonical URL handling and redirect treatment;
• crawl scope, depth and URL exclusions;
• source HTML and rendered HTML settings;
• internal-link definitions, including whether links to redirected or non-canonical URLs are retained as separate diagnostics;
• treatment of repeated modules, such as whether one footer relationship is counted once per source page rather than once per rendered occurrence.

Run extraction QA before calculating deltas. A parser change, rendering failure or crawl-depth difference can create apparent link decay that exists only in the dataset. Compare raw and rendered extraction on representative templates, inspect a sample of lost edges manually and check whether the crawl reached the same URL universe.

Calculate graph deltas that explain what changed

For every stable URL present in both states, calculate changes in its internal support. Useful measures include:

• Unique inlink delta: the number of distinct internal source pages linking to the URL before and after.
• Referring-template delta: the number of distinct source templates, such as category, editorial, product or location pages.
• Page-role and taxonomy delta: whether the URL lost links from important business or topical groups.
• Hub reachability: whether the page remains reachable from relevant category, service or editorial hubs.
• Path-depth change: whether the shortest or typical route from key entry points became longer.
• Link-class delta: whether contextual, breadcrumb, related-content, listing, navigation or footer links disappeared.
• Destination and anchor changes: whether a module now points to a different page or uses materially different anchor relationships.

Raw inlink counts and graph-centrality measures are different things. A simple count treats each source similarly. A measure such as PageRank models the structure using a particular mathematical formulation and can help identify weakened hubs or destinations. It remains a diagnostic model, not a direct representation of Google’s ranking system, and should not be translated into a guaranteed ranking effect.

Consider a software company whose redesign replaces an editorial hub with a smaller set of navigation links. A guide may lose 18 editorial and related-content sources but retain two links from its product taxonomy. It is not orphaned, yet its source diversity and topical routes have changed substantially. That is a more useful finding than “the guide has two inlinks”. This is an illustrative example, not measured client data.

Where link classes can be inferred reliably, keep them separate. A lost breadcrumb link, a removed contextual recommendation and a deleted footer link are not interchangeable. The classification does not imply that search engines assign a known universal weight to each class; it makes the change easier to interpret.

Segment the affected URLs into cohorts

After calculating URL-level deltas, group affected pages to determine whether the redesign created a systematic problem.

Useful cohort dimensions include:

• template and page type;
• page role, such as category, product, guide, comparison or support page;
• taxonomy, topic or business unit;
• locale and market;
• commercial value, conversion contribution or strategic priority;
• historical organic traffic and impression level;
• crawl frequency or log-observed activity;
• release wave or deployment date.

Look for patterns such as:

• all URLs using one new category template losing breadcrumb and related-content links;
• one locale retaining the old navigation while other markets receive the new version;
• older guides losing links from listing pages after a taxonomy restructure;
• high-value pages losing diverse sources while low-value pages retain broad exposure;
• one template showing a graph delta that is absent from otherwise similar control templates.

Cohort analysis prevents isolated anomalies from being mistaken for redesign effects. It also turns a large URL list into an implementation question: which component or template change affected which group of pages?

Reconcile the graph with search and crawl evidence

A graph delta establishes structural change. It does not establish a ranking or traffic effect. Add time-aligned evidence from several sources.

Organic performance

Compare clicks, impressions, CTR, average position, landing pages and query groups for affected cohorts. Search Console supports comparisons of these measures, but URL-level interpretation is constrained by canonical assignment, aggregation, anonymisation, sampling and changing search-result layouts. See Google’s Search Console performance report documentation.

Use a matched control where possible. An unaffected template, locale or page-role cohort can show whether affected pages changed differently after the release. Match controls using pre-release characteristics such as traffic, impressions, page age, content type and historical trend. Do not use a control group that was exposed to the same redesign or has substantial spillover from it.

A difference-in-differences design can strengthen the comparison when treated and control cohorts have credible parallel pre-trends and consistent measurement. In practice, redesigns are compound interventions, so this method is not automatically valid. Staged treatment, spillovers, serial correlation and unrelated releases can all weaken the estimate. Treat the result as an attribution aid rather than proof of a search-ranking mechanism.

Crawl and log evidence

Use server logs, where available, to compare Googlebot requests for affected and control cohorts. A fall in requests can corroborate reduced discovery or recrawl activity, particularly when it aligns with the graph change and the affected templates.

It is not proof of causality. Crawl behaviour is influenced by popularity, freshness, perceived quality, relevance, server capacity and the size of the URL inventory. Crawler requests also show activity, not every URL known to a search engine or every link it evaluated. Google’s crawl-budget documentation describes several factors that affect crawling, so log activity should be treated as corroborating evidence rather than a causal measure. See Google’s crawl-budget guidance.

Implementation evidence

Connect the affected graph edges to deployment evidence. Confirm whether the relevant menu, breadcrumb, listing, related-content or template component changed in the release. Inspect representative URLs in source and rendered output, and record whether the change was consistent across the cohort.

The strongest practical diagnosis usually has four parts:

1. the graph change is real and tied to an implementation;
2. the affected cohort changed after the release and had credible pre-period behaviour;
3. crawl or log evidence is directionally consistent where available;
4. competing technical and demand explanations have been checked.

Even this evidence pattern remains observational unless the comparison design supports stronger causal inference.

Exclude alternative explanations before prioritising a fix

Internal-link loss is only one possible explanation for a post-redesign decline. For each high-priority URL or cohort, check:

• canonical changes or conflicting canonical signals;
• new noindex directives or robots restrictions;
• redirects, status-code changes and destination mismatches;
• content, title, structured-data or template changes beyond linking;
• rendering failures that hide links or page content;
• material changes in speed, availability or server response;
• search-demand shifts, seasonality, promotions and competitor activity;
• search-result layout or search-system changes;
• crawl extraction errors, blocked resources or inconsistent URL normalisation.

A page may also retain strong external links, direct demand, sitemap discovery or alternative internal routes. In that case, reduced internal support may be structurally real without producing a measurable search decline.

Conversely, a performance decline may have started before the redesign. Event-study views or pre-trend checks help distinguish a redesign-related change from an existing problem that the release merely coincided with.

Prioritise remediation by value and evidence

Do not rank fixes by the number of lost links alone. A useful prioritisation framework combines:

• commercial value: revenue, leads, strategic importance or conversion contribution;
• support loss: magnitude and quality of lost sources, hubs and link classes;
• corroboration: aligned performance, crawl or implementation evidence;
• diagnostic confidence: how well alternative explanations have been excluded;
• implementation effort: the complexity, risk and reach of the proposed change.

A high-value page that lost access from several relevant category and editorial hubs should usually outrank a low-value page that lost repeated footer links. A template-level defect may deserve priority even when individual URLs have modest losses, because one implementation can restore appropriate support across an entire cohort.

Remediation might involve restoring a relevant breadcrumb, rebuilding a category relationship, adding an appropriately targeted related-content component or correcting a template destination. It should not recreate every historical relationship. Taxonomies, products, services and business priorities may have changed, so the target is a coherent current architecture.

For organisations that need to connect diagnosis to implementation, the work may sit across technical SEO, SEO implementation and SEO engineering. These links are service resources rather than evidence for the diagnostic method. The recommendation should identify the component, cohort and expected graph change, not simply ask for “more internal links”.

Validate the repair as another before-and-after test

Validation should repeat the diagnostic rather than stop when the template has been deployed.

1. Recrawl the affected templates and a representative sample of URLs.
2. Repeat URL normalisation, link extraction and graph calculations using comparable settings.
3. Confirm that the intended edges, link classes and source diversity have returned or improved.
4. Inspect source and rendered HTML on representative pages.
5. Check canonical, noindex, redirects and other technical signals again.
6. Review server-log crawling and Search Console performance over an appropriate period.
7. Compare the treated cohort with its control and annotate further releases or demand changes.

Set expectations carefully. A graph repair may improve discoverability or structural support without producing an immediate or measurable traffic recovery. Recovery can be delayed, partial or absent because the original decline had another cause, the page is no longer competitive, demand has changed or the new architecture is still not appropriate.

Conclusion: diagnose the lost relationship, not the link count

The useful distinction is between a page that has few links today and a page whose internal support materially deteriorated after a known site change. The latter is a longitudinal problem.

Compare stable pre- and post-redesign graphs, separate link classes, segment changes by template and business role, and test the structural evidence against performance, crawl activity and implementation records. Use controls where possible, challenge the diagnosis with alternative explanations and prioritise pages where value, support loss and evidence align.

The practical outcome is not a historical replica of the old site. It is a better-supported current architecture: one that gives valuable pages appropriate routes from relevant hubs and makes the effect of the next redesign measurable rather than speculative.