diff --git a/docs-website/docs/concepts/pipelines/debugging-pipelines.mdx b/docs-website/docs/concepts/pipelines/debugging-pipelines.mdx
index 5dc8b28eb3e..3234d3a85e5 100644
--- a/docs-website/docs/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/docs/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/docs/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/docs/concepts/pipelines/visualizing-pipelines.mdx
index 95a63a02a48..78e69675d5f 100644
--- a/docs-website/docs/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/docs/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/docs/development/deployment/kubernetes.mdx b/docs-website/docs/development/deployment/kubernetes.mdx
index 929ca4a99e1..c58e5322b4c 100644
--- a/docs-website/docs/development/deployment/kubernetes.mdx
+++ b/docs-website/docs/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/docs/development/enabling-gpu-acceleration.mdx b/docs-website/docs/development/enabling-gpu-acceleration.mdx
index 9dfc2920c0f..b438ea0ba5e 100644
--- a/docs-website/docs/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/docs/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/docs/development/logging.mdx b/docs-website/docs/development/logging.mdx
index fb51f097a06..fc5bcd8f9db 100644
--- a/docs-website/docs/development/logging.mdx
+++ b/docs-website/docs/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -96,7 +96,7 @@ configure_logging(propagate=False)
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -115,7 +115,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/docs/development/tracing/logging-tracer.mdx b/docs-website/docs/development/tracing/logging-tracer.mdx
index 75294773774..dc57419bf0c 100644
--- a/docs-website/docs/development/tracing/logging-tracer.mdx
+++ b/docs-website/docs/development/tracing/logging-tracer.mdx
@@ -58,4 +58,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/docs/development/tracing/opentelemetry.mdx b/docs-website/docs/development/tracing/opentelemetry.mdx
index 8a47c81d0a6..8cf184b47ca 100644
--- a/docs-website/docs/development/tracing/opentelemetry.mdx
+++ b/docs-website/docs/development/tracing/opentelemetry.mdx
@@ -93,7 +93,7 @@ See the [`OpenTelemetryConnector` documentation page](../../pipeline-components/
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
diff --git a/docs-website/docs/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/docs/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index 5c8956337cc..c99eedd389a 100644
--- a/docs-website/docs/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/docs/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/static/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png b/docs-website/static/img/basic-logging-output.png
similarity index 100%
rename from docs-website/static/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png
rename to docs-website/static/img/basic-logging-output.png
diff --git a/docs-website/static/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg b/docs-website/static/img/colab-gpu-runtime.jpeg
similarity index 100%
rename from docs-website/static/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg
rename to docs-website/static/img/colab-gpu-runtime.jpeg
diff --git a/docs-website/static/img/2c188e9-2.0_Document_Stores_6.png b/docs-website/static/img/document-store-categories.png
similarity index 100%
rename from docs-website/static/img/2c188e9-2.0_Document_Stores_6.png
rename to docs-website/static/img/document-store-categories.png
diff --git a/docs-website/static/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png b/docs-website/static/img/hayhooks-k8s-1.png
similarity index 100%
rename from docs-website/static/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png
rename to docs-website/static/img/hayhooks-k8s-1.png
diff --git a/docs-website/static/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png b/docs-website/static/img/hayhooks-k8s-2.png
similarity index 100%
rename from docs-website/static/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png
rename to docs-website/static/img/hayhooks-k8s-2.png
diff --git a/docs-website/static/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png b/docs-website/static/img/hayhooks-k8s-3.png
similarity index 100%
rename from docs-website/static/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png
rename to docs-website/static/img/hayhooks-k8s-3.png
diff --git a/docs-website/static/img/2d00628-Untitled_2.png b/docs-website/static/img/hyde-architecture.png
similarity index 100%
rename from docs-website/static/img/2d00628-Untitled_2.png
rename to docs-website/static/img/hyde-architecture.png
diff --git a/docs-website/static/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png b/docs-website/static/img/jaeger-trace-timeline.png
similarity index 100%
rename from docs-website/static/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png
rename to docs-website/static/img/jaeger-trace-timeline.png
diff --git a/docs-website/static/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png b/docs-website/static/img/logging-tracer-console-output.png
similarity index 100%
rename from docs-website/static/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png
rename to docs-website/static/img/logging-tracer-console-output.png
diff --git a/docs-website/static/img/46a8989-Untitled.png b/docs-website/static/img/rag-pipeline.png
similarity index 100%
rename from docs-website/static/img/46a8989-Untitled.png
rename to docs-website/static/img/rag-pipeline.png
diff --git a/docs-website/static/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png b/docs-website/static/img/structured-json-logging.png
similarity index 100%
rename from docs-website/static/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png
rename to docs-website/static/img/structured-json-logging.png
diff --git a/docs-website/versioned_docs/version-2.18/concepts/document-store/choosing-a-document-store.mdx b/docs-website/versioned_docs/version-2.18/concepts/document-store/choosing-a-document-store.mdx
index 0ea6b0a9cc7..ab109a8e607 100644
--- a/docs-website/versioned_docs/version-2.18/concepts/document-store/choosing-a-document-store.mdx
+++ b/docs-website/versioned_docs/version-2.18/concepts/document-store/choosing-a-document-store.mdx
@@ -35,7 +35,7 @@ We are working on supporting all these types in Haystack.
 
 In the meantime, here’s the most recent overview of available integrations:
 
-<ClickableImage src="/img/2c188e9-2.0_Document_Stores_6.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg"/>
+<ClickableImage src="/img/document-store-categories.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg"/>
 
 #### Summary
 
diff --git a/docs-website/versioned_docs/version-2.18/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.18/concepts/pipelines/debugging-pipelines.mdx
index 8ecd9e86447..afb06f87d08 100644
--- a/docs-website/versioned_docs/version-2.18/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.18/concepts/pipelines/debugging-pipelines.mdx
@@ -113,7 +113,7 @@ tracing.enable_tracing(
 
 Here’s what the resulting log would look like when a pipeline is run:
 
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.18/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.18/concepts/pipelines/visualizing-pipelines.mdx
index 35c458f7310..f70fe980ef5 100644
--- a/docs-website/versioned_docs/version-2.18/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.18/concepts/pipelines/visualizing-pipelines.mdx
@@ -79,7 +79,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 
 This is an example of what a pipeline graph may look like:
 
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.18/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.18/development/deployment/kubernetes.mdx
index 91706f20851..40157522862 100644
--- a/docs-website/versioned_docs/version-2.18/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.18/development/deployment/kubernetes.mdx
@@ -57,7 +57,7 @@ spec:
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
 
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="None" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="None" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -184,7 +184,7 @@ data:
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
 
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="None" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="None" />
 
 ## Roll Out Multiple Pods
 
@@ -266,6 +266,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.18/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.18/development/enabling-gpu-acceleration.mdx
index b1bad278d70..ada85722e88 100644
--- a/docs-website/versioned_docs/version-2.18/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.18/development/enabling-gpu-acceleration.mdx
@@ -30,7 +30,7 @@ You can find more information on the [Device management](../concepts/device-mana
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
 
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.18/development/logging.mdx b/docs-website/versioned_docs/version-2.18/development/logging.mdx
index ec702ab0480..339329dbcc5 100644
--- a/docs-website/versioned_docs/version-2.18/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.18/development/logging.mdx
@@ -69,7 +69,7 @@ tracing.enable_tracing(
 
 Here’s what the resulting log would look like when a pipeline is run:
 
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -81,7 +81,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
 
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip
 Rich Formatting
@@ -102,7 +102,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
   haystack.logging.configure_logging(use_json=True)
   ```
 
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.18/development/tracing.mdx b/docs-website/versioned_docs/version-2.18/development/tracing.mdx
index c6bfa1458f7..ca75d946329 100644
--- a/docs-website/versioned_docs/version-2.18/development/tracing.mdx
+++ b/docs-website/versioned_docs/version-2.18/development/tracing.mdx
@@ -242,7 +242,7 @@ To enable content tracing, there are two options:
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
 
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
@@ -338,4 +338,4 @@ tracing.enable_tracing(
 
 Here’s what the resulting log would look like when a pipeline is run:
 
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.18/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.18/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index c01566f90f8..9212d0cb09d 100644
--- a/docs-website/versioned_docs/version-2.18/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.18/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -23,7 +23,7 @@ The HyDE method is highly useful when:
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
 
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.19/concepts/document-store/choosing-a-document-store.mdx b/docs-website/versioned_docs/version-2.19/concepts/document-store/choosing-a-document-store.mdx
index d790ff45732..63012d8e099 100644
--- a/docs-website/versioned_docs/version-2.19/concepts/document-store/choosing-a-document-store.mdx
+++ b/docs-website/versioned_docs/version-2.19/concepts/document-store/choosing-a-document-store.mdx
@@ -35,7 +35,7 @@ We are working on supporting all these types in Haystack.
 
 In the meantime, here’s the most recent overview of available integrations:
 
-<ClickableImage src="/img/2c188e9-2.0_Document_Stores_6.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg"/>
+<ClickableImage src="/img/document-store-categories.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg"/>
 
 #### Summary
 
diff --git a/docs-website/versioned_docs/version-2.19/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.19/concepts/pipelines/debugging-pipelines.mdx
index 8ecd9e86447..afb06f87d08 100644
--- a/docs-website/versioned_docs/version-2.19/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.19/concepts/pipelines/debugging-pipelines.mdx
@@ -113,7 +113,7 @@ tracing.enable_tracing(
 
 Here’s what the resulting log would look like when a pipeline is run:
 
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.19/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.19/concepts/pipelines/visualizing-pipelines.mdx
index d79ed0d6032..542ab12878b 100644
--- a/docs-website/versioned_docs/version-2.19/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.19/concepts/pipelines/visualizing-pipelines.mdx
@@ -78,7 +78,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 
 This is an example of what a pipeline graph may look like:
 
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.19/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.19/development/deployment/kubernetes.mdx
index 91706f20851..40157522862 100644
--- a/docs-website/versioned_docs/version-2.19/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.19/development/deployment/kubernetes.mdx
@@ -57,7 +57,7 @@ spec:
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
 
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="None" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="None" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -184,7 +184,7 @@ data:
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
 
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="None" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="None" />
 
 ## Roll Out Multiple Pods
 
@@ -266,6 +266,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.19/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.19/development/enabling-gpu-acceleration.mdx
index b1bad278d70..ada85722e88 100644
--- a/docs-website/versioned_docs/version-2.19/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.19/development/enabling-gpu-acceleration.mdx
@@ -30,7 +30,7 @@ You can find more information on the [Device management](../concepts/device-mana
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
 
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.19/development/logging.mdx b/docs-website/versioned_docs/version-2.19/development/logging.mdx
index c354a795c37..75418b4b0f2 100644
--- a/docs-website/versioned_docs/version-2.19/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.19/development/logging.mdx
@@ -69,7 +69,7 @@ tracing.enable_tracing(
 
 Here’s what the resulting log would look like when a pipeline is run:
 
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -81,7 +81,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
 
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -101,7 +101,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
   haystack.logging.configure_logging(use_json=True)
   ```
 
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.19/development/tracing.mdx b/docs-website/versioned_docs/version-2.19/development/tracing.mdx
index c6bfa1458f7..ca75d946329 100644
--- a/docs-website/versioned_docs/version-2.19/development/tracing.mdx
+++ b/docs-website/versioned_docs/version-2.19/development/tracing.mdx
@@ -242,7 +242,7 @@ To enable content tracing, there are two options:
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
 
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
@@ -338,4 +338,4 @@ tracing.enable_tracing(
 
 Here’s what the resulting log would look like when a pipeline is run:
 
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.19/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.19/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index c01566f90f8..9212d0cb09d 100644
--- a/docs-website/versioned_docs/version-2.19/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.19/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -23,7 +23,7 @@ The HyDE method is highly useful when:
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
 
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.20/concepts/document-store/choosing-a-document-store.mdx b/docs-website/versioned_docs/version-2.20/concepts/document-store/choosing-a-document-store.mdx
index 24fe2267630..d777e9dd508 100644
--- a/docs-website/versioned_docs/version-2.20/concepts/document-store/choosing-a-document-store.mdx
+++ b/docs-website/versioned_docs/version-2.20/concepts/document-store/choosing-a-document-store.mdx
@@ -34,7 +34,7 @@ We can group vector databases into five categories, from more specialized to gen
 We are working on supporting all these types in Haystack.
 
 In the meantime, here’s the most recent overview of available integrations:
-<ClickableImage src="/img/2c188e9-2.0_Document_Stores_6.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
+<ClickableImage src="/img/document-store-categories.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
 
 #### Summary
 
diff --git a/docs-website/versioned_docs/version-2.20/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.20/concepts/pipelines/debugging-pipelines.mdx
index dbf26e2074e..4fba868826b 100644
--- a/docs-website/versioned_docs/version-2.20/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.20/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.20/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.20/concepts/pipelines/visualizing-pipelines.mdx
index 27425a8caf3..b09c2483644 100644
--- a/docs-website/versioned_docs/version-2.20/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.20/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.20/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.20/development/deployment/kubernetes.mdx
index 159201c4271..4f3d609333f 100644
--- a/docs-website/versioned_docs/version-2.20/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.20/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.20/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.20/development/enabling-gpu-acceleration.mdx
index 80e4efea0eb..8ed8de0d05f 100644
--- a/docs-website/versioned_docs/version-2.20/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.20/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.20/development/logging.mdx b/docs-website/versioned_docs/version-2.20/development/logging.mdx
index e9c5cf01450..16fd340e48c 100644
--- a/docs-website/versioned_docs/version-2.20/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.20/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -79,7 +79,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -98,7 +98,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.20/development/tracing.mdx b/docs-website/versioned_docs/version-2.20/development/tracing.mdx
index c0f7e381d87..0f54e7f3622 100644
--- a/docs-website/versioned_docs/version-2.20/development/tracing.mdx
+++ b/docs-website/versioned_docs/version-2.20/development/tracing.mdx
@@ -238,7 +238,7 @@ To enable content tracing, there are two options:
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
@@ -333,4 +333,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.20/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.20/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index 7fc6847fddc..95136a8a4dd 100644
--- a/docs-website/versioned_docs/version-2.20/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.20/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.21/concepts/document-store/choosing-a-document-store.mdx b/docs-website/versioned_docs/version-2.21/concepts/document-store/choosing-a-document-store.mdx
index 24fe2267630..d777e9dd508 100644
--- a/docs-website/versioned_docs/version-2.21/concepts/document-store/choosing-a-document-store.mdx
+++ b/docs-website/versioned_docs/version-2.21/concepts/document-store/choosing-a-document-store.mdx
@@ -34,7 +34,7 @@ We can group vector databases into five categories, from more specialized to gen
 We are working on supporting all these types in Haystack.
 
 In the meantime, here’s the most recent overview of available integrations:
-<ClickableImage src="/img/2c188e9-2.0_Document_Stores_6.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
+<ClickableImage src="/img/document-store-categories.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
 
 #### Summary
 
diff --git a/docs-website/versioned_docs/version-2.21/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.21/concepts/pipelines/debugging-pipelines.mdx
index dbf26e2074e..4fba868826b 100644
--- a/docs-website/versioned_docs/version-2.21/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.21/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.21/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.21/concepts/pipelines/visualizing-pipelines.mdx
index 0d5c0cd5fed..135688e0f52 100644
--- a/docs-website/versioned_docs/version-2.21/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.21/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.21/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.21/development/deployment/kubernetes.mdx
index 159201c4271..4f3d609333f 100644
--- a/docs-website/versioned_docs/version-2.21/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.21/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.21/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.21/development/enabling-gpu-acceleration.mdx
index 80e4efea0eb..8ed8de0d05f 100644
--- a/docs-website/versioned_docs/version-2.21/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.21/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.21/development/logging.mdx b/docs-website/versioned_docs/version-2.21/development/logging.mdx
index e9c5cf01450..16fd340e48c 100644
--- a/docs-website/versioned_docs/version-2.21/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.21/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -79,7 +79,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -98,7 +98,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.21/development/tracing.mdx b/docs-website/versioned_docs/version-2.21/development/tracing.mdx
index c0f7e381d87..0f54e7f3622 100644
--- a/docs-website/versioned_docs/version-2.21/development/tracing.mdx
+++ b/docs-website/versioned_docs/version-2.21/development/tracing.mdx
@@ -238,7 +238,7 @@ To enable content tracing, there are two options:
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
@@ -333,4 +333,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.21/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.21/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index b1c1829a5a5..9dbed7f775d 100644
--- a/docs-website/versioned_docs/version-2.21/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.21/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.22/concepts/document-store/choosing-a-document-store.mdx b/docs-website/versioned_docs/version-2.22/concepts/document-store/choosing-a-document-store.mdx
index 24fe2267630..d777e9dd508 100644
--- a/docs-website/versioned_docs/version-2.22/concepts/document-store/choosing-a-document-store.mdx
+++ b/docs-website/versioned_docs/version-2.22/concepts/document-store/choosing-a-document-store.mdx
@@ -34,7 +34,7 @@ We can group vector databases into five categories, from more specialized to gen
 We are working on supporting all these types in Haystack.
 
 In the meantime, here’s the most recent overview of available integrations:
-<ClickableImage src="/img/2c188e9-2.0_Document_Stores_6.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
+<ClickableImage src="/img/document-store-categories.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
 
 #### Summary
 
diff --git a/docs-website/versioned_docs/version-2.22/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.22/concepts/pipelines/debugging-pipelines.mdx
index dbf26e2074e..4fba868826b 100644
--- a/docs-website/versioned_docs/version-2.22/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.22/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.22/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.22/concepts/pipelines/visualizing-pipelines.mdx
index 0d5c0cd5fed..135688e0f52 100644
--- a/docs-website/versioned_docs/version-2.22/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.22/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.22/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.22/development/deployment/kubernetes.mdx
index 159201c4271..4f3d609333f 100644
--- a/docs-website/versioned_docs/version-2.22/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.22/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.22/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.22/development/enabling-gpu-acceleration.mdx
index 80e4efea0eb..8ed8de0d05f 100644
--- a/docs-website/versioned_docs/version-2.22/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.22/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.22/development/logging.mdx b/docs-website/versioned_docs/version-2.22/development/logging.mdx
index e9c5cf01450..16fd340e48c 100644
--- a/docs-website/versioned_docs/version-2.22/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.22/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -79,7 +79,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -98,7 +98,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.22/development/tracing.mdx b/docs-website/versioned_docs/version-2.22/development/tracing.mdx
index c0f7e381d87..0f54e7f3622 100644
--- a/docs-website/versioned_docs/version-2.22/development/tracing.mdx
+++ b/docs-website/versioned_docs/version-2.22/development/tracing.mdx
@@ -238,7 +238,7 @@ To enable content tracing, there are two options:
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
@@ -333,4 +333,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.22/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.22/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index b1c1829a5a5..9dbed7f775d 100644
--- a/docs-website/versioned_docs/version-2.22/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.22/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.23/concepts/document-store/choosing-a-document-store.mdx b/docs-website/versioned_docs/version-2.23/concepts/document-store/choosing-a-document-store.mdx
index 24fe2267630..d777e9dd508 100644
--- a/docs-website/versioned_docs/version-2.23/concepts/document-store/choosing-a-document-store.mdx
+++ b/docs-website/versioned_docs/version-2.23/concepts/document-store/choosing-a-document-store.mdx
@@ -34,7 +34,7 @@ We can group vector databases into five categories, from more specialized to gen
 We are working on supporting all these types in Haystack.
 
 In the meantime, here’s the most recent overview of available integrations:
-<ClickableImage src="/img/2c188e9-2.0_Document_Stores_6.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
+<ClickableImage src="/img/document-store-categories.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
 
 #### Summary
 
diff --git a/docs-website/versioned_docs/version-2.23/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.23/concepts/pipelines/debugging-pipelines.mdx
index dbf26e2074e..4fba868826b 100644
--- a/docs-website/versioned_docs/version-2.23/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.23/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.23/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.23/concepts/pipelines/visualizing-pipelines.mdx
index 0d5c0cd5fed..135688e0f52 100644
--- a/docs-website/versioned_docs/version-2.23/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.23/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.23/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.23/development/deployment/kubernetes.mdx
index 159201c4271..4f3d609333f 100644
--- a/docs-website/versioned_docs/version-2.23/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.23/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.23/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.23/development/enabling-gpu-acceleration.mdx
index 80e4efea0eb..8ed8de0d05f 100644
--- a/docs-website/versioned_docs/version-2.23/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.23/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.23/development/logging.mdx b/docs-website/versioned_docs/version-2.23/development/logging.mdx
index e9c5cf01450..16fd340e48c 100644
--- a/docs-website/versioned_docs/version-2.23/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.23/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -79,7 +79,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -98,7 +98,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.23/development/tracing.mdx b/docs-website/versioned_docs/version-2.23/development/tracing.mdx
index c0f7e381d87..0f54e7f3622 100644
--- a/docs-website/versioned_docs/version-2.23/development/tracing.mdx
+++ b/docs-website/versioned_docs/version-2.23/development/tracing.mdx
@@ -238,7 +238,7 @@ To enable content tracing, there are two options:
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
@@ -333,4 +333,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.23/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.23/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index b1c1829a5a5..9dbed7f775d 100644
--- a/docs-website/versioned_docs/version-2.23/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.23/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.24/concepts/document-store/choosing-a-document-store.mdx b/docs-website/versioned_docs/version-2.24/concepts/document-store/choosing-a-document-store.mdx
index 24fe2267630..d777e9dd508 100644
--- a/docs-website/versioned_docs/version-2.24/concepts/document-store/choosing-a-document-store.mdx
+++ b/docs-website/versioned_docs/version-2.24/concepts/document-store/choosing-a-document-store.mdx
@@ -34,7 +34,7 @@ We can group vector databases into five categories, from more specialized to gen
 We are working on supporting all these types in Haystack.
 
 In the meantime, here’s the most recent overview of available integrations:
-<ClickableImage src="/img/2c188e9-2.0_Document_Stores_6.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
+<ClickableImage src="/img/document-store-categories.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
 
 #### Summary
 
diff --git a/docs-website/versioned_docs/version-2.24/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.24/concepts/pipelines/debugging-pipelines.mdx
index dbf26e2074e..4fba868826b 100644
--- a/docs-website/versioned_docs/version-2.24/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.24/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.24/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.24/concepts/pipelines/visualizing-pipelines.mdx
index 0d5c0cd5fed..135688e0f52 100644
--- a/docs-website/versioned_docs/version-2.24/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.24/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.24/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.24/development/deployment/kubernetes.mdx
index 159201c4271..4f3d609333f 100644
--- a/docs-website/versioned_docs/version-2.24/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.24/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.24/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.24/development/enabling-gpu-acceleration.mdx
index 80e4efea0eb..8ed8de0d05f 100644
--- a/docs-website/versioned_docs/version-2.24/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.24/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.24/development/logging.mdx b/docs-website/versioned_docs/version-2.24/development/logging.mdx
index e9c5cf01450..16fd340e48c 100644
--- a/docs-website/versioned_docs/version-2.24/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.24/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -79,7 +79,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -98,7 +98,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.24/development/tracing.mdx b/docs-website/versioned_docs/version-2.24/development/tracing.mdx
index c0f7e381d87..0f54e7f3622 100644
--- a/docs-website/versioned_docs/version-2.24/development/tracing.mdx
+++ b/docs-website/versioned_docs/version-2.24/development/tracing.mdx
@@ -238,7 +238,7 @@ To enable content tracing, there are two options:
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
@@ -333,4 +333,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.24/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.24/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index b1c1829a5a5..9dbed7f775d 100644
--- a/docs-website/versioned_docs/version-2.24/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.24/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.25/concepts/document-store/choosing-a-document-store.mdx b/docs-website/versioned_docs/version-2.25/concepts/document-store/choosing-a-document-store.mdx
index 24fe2267630..d777e9dd508 100644
--- a/docs-website/versioned_docs/version-2.25/concepts/document-store/choosing-a-document-store.mdx
+++ b/docs-website/versioned_docs/version-2.25/concepts/document-store/choosing-a-document-store.mdx
@@ -34,7 +34,7 @@ We can group vector databases into five categories, from more specialized to gen
 We are working on supporting all these types in Haystack.
 
 In the meantime, here’s the most recent overview of available integrations:
-<ClickableImage src="/img/2c188e9-2.0_Document_Stores_6.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
+<ClickableImage src="/img/document-store-categories.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
 
 #### Summary
 
diff --git a/docs-website/versioned_docs/version-2.25/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.25/concepts/pipelines/debugging-pipelines.mdx
index dbf26e2074e..4fba868826b 100644
--- a/docs-website/versioned_docs/version-2.25/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.25/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.25/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.25/concepts/pipelines/visualizing-pipelines.mdx
index 0d5c0cd5fed..135688e0f52 100644
--- a/docs-website/versioned_docs/version-2.25/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.25/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.25/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.25/development/deployment/kubernetes.mdx
index 159201c4271..4f3d609333f 100644
--- a/docs-website/versioned_docs/version-2.25/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.25/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.25/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.25/development/enabling-gpu-acceleration.mdx
index 80e4efea0eb..8ed8de0d05f 100644
--- a/docs-website/versioned_docs/version-2.25/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.25/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.25/development/logging.mdx b/docs-website/versioned_docs/version-2.25/development/logging.mdx
index e9c5cf01450..16fd340e48c 100644
--- a/docs-website/versioned_docs/version-2.25/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.25/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -79,7 +79,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -98,7 +98,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.25/development/tracing.mdx b/docs-website/versioned_docs/version-2.25/development/tracing.mdx
index 589c6387662..91f946dbc7d 100644
--- a/docs-website/versioned_docs/version-2.25/development/tracing.mdx
+++ b/docs-website/versioned_docs/version-2.25/development/tracing.mdx
@@ -260,7 +260,7 @@ To enable content tracing, there are two options:
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
@@ -355,4 +355,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.25/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.25/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index b1c1829a5a5..9dbed7f775d 100644
--- a/docs-website/versioned_docs/version-2.25/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.25/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.26/concepts/document-store/choosing-a-document-store.mdx b/docs-website/versioned_docs/version-2.26/concepts/document-store/choosing-a-document-store.mdx
index 24fe2267630..d777e9dd508 100644
--- a/docs-website/versioned_docs/version-2.26/concepts/document-store/choosing-a-document-store.mdx
+++ b/docs-website/versioned_docs/version-2.26/concepts/document-store/choosing-a-document-store.mdx
@@ -34,7 +34,7 @@ We can group vector databases into five categories, from more specialized to gen
 We are working on supporting all these types in Haystack.
 
 In the meantime, here’s the most recent overview of available integrations:
-<ClickableImage src="/img/2c188e9-2.0_Document_Stores_6.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
+<ClickableImage src="/img/document-store-categories.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
 
 #### Summary
 
diff --git a/docs-website/versioned_docs/version-2.26/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.26/concepts/pipelines/debugging-pipelines.mdx
index dbf26e2074e..4fba868826b 100644
--- a/docs-website/versioned_docs/version-2.26/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.26/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.26/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.26/concepts/pipelines/visualizing-pipelines.mdx
index 0d5c0cd5fed..135688e0f52 100644
--- a/docs-website/versioned_docs/version-2.26/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.26/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.26/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.26/development/deployment/kubernetes.mdx
index fb306ecf468..cb00825a592 100644
--- a/docs-website/versioned_docs/version-2.26/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.26/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.26/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.26/development/enabling-gpu-acceleration.mdx
index 80e4efea0eb..8ed8de0d05f 100644
--- a/docs-website/versioned_docs/version-2.26/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.26/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.26/development/logging.mdx b/docs-website/versioned_docs/version-2.26/development/logging.mdx
index e9c5cf01450..16fd340e48c 100644
--- a/docs-website/versioned_docs/version-2.26/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.26/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -79,7 +79,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -98,7 +98,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.26/development/tracing.mdx b/docs-website/versioned_docs/version-2.26/development/tracing.mdx
index 589c6387662..91f946dbc7d 100644
--- a/docs-website/versioned_docs/version-2.26/development/tracing.mdx
+++ b/docs-website/versioned_docs/version-2.26/development/tracing.mdx
@@ -260,7 +260,7 @@ To enable content tracing, there are two options:
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
@@ -355,4 +355,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.26/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.26/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index b1c1829a5a5..9dbed7f775d 100644
--- a/docs-website/versioned_docs/version-2.26/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.26/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.27/concepts/document-store/choosing-a-document-store.mdx b/docs-website/versioned_docs/version-2.27/concepts/document-store/choosing-a-document-store.mdx
index 24fe2267630..d777e9dd508 100644
--- a/docs-website/versioned_docs/version-2.27/concepts/document-store/choosing-a-document-store.mdx
+++ b/docs-website/versioned_docs/version-2.27/concepts/document-store/choosing-a-document-store.mdx
@@ -34,7 +34,7 @@ We can group vector databases into five categories, from more specialized to gen
 We are working on supporting all these types in Haystack.
 
 In the meantime, here’s the most recent overview of available integrations:
-<ClickableImage src="/img/2c188e9-2.0_Document_Stores_6.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
+<ClickableImage src="/img/document-store-categories.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
 
 #### Summary
 
diff --git a/docs-website/versioned_docs/version-2.27/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.27/concepts/pipelines/debugging-pipelines.mdx
index dbf26e2074e..4fba868826b 100644
--- a/docs-website/versioned_docs/version-2.27/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.27/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.27/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.27/concepts/pipelines/visualizing-pipelines.mdx
index 0d5c0cd5fed..135688e0f52 100644
--- a/docs-website/versioned_docs/version-2.27/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.27/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.27/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.27/development/deployment/kubernetes.mdx
index 929ca4a99e1..c58e5322b4c 100644
--- a/docs-website/versioned_docs/version-2.27/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.27/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.27/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.27/development/enabling-gpu-acceleration.mdx
index 80e4efea0eb..8ed8de0d05f 100644
--- a/docs-website/versioned_docs/version-2.27/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.27/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.27/development/logging.mdx b/docs-website/versioned_docs/version-2.27/development/logging.mdx
index e9c5cf01450..16fd340e48c 100644
--- a/docs-website/versioned_docs/version-2.27/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.27/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -79,7 +79,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -98,7 +98,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.27/development/tracing.mdx b/docs-website/versioned_docs/version-2.27/development/tracing.mdx
index 589c6387662..91f946dbc7d 100644
--- a/docs-website/versioned_docs/version-2.27/development/tracing.mdx
+++ b/docs-website/versioned_docs/version-2.27/development/tracing.mdx
@@ -260,7 +260,7 @@ To enable content tracing, there are two options:
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
@@ -355,4 +355,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.27/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.27/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index b1c1829a5a5..9dbed7f775d 100644
--- a/docs-website/versioned_docs/version-2.27/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.27/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.28/concepts/document-store/choosing-a-document-store.mdx b/docs-website/versioned_docs/version-2.28/concepts/document-store/choosing-a-document-store.mdx
index 24fe2267630..d777e9dd508 100644
--- a/docs-website/versioned_docs/version-2.28/concepts/document-store/choosing-a-document-store.mdx
+++ b/docs-website/versioned_docs/version-2.28/concepts/document-store/choosing-a-document-store.mdx
@@ -34,7 +34,7 @@ We can group vector databases into five categories, from more specialized to gen
 We are working on supporting all these types in Haystack.
 
 In the meantime, here’s the most recent overview of available integrations:
-<ClickableImage src="/img/2c188e9-2.0_Document_Stores_6.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
+<ClickableImage src="/img/document-store-categories.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
 
 #### Summary
 
diff --git a/docs-website/versioned_docs/version-2.28/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.28/concepts/pipelines/debugging-pipelines.mdx
index dbf26e2074e..4fba868826b 100644
--- a/docs-website/versioned_docs/version-2.28/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.28/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.28/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.28/concepts/pipelines/visualizing-pipelines.mdx
index 0d5c0cd5fed..135688e0f52 100644
--- a/docs-website/versioned_docs/version-2.28/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.28/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.28/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.28/development/deployment/kubernetes.mdx
index 929ca4a99e1..c58e5322b4c 100644
--- a/docs-website/versioned_docs/version-2.28/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.28/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.28/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.28/development/enabling-gpu-acceleration.mdx
index 80e4efea0eb..8ed8de0d05f 100644
--- a/docs-website/versioned_docs/version-2.28/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.28/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.28/development/logging.mdx b/docs-website/versioned_docs/version-2.28/development/logging.mdx
index e9c5cf01450..16fd340e48c 100644
--- a/docs-website/versioned_docs/version-2.28/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.28/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -79,7 +79,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -98,7 +98,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.28/development/tracing.mdx b/docs-website/versioned_docs/version-2.28/development/tracing.mdx
index 589c6387662..91f946dbc7d 100644
--- a/docs-website/versioned_docs/version-2.28/development/tracing.mdx
+++ b/docs-website/versioned_docs/version-2.28/development/tracing.mdx
@@ -260,7 +260,7 @@ To enable content tracing, there are two options:
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
@@ -355,4 +355,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.28/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.28/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index b1c1829a5a5..9dbed7f775d 100644
--- a/docs-website/versioned_docs/version-2.28/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.28/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.29/concepts/document-store/choosing-a-document-store.mdx b/docs-website/versioned_docs/version-2.29/concepts/document-store/choosing-a-document-store.mdx
index 24fe2267630..d777e9dd508 100644
--- a/docs-website/versioned_docs/version-2.29/concepts/document-store/choosing-a-document-store.mdx
+++ b/docs-website/versioned_docs/version-2.29/concepts/document-store/choosing-a-document-store.mdx
@@ -34,7 +34,7 @@ We can group vector databases into five categories, from more specialized to gen
 We are working on supporting all these types in Haystack.
 
 In the meantime, here’s the most recent overview of available integrations:
-<ClickableImage src="/img/2c188e9-2.0_Document_Stores_6.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
+<ClickableImage src="/img/document-store-categories.png" alt="Document store categories diagram showing four types: pure vector databases (Chroma, Milvus, Pinecone, Weaviate, Qdrant), full-text search databases (Elasticsearch, OpenSearch), vector-capable SQL databases (Pgvector for PostgreSQL), and vector-capable NoSQL databases (DataStax Astra, MongoDB, neo4j)" className="img-light-bg" />
 
 #### Summary
 
diff --git a/docs-website/versioned_docs/version-2.29/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.29/concepts/pipelines/debugging-pipelines.mdx
index 4665d1c195e..f161ccc9064 100644
--- a/docs-website/versioned_docs/version-2.29/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.29/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.29/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.29/concepts/pipelines/visualizing-pipelines.mdx
index 95a63a02a48..78e69675d5f 100644
--- a/docs-website/versioned_docs/version-2.29/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.29/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.29/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.29/development/deployment/kubernetes.mdx
index 929ca4a99e1..c58e5322b4c 100644
--- a/docs-website/versioned_docs/version-2.29/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.29/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.29/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.29/development/enabling-gpu-acceleration.mdx
index 80e4efea0eb..8ed8de0d05f 100644
--- a/docs-website/versioned_docs/version-2.29/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.29/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.29/development/logging.mdx b/docs-website/versioned_docs/version-2.29/development/logging.mdx
index e9c5cf01450..16fd340e48c 100644
--- a/docs-website/versioned_docs/version-2.29/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.29/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -79,7 +79,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -98,7 +98,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.29/development/tracing.mdx b/docs-website/versioned_docs/version-2.29/development/tracing.mdx
index 589c6387662..91f946dbc7d 100644
--- a/docs-website/versioned_docs/version-2.29/development/tracing.mdx
+++ b/docs-website/versioned_docs/version-2.29/development/tracing.mdx
@@ -260,7 +260,7 @@ To enable content tracing, there are two options:
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
@@ -355,4 +355,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.29/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.29/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index c8b2d8fd667..f6503270c20 100644
--- a/docs-website/versioned_docs/version-2.29/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.29/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.30/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.30/concepts/pipelines/debugging-pipelines.mdx
index 5dc8b28eb3e..3234d3a85e5 100644
--- a/docs-website/versioned_docs/version-2.30/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.30/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.30/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.30/concepts/pipelines/visualizing-pipelines.mdx
index 95a63a02a48..78e69675d5f 100644
--- a/docs-website/versioned_docs/version-2.30/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.30/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.30/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.30/development/deployment/kubernetes.mdx
index 929ca4a99e1..c58e5322b4c 100644
--- a/docs-website/versioned_docs/version-2.30/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.30/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.30/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.30/development/enabling-gpu-acceleration.mdx
index 80e4efea0eb..8ed8de0d05f 100644
--- a/docs-website/versioned_docs/version-2.30/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.30/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.30/development/logging.mdx b/docs-website/versioned_docs/version-2.30/development/logging.mdx
index e9c5cf01450..16fd340e48c 100644
--- a/docs-website/versioned_docs/version-2.30/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.30/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -79,7 +79,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -98,7 +98,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.30/development/tracing/logging-tracer.mdx b/docs-website/versioned_docs/version-2.30/development/tracing/logging-tracer.mdx
index 75294773774..dc57419bf0c 100644
--- a/docs-website/versioned_docs/version-2.30/development/tracing/logging-tracer.mdx
+++ b/docs-website/versioned_docs/version-2.30/development/tracing/logging-tracer.mdx
@@ -58,4 +58,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.30/development/tracing/opentelemetry.mdx b/docs-website/versioned_docs/version-2.30/development/tracing/opentelemetry.mdx
index 42f4629000a..39d7e08d23e 100644
--- a/docs-website/versioned_docs/version-2.30/development/tracing/opentelemetry.mdx
+++ b/docs-website/versioned_docs/version-2.30/development/tracing/opentelemetry.mdx
@@ -93,7 +93,7 @@ See the [`OpenTelemetryConnector` documentation page](../../pipeline-components/
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
diff --git a/docs-website/versioned_docs/version-2.30/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.30/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index c8b2d8fd667..f6503270c20 100644
--- a/docs-website/versioned_docs/version-2.30/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.30/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?
 
diff --git a/docs-website/versioned_docs/version-2.31/concepts/pipelines/debugging-pipelines.mdx b/docs-website/versioned_docs/version-2.31/concepts/pipelines/debugging-pipelines.mdx
index 5dc8b28eb3e..3234d3a85e5 100644
--- a/docs-website/versioned_docs/version-2.31/concepts/pipelines/debugging-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.31/concepts/pipelines/debugging-pipelines.mdx
@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 
diff --git a/docs-website/versioned_docs/version-2.31/concepts/pipelines/visualizing-pipelines.mdx b/docs-website/versioned_docs/version-2.31/concepts/pipelines/visualizing-pipelines.mdx
index 95a63a02a48..78e69675d5f 100644
--- a/docs-website/versioned_docs/version-2.31/concepts/pipelines/visualizing-pipelines.mdx
+++ b/docs-website/versioned_docs/version-2.31/concepts/pipelines/visualizing-pipelines.mdx
@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 
diff --git a/docs-website/versioned_docs/version-2.31/development/deployment/kubernetes.mdx b/docs-website/versioned_docs/version-2.31/development/deployment/kubernetes.mdx
index 929ca4a99e1..c58e5322b4c 100644
--- a/docs-website/versioned_docs/version-2.31/development/deployment/kubernetes.mdx
+++ b/docs-website/versioned_docs/version-2.31/development/deployment/kubernetes.mdx
@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
diff --git a/docs-website/versioned_docs/version-2.31/development/enabling-gpu-acceleration.mdx b/docs-website/versioned_docs/version-2.31/development/enabling-gpu-acceleration.mdx
index 80e4efea0eb..8ed8de0d05f 100644
--- a/docs-website/versioned_docs/version-2.31/development/enabling-gpu-acceleration.mdx
+++ b/docs-website/versioned_docs/version-2.31/development/enabling-gpu-acceleration.mdx
@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:
diff --git a/docs-website/versioned_docs/version-2.31/development/logging.mdx b/docs-website/versioned_docs/version-2.31/development/logging.mdx
index e9c5cf01450..16fd340e48c 100644
--- a/docs-website/versioned_docs/version-2.31/development/logging.mdx
+++ b/docs-website/versioned_docs/version-2.31/development/logging.mdx
@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -79,7 +79,7 @@ If Haystack detects a [structlog installation](https://www.structlog.org/en/stab
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -98,7 +98,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 
diff --git a/docs-website/versioned_docs/version-2.31/development/tracing/logging-tracer.mdx b/docs-website/versioned_docs/version-2.31/development/tracing/logging-tracer.mdx
index 75294773774..dc57419bf0c 100644
--- a/docs-website/versioned_docs/version-2.31/development/tracing/logging-tracer.mdx
+++ b/docs-website/versioned_docs/version-2.31/development/tracing/logging-tracer.mdx
@@ -58,4 +58,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
diff --git a/docs-website/versioned_docs/version-2.31/development/tracing/opentelemetry.mdx b/docs-website/versioned_docs/version-2.31/development/tracing/opentelemetry.mdx
index 42f4629000a..39d7e08d23e 100644
--- a/docs-website/versioned_docs/version-2.31/development/tracing/opentelemetry.mdx
+++ b/docs-website/versioned_docs/version-2.31/development/tracing/opentelemetry.mdx
@@ -93,7 +93,7 @@ See the [`OpenTelemetryConnector` documentation page](../../pipeline-components/
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 
diff --git a/docs-website/versioned_docs/version-2.31/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx b/docs-website/versioned_docs/version-2.31/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
index 5c8956337cc..c99eedd389a 100644
--- a/docs-website/versioned_docs/version-2.31/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
+++ b/docs-website/versioned_docs/version-2.31/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx
@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?