Skip to main content

IP Infusion Documentation: Google Search Remediation Plan

Prepared by: Mighty Digital
For: IP Infusion Technical Publications
Date: April 2026
Status: Draft for Review

Executive Summary​

Unintended legacy documentation URLs from docs.ipinfusion.com (the Digital Ocean/Legacy server) have been indexed by Google and are surfacing in search results alongside—and sometimes instead of—the preferred CURRENT documentation at documentation.ipinfusion.com. This document analyzes the problem, prioritizes remediation actions, and provides detailed technical recommendations, resource links, and a proposed division of labor between IP Infusion and Mighty Digital.

The two primary goals are:

  1. Remove or suppress specific legacy URLs from the Google Search index
  2. Curate and steer search results toward preferred, current documentation links

1. Understanding the Two Servers​

Legacy ServerCurrent Server
Domaindocs.ipinfusion.comdocumentation.ipinfusion.com
HostingDigital Ocean (Mighty Digital managed)Hosted MadCap Flare service
URL Patterndocs.ipinfusion.com/service-provider/index.html#page/OcNOS-SP/...documentation.ipinfusion.com/ocnos-sp-layer-2-7.0/Content/Home.htm
Control LevelFull (file system, Nginx config, custom scripting)Dependent on MadCap Flare platform
Primary ActionDeindex, redirect, restrictOptimize, signal authority

The Legacy server is fully under Mighty Digital's control. This is where the most powerful technical interventions can be made. The Current server is hosted on a third-party platform (MadCap Flare), which limits direct server-level changes, though page-level metadata and sitemap management may still be accessible.

2. Root Cause Analysis​

Before remediating, it is important to understand how legacy URLs entered the Google index. Likely causes include:

  • Google Programmable Search Engine (PSE): If a PSE was previously configured with docs.ipinfusion.com as a source, Googlebot may have followed and indexed those pages as part of normal crawling. Investigate whether a PSE still references the legacy domain.
  • External inbound links: If third-party sites, forums, vendor documentation, or older IP Infusion marketing pages linked to docs.ipinfusion.com, Googlebot will have followed those links and indexed the destination pages.
  • No robots.txt or permissive crawling rules: If the legacy server has no robots.txt (or an overly permissive one), Googlebot has had unrestricted access to all content.
  • Sitemaps submitted or discoverable: If an XML sitemap referencing legacy URLs was ever submitted to Google Search Console, those URLs were explicitly invited into the index.

Action item: Audit the Google Search Console account for docs.ipinfusion.com to check submitted sitemaps, crawl history, and coverage reports.

3. Inventorying Legacy URLs in the Google Index​

Before removing anything, you need to know what is indexed. This is the necessary first step.

3.1 Google Search Operators​

Use Google's site: operator to enumerate indexed legacy URLs:

site:docs.ipinfusion.com
site:docs.ipinfusion.com/service-provider
site:docs.ipinfusion.com/sp-6.3.3-configuration-guide

Record results in a spreadsheet, noting: URL, page title, approximate version (e.g., 6.3, 6.3.3), and whether a corresponding current URL exists. This becomes your master remediation inventory.

3.2 Google Search Console Coverage Report​

In Google Search Console (GSC), navigate to Index > Pages for the docs.ipinfusion.com property (if verified). The coverage report shows all URLs Google has crawled and indexed, including those it chose not to index. Export this list.

GSC Documentation: Google Search Console Help Center
Coverage Report Guide: Understand the Index Coverage report

3.3 Third-Party Crawl Tools​

Supplement GSC data with a full crawl of docs.ipinfusion.com using one of these tools:

  • Screaming Frog SEO Spider (free up to 500 URLs, paid for larger sites): Crawls the site and exports all discovered URLs, response codes, redirect chains, and meta tags. screaming frog.co.uk
  • Sitebulb: Similar crawler with visual reporting. sitebulb.com
  • Ahrefs or Semrush Site Audit: Can also reveal which legacy URLs have external backlinks pointing to them (important for redirect planning). ahrefs.com / semrush.com

3.4 LLM/AI Search Audit​

Since LLMs like ChatGPT are already surfacing incorrect legacy URLs (as shown in the example in the project brief), manually test prompts that your users are likely to ask:

  • "OcNOS Path MTU IPv6 configuration"
  • "IP Infusion OcNOS SP 6.3 documentation"
  • "OcNOS OSPFv3 configuration guide"

Catalog which URLs appear, note the version, and check whether they are legacy or current. This helps prioritize which URLs to remediate first based on actual user impact.

4. Removing Legacy URLs from the Google Index​

Use a layered approach. No single technique is sufficient on its own; they work together and reinforce each other over time.

4.1 Layer 1: Immediate Suppression — Google Search Console Removal Tool​

What it does: Hides specific URLs from Google Search results for approximately 180 days (6 months). It does not permanently remove them from the index.

When to use it: For the highest-priority legacy URLs surfacing right now. Use this first for immediate relief while permanent solutions are implemented.

How to use it:

  1. Log in to Google Search Console for docs.ipinfusion.com
  2. Navigate to Removals (left sidebar)
  3. Click New Request → Temporarily remove URL
  4. Enter individual URLs, or use "Remove all URLs with this prefix" for entire path patterns (e.g., /sp-6.3.3-configuration-guide/)

⚠️ Important: The Removals tool is a temporary measure only. Without follow-up permanent actions (Layers 2 and 3 below), removed URLs will reappear after 180 days.

Official documentation: Google Removals Tool Help

4.2 Layer 2: Permanent Deindexing — noindex Meta Tags​

What it does: Instructs Googlebot to remove a page from the index permanently on its next crawl. This is the most reliable permanent deindexing signal available.

Since the Legacy server is a flat HTML file system on Digital Ocean, noindex tags can be injected in two ways:

Option A — Add to individual HTML files: Insert into the <head> section of each file to be deindexed:

<meta name="robots" content="noindex, nofollow">

Option B — Inject via Nginx HTTP header (more scalable): Configure the Nginx server to emit an X-Robots-Tag header for specific path patterns:

location ~* ^/(sp-6\.3\.3|sp-6\.2|sp-5\.) {
    add_header X-Robots-Tag "noindex, nofollow";
}

This approach is highly scalable because it applies to entire version directories without modifying individual HTML files. It requires access to the Nginx configuration on the Digital Ocean server.

Google's official guidance on noindex: Remove Your Site Info from Google
X-Robots-Tag specification: Robots meta tag, data-nosnippet, and X-Robots-Tag

⚠️ Critical note: Do NOT use robots.txt Disallow as the primary deindexing method. Google dropped support for noindex directives inside robots.txt in 2019. A Disallow rule prevents crawling, but pages already in the index will remain there because Googlebot can no longer see the noindex tag to process the removal.

4.3 Layer 3: HTTP Status Codes — 410 Gone​

For legacy content that has no successor and should simply cease to exist:

410 Gone tells Google definitively that the resource has been permanently removed and will not return. This is stronger than a 404 (which could be interpreted as a temporary absence) and signals to Google to remove the URL from the index faster.

Configure Nginx to return 410 for deprecated version paths:

# Return 410 for EOL documentation versions
location ~* ^/(sp-5\.|sp-4\.) {
    return 410;
}

Reference: Google on 404 and 410 status codes

4.4 Layer 4: Robots.txt — Block Future Crawling​

While robots.txt alone will not remove already-indexed content, it prevents Googlebot from re-crawling the legacy server and discovering new or re-appearing content.

Add or update /robots.txt on docs.ipinfusion.com:

User-agent: *
Disallow: /

# Allow Googlebot to crawl the robots.txt itself (automatic)

To block by specific version directories only (less aggressive):

User-agent: *
Disallow: /sp-6.3.3-configuration-guide/
Disallow: /sp-6.2/
Disallow: /service-provider/

Note: A full Disallow: / is appropriate if the Legacy server is intended to serve no public traffic and all content has migrated or been deprecated.
Google Robots.txt documentation: Robots.txt Introduction and Guide
Robots.txt tester (GSC): Available under Settings in Search Console

4.5 Layer 5: 301 Redirects to Current Content​

For legacy URLs that correspond to valid, current content on documentation.ipinfusion.com, the ideal solution is a permanent 301 redirect. This:

  • Sends users arriving on old links to the correct destination
  • Transfers any residual SEO "link equity" from the old URL to the new one
  • Signals to Google that the canonical version is now at the new location

Nginx map-based redirect approach (scalable for large URL sets):

# Load a map file of old -> new URL mappings
map $request_uri $new_url {
    include /etc/nginx/redirects/ipi_docs_redirects.map;
    default "";
}

server {
    listen 80;
    server_name docs.ipinfusion.com;

    if ($new_url != "") {
        return 301 $new_url;
    }

    # Fallback: redirect unmapped URLs to the documentation home
    location / {
        return 301 https://documentation.ipinfusion.com/home/Content/LibraryPages/Library.htm;
    }
}

The .map file would contain entries like:

/sp-6.3.3-configuration-guide/OcNOS-SP/Layer3-Config/OSPF_Configuration.054.07.html  https://documentation.ipinfusion.com/ocnos-sp-layer-2-7.0/Content/OSPF-equivalent.htm;

For content without a direct equivalent: Redirect to the product documentation home page or the nearest category landing page.

Nginx redirect documentation: Creating NGINX Rewrite Rules
DigitalOcean Nginx redirect tutorial: How To Create Temporary and Permanent Redirects with Nginx

5. Curating Search Results — Steering Users to Preferred Links​

Removing bad links is only half the job. The other half is ensuring the right content ranks well and is clearly authoritative.

5.1 XML Sitemaps for the Current Server​

Ensure that documentation.ipinfusion.com has a well-structured, up-to-date XML sitemap submitted to Google Search Console. The sitemap should:

  • Include only preferred, current release URLs
  • Exclude deprecated or non-canonical pages
  • Be updated automatically when new content is published (MadCap Flare may support this natively)
  • Use <lastmod> tags to signal freshness

Submit the sitemap at: GSC → Sitemaps

Sitemap documentation: Build and submit a sitemap

5.2 Canonical Tags​

If any legacy content remains accessible (not yet 410'd or redirected), use canonical tags to point Google to the preferred version:

<link rel="canonical" href="https://documentation.ipinfusion.com/ocnos-sp-layer-2-7.0/Content/Home.htm">

This can be added to legacy HTML files or emitted via the Nginx Link header.

5.3 On-Page SEO for Current Documentation​

Work upstream in the MadCap Flare publishing workflow (or inject via post-processing) to improve on-page signals on documentation.ipinfusion.com:

  • Title tags: Should follow the pattern: [Topic] — OcNOS [Version] [Product] Documentation | IP Infusion. Avoid generic titles like "Untitled" or "Page 1."
  • Meta descriptions: 150–160 characters summarizing the content; should include product name, version, and key topic.
  • Heading structure: H1 should match the page topic; H2/H3 for sub-sections.
  • Structured data / Schema.org: Consider adding TechArticle or Article schema markup to documentation pages to improve rich snippet eligibility.

Google's SEO Starter Guide: Search Engine Optimization (SEO) Starter Guide

5.4 Google Search Console — Performance Monitoring​

Use the Performance report in GSC for documentation.ipinfusion.com to:

  • Identify which queries are driving traffic to current docs
  • Identify queries where the legacy site still outranks current docs (these are priority targets)
  • Track impressions and click-through rates over time to measure remediation progress

GSC Performance report: Search Console Performance Report

5.5 Sponsored Search / Google Ads (Paid Placement)​

The project brief raises the question of paid search as part of the strategy. This is a viable, though ancillary, tactic.

When it makes sense:

  • For high-traffic navigational queries (e.g., "OcNOS documentation," "IP Infusion SP 7.0 config guide") where legacy URLs consistently outrank current ones in the interim
  • As a short-term bridge while organic remediation takes effect (Google deindexing can take weeks to months)

Approach:

  • Bid on exact-match branded queries: [ip infusion ocnos documentation], [ocnos sp configuration guide]
  • Use ad copy that clearly indicates the link goes to official, current documentation
  • Link directly to preferred version landing pages

Caveats:

  • Paid ads are a recurring expense; organic remediation is the durable solution
  • Ads do not appear in all contexts (mobile apps, AI-powered search, etc.)

Google Ads Help: Get started with Google Ads

6. LLM Search and Generative AI Optimization​

As demonstrated in the project brief (the ChatGPT example surfacing an incorrect docs.ipinfusion.com URL), LLM-powered search tools are increasingly surfacing documentation links. Traditional SEO techniques help here too, but there are emerging LLM-specific strategies.

6.1 llms.txt Standard​

The llms.txt file is a proposed open standard (proposed by Jeremy Howard of Answer.AI in September 2024) for helping LLMs discover and navigate website content efficiently. Placed at the root of a domain (e.g., https://documentation.ipinfusion.com/llms.txt), it provides a structured Markdown index of a site's key pages.

Format example:

# IP Infusion OcNOS Documentation

> Official technical documentation for OcNOS network operating system 
> by IP Infusion. Covers Service Provider, Data Center, and carrier-grade 
> networking configuration.

## Latest Releases
- [OcNOS SP 7.0 Home](https://documentation.ipinfusion.com/ocnos-sp-layer-2-7.0/Content/Home.htm): Service Provider edition, version 7.0
- [OcNOS DC 7.0 Home](https://documentation.ipinfusion.com/ocnos-dc-7.0/Content/Home.htm): Data Center edition, version 7.0

## Configuration Guides
- [Layer 3 Configuration](https://documentation.ipinfusion.com/...): Routing protocols, OSPF, BGP, MPLS
- [Layer 2 Configuration](https://documentation.ipinfusion.com/...): VLANs, spanning tree, switching

Current state of adoption: As of early 2026, major platforms including Anthropic, Cloudflare, and Stripe have implemented llms.txt. GPTBot has been observed fetching llms.txt files. However, no major AI platform has officially confirmed that llms.txt directly influences citation results. Adoption is low-risk and low-effort (a few hours of implementation), and the potential upside increases as LLM-based search grows.

Official llms.txt proposal: llmstxt.org
Mintlify's llms.txt implementation guide: Simplifying docs for AI with /llms.txt
SE Ranking research on adoption: Does LLMs.txt impact AI visibility?

Recommendation: Implement llms.txt on documentation.ipinfusion.com pointing exclusively to current, preferred content. This is a lightweight investment with forward-looking upside.

6.2 Markdown Versions of Documentation Pages​

The llms.txt standard also recommends making page content available in clean Markdown at the same URL with .md appended (e.g., documentation.ipinfusion.com/ocnos-sp-7.0/Content/Home.htm.md). This makes content easily ingestible by AI tools without HTML parsing overhead.

Whether this is feasible depends on MadCap Flare's output capabilities. Investigate whether Flare can export Markdown alongside HTML, or whether a post-processing step could convert HTML pages to Markdown.

6.3 Allow AI Crawlers in robots.txt​

Ensure that the robots.txt on documentation.ipinfusion.com does not inadvertently block AI crawlers such as:

  • GPTBot (OpenAI/ChatGPT)
  • ClaudeBot (Anthropic)
  • PerplexityBot
  • Google-Extended (Google's AI training crawler)

These crawlers respect robots.txt disallow rules. If you want LLMs to cite your current documentation, these bots must be able to reach it.

7. Typesense Search — Comparison and Fine-Tuning​

The existing Typesense self-hosted search solution provides a curated, harmonized search experience across both servers. It can also serve as a data source for evaluating and fine-tuning remediation efforts.

Recommended uses:

  • Benchmarking: Run identical queries through Typesense, Google Search, and LLM tools (ChatGPT, Perplexity, etc.) side-by-side. Document which URLs surface for each. This creates a measurable baseline and tracks improvement over time.
  • Priority ranking in Typesense: Ensure that Typesense results are weighted to boost current-version content over legacy. Review Typesense ranking rules and apply version-based boosts.
  • Coverage gap detection: If a query returns good results in Typesense but poor results in Google, it indicates a Google-specific indexing or authority issue—useful for diagnosing problem areas.

Typesense documentation: Typesense Docs
Typesense ranking and relevance tuning: Ranking and Relevance

8. EOL/EOS Content Policy​

The project brief raises whether older content can be removed from docs.ipinfusion.com beyond certain End-of-Life / End-of-Support dates. This is a high-value, high-leverage action.

Recommendation: Establish a formal documentation retention policy:

  1. Define EOL/EOS dates for each OcNOS release version (this is an IP Infusion internal decision)
  2. For EOL content: Return HTTP 410 Gone from the Nginx server for all pages in that version's directory. This is the clearest signal to Google that the content is permanently gone.
  3. For EOS content that still has some value: Redirect to either the nearest equivalent current page or a "version archived" landing page that clearly states the content is no longer maintained and links to the current release.
  4. Do not simply delete files: Deleting files without configuring Nginx to return 404/410 will result in generic server errors rather than clean deindexing signals.

9. Figuring Out the Source: Google Programmable Search Engine​

The project brief specifically asks whether the legacy Google Programmable Search (PSE) could be the source of indexed URLs.

Investigation steps:

  1. Log in to the Google PSE control panel at programmablesearchengine.google.com
  2. Check whether any existing PSEs include docs.ipinfusion.com as an indexed site
  3. If found: Remove docs.ipinfusion.com from the PSE's site list and verify the PSE is pointing only to documentation.ipinfusion.com

Note that PSE primarily controls results within the custom search widget, not organic Google Search. However, Googlebot may have discovered and indexed linked pages through PSE-connected sitemaps or through crawling patterns associated with PSE configuration. Removing the legacy domain from any PSE is still a recommended hygiene step.

10. Implementation Roadmap​

Phase 1 — Immediate (Week 1–2)​

TaskOwnerNotes
Verify/set up GSC properties for both domainsIP Infusiondocs.ipinfusion.com and documentation.ipinfusion.com
Run site:docs.ipinfusion.com audit; export URL inventoryMighty DigitalUse GSC + Screaming Frog
Submit GSC Removal requests for top 20–50 highest-visibility legacy URLsMighty Digital180-day suppression while permanent work proceeds
Investigate Google PSE for legacy domain referencesIP Infusion / Mighty DigitalRemove if found
Manual LLM search audit (ChatGPT, Perplexity, Google AI)IP Infusion Tech PubsCatalog incorrect URL citations

Phase 2 — Short-Term (Weeks 3–6)​

TaskOwnerNotes
Implement Nginx noindex X-Robots-Tag headers on Legacy server for deprecated version directoriesMighty DigitalHighest-impact permanent deindexing action
Implement Nginx 410 Gone for confirmed EOL versionsMighty DigitalRequires EOL list from IP Infusion
Add/update robots.txt on docs.ipinfusion.com to block crawling of deprecated pathsMighty Digital
Build redirect map file: legacy URL → current URLIP Infusion Tech Pubs + Mighty DigitalTech Pubs identifies correct destinations; MDG implements
Submit updated XML sitemap for documentation.ipinfusion.com to GSCIP Infusion / Flare adminEnsure only current content included

Phase 3 — Medium-Term (Weeks 7–12)​

TaskOwnerNotes
Implement Nginx 301 redirect rules on Legacy serverMighty DigitalUsing map file from Phase 2
Implement llms.txt on documentation.ipinfusion.comMighty DigitalCurrent versions and key topics only
On-page SEO improvements for CURRENT server (titles, meta descriptions)IP Infusion Tech Pubs / Mighty DigitalMay require Flare template changes
Typesense side-by-side benchmark vs Google vs LLMMighty DigitalCreate regular reporting cadence
Evaluate Google Ads for priority branded queriesIP Infusion (decision) / Mighty Digital (execution)If organic signals still lagging

Phase 4 — Ongoing​

TaskOwnerFrequency
Monitor GSC coverage and performance reportsMighty DigitalMonthly
Re-run site:docs.ipinfusion.com to track index reductionMighty DigitalMonthly
Manual LLM audit of priority queriesIP Infusion Tech PubsQuarterly
Review and update redirect map for newly deprecated contentBothPer release cycle
Update llms.txt with new releasesMighty DigitalPer release cycle

11. Measurement Criteria​

Define success clearly before beginning so progress can be objectively tracked.

MetricBaseline (Measure Now)Target
# of docs.ipinfusion.com URLs in Google indexTBD (run site: audit)Reduce by 90%+ for EOL versions; 100% for confirmed deprecated content
# of incorrect legacy URLs surfaced by LLM queries (test set)TBD (manual audit)Reduce to 0 for test query set
Google Search impressions for docs.ipinfusion.comTBD (GSC Performance)Reduce to near 0
Google Search impressions for documentation.ipinfusion.comTBD (GSC Performance)Stable or increasing
Click-through rate on current docsTBD (GSC)Improving trend
Redirect success rate on Legacy serverN/A95%+ of legacy URLs redirect to valid current destination

12. Division of Labor Summary​

ResponsibilityIP Infusion Tech PubsMighty Digital
EOL/EOS version list and dates✅ PrimaryAdvise
URL mapping (legacy → current)✅ PrimaryAssist with pattern matching
GSC property verification and access✅ PrimaryAssist
GSC Removal requestsApprove✅ Execute
Nginx configuration (robots.txt, noindex headers, 410, 301 redirects)—✅ Execute
llms.txt creation and maintenanceContent authority✅ Implement
Typesense relevance tuningReview✅ Execute
On-page SEO in MadCap Flare templates✅ Primary (Flare access)Advise
Google Ads campaign (if approved)Approve budget✅ Manage
Reporting and measurementReview✅ Produce

13. Key Resources and References​

Google Official Documentation​

Nginx Configuration​

SEO Deindexing Guides​

LLM Search and llms.txt​

Tooling​

This document is a living plan and should be updated as the inventory audit is completed, EOL decisions are finalized, and implementation phases proceed.