fix: linkchecker include filter port mismatch (#2242)

* initial commit; fixed anchor links on internal docs pages

* add back in absolute paths for links in code comments

* fix: update linkchecker include filter to match server port 1314

PR #1629 changed the Hugo server to port 1314 but forgot to update
the --include filter, which still matched port 1313. This caused all
links to be excluded, making the checker a no-op (0 checked, 82277 excluded).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Fix url rewrite regex so images are not impacted

* Fix links from non-documentation pages

* Fix broken links

* more broken links

* more broken links

* broken link

* Add srcset width descriptor to .lycheeignore

* Ignore URLs that contain a % character

* Anchor regex so it matches the entire URL

---------

Co-authored-by: kanungle <neil.kanungo@gmail.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Abdon Pijpelink <abdon.pijpelink@qdrant.com>

qdrant-landing/content/documentation/tutorials-operations/create-snapshot.md

@@ -23,7 +23,7 @@ in this tutorial to create and download snapshots. When you [Restore from snapsh
 
 ## Prerequisites
 
-Let's assume you already have a running Qdrant instance or a cluster. If not, you can follow the [installation guide](/documentation/guides/installation/) to set up a local Qdrant instance or use [Qdrant Cloud](https://cloud.qdrant.io/) to create a cluster in a few clicks.
+Let's assume you already have a running Qdrant instance or a cluster. If not, you can follow the [installation guide](/documentation/operations/installation/) to set up a local Qdrant instance or use [Qdrant Cloud](https://cloud.qdrant.io/) to create a cluster in a few clicks.
 
 Once the cluster is running, let's install the required dependencies:
 
@@ -151,7 +151,7 @@ Qdrant exposes an HTTP endpoint to request creating a snapshot, but we can also
 Our setup consists of 3 nodes, so we need to call the endpoint **on each of them** and create a snapshot on each node. While using Python SDK, that means creating a separate client instance for each node.
 
 
-<aside role="status">You may get a timeout error, if the collection size is big. You can trigger the snapshot process in the background, without awaiting for the result, by using <code>wait=false</code> parameter. You can always <a href="/documentation/concepts/snapshots/#list-snapshot">list all the snapshots through the API</a> later on.</aside>
+<aside role="status">You may get a timeout error, if the collection size is big. You can trigger the snapshot process in the background, without awaiting for the result, by using <code>wait=false</code> parameter. You can always <a href="/documentation/operations/snapshots/#list-snapshot">list all the snapshots through the API</a> later on.</aside>
 
 
 ```python
@@ -276,11 +276,11 @@ curl -X POST 'https://node-2.my-cluster.com:6333/collections/test_collection_imp
 ```
 
 
-**Important:** We selected `priority=snapshot` to make sure that the snapshot is preferred over the data stored on the node. You can read mode about the priority in the [documentation](/documentation/concepts/snapshots/#snapshot-priority).
+**Important:** We selected `priority=snapshot` to make sure that the snapshot is preferred over the data stored on the node. You can read mode about the priority in the [documentation](/documentation/operations/snapshots/#snapshot-priority).
 
 Apart from Snapshots, Qdrant also provides the [Qdrant Migration Tool](https://github.com/qdrant/migration) that supports: 
 - Migration between Qdrant Cloud instances. 
 - Migrating vectors from other providers into Qdrant.
 - Migrating from Qdrant OSS to Qdrant Cloud.
 
-Follow our [migration guide](/documentation/database-tutorials/migration/) to learn how to effectively use the Qdrant Migration tool. 
+Follow our [migration guide](/documentation/tutorials-operations/migration/) to learn how to effectively use the Qdrant Migration tool. 

qdrant-landing/content/documentation/tutorials-operations/embedding-model-migration.md

@@ -29,7 +29,7 @@ Re-embedding requires access to the original data used to create the embeddings.
 
 The solution outlined in this tutorial only works for upsert operations. If you use deletes or partial updates, it is necessary to pause those operations during the migration or implement additional logic to handle them.
 
-This tutorial assumes you use [Qdrant Cloud Inference](/documentation/concepts/inference/#qdrant-cloud-inference) to generate vector embeddings. If you manage your own embedding infrastructure, you can apply the same principles, but you will need to adapt the code examples to use your embedding service.
+This tutorial assumes you use [Qdrant Cloud Inference](/documentation/inference/#qdrant-cloud-inference) to generate vector embeddings. If you manage your own embedding infrastructure, you can apply the same principles, but you will need to adapt the code examples to use your embedding service.
 
 ## Step 1: Create a New Collection
 
@@ -86,9 +86,9 @@ The migration process reads the points from the old collection, re-embeds them u
 
 Breaking down this code step by step:
 
-- Data is read from the old collection in batches of 100 points using a [scroll](/documentation/concepts/points/#scroll-points). The `last_offset` variable keeps track of the scroll position in the collection.
+- Data is read from the old collection in batches of 100 points using a [scroll](/documentation/manage-data/points/#scroll-points). The `last_offset` variable keeps track of the scroll position in the collection.
 - For each batch of points, the process re-embeds the vectors using the new embedding model. It assumes that the original text used for embedding is stored in the payload under the key `text`.
-- With the re-embedded vectors, it upserts the points into the new collection, keeping the original IDs and payloads. The upserts use [insert-only mode](/documentation/concepts/points/#update-mode) to ensure that a point is only inserted if it does not already exist in the new collection. This prevents overwriting newer updates from the regular update service.
+- With the re-embedded vectors, it upserts the points into the new collection, keeping the original IDs and payloads. The upserts use [insert-only mode](/documentation/manage-data/points/#update-mode) to ensure that a point is only inserted if it does not already exist in the new collection. This prevents overwriting newer updates from the regular update service.
 
 This kind of migration process can take some time, and the offset can be stored in a persistent way, so you can resume the migration process in case of a failure. You can use a database, a file, or any other persistent storage to keep track of the last offset. Having said that, because the conditional upserts would not overwrite any points in the new collection, you could safely restart the migration process from the beginning if needed.
 
@@ -96,7 +96,7 @@ This kind of migration process can take some time, and the offset can be stored
 
 Once the migration process is complete, and all the points from the old collection are re-embedded and stored in the new collection, you can roll out a configuration change of the backend application. There are two key changes you have to make:
 
-1. **The collection name**. Switch this from the old collection to the new collection. If you're using a [collection alias](/documentation/concepts/collections/#collection-aliases), switch the alias to point to the new collection.
+1. **The collection name**. Switch this from the old collection to the new collection. If you're using a [collection alias](/documentation/manage-data/collections/#collection-aliases), switch the alias to point to the new collection.
 2. **The embedding model**. Switch this from the old embedding model to the new embedding model.
 
 If these values are hardcoded in your application, you will need to change them directly in the code and deploy a new version of your application. For example, if your current search code looks like this:

qdrant-landing/content/documentation/tutorials-operations/migration.md

@@ -19,7 +19,7 @@ In this tutorial, we will learn how to use the migration tool and walk through a
 
 ## Why use this instead of Qdrant’s Native Snapshotting?
 
-Qdrant supports [snapshot-based backups](https://qdrant.tech/documentation/concepts/snapshots/), which are low-level disk operations built for same-cluster recovery or local backups. These snapshots:
+Qdrant supports [snapshot-based backups](/documentation/operations/snapshots/), which are low-level disk operations built for same-cluster recovery or local backups. These snapshots:
 
 * Require snapshot consistency across nodes.   
 * Can be hard to port across machines or cloud zones. 
@@ -91,7 +91,7 @@ When the migration is complete, you will see the new collection on Qdrant with a
 
 The **Qdrant Migration Tool** makes data transfer across vector database instances effortless. Whether you're moving between cloud regions, upgrading from self-hosted to Qdrant Cloud, or switching from other databases such as Pinecone, this tool saves you hours of manual effort. [Try it today](https://github.com/qdrant/migration).
 
-For detailed per-provider migration guides (Pinecone, Weaviate, Milvus, Elasticsearch, pgvector), see the [Migrate to Qdrant](/documentation/migrate-to-qdrant/) section. After migrating, use the [Migration Verification Guide](/documentation/migration-verification/) to confirm data integrity and search quality.
+For detailed per-provider migration guides (Pinecone, Weaviate, Milvus, Elasticsearch, pgvector), see the [Migrate to Qdrant](/documentation/migrate-to-qdrant/) section. After migrating, use the [Migration Verification Guide](/documentation/migration-guidance/) to confirm data integrity and search quality.