diff --git a/docs/FastAPI/01_fastapi_application___routing.md b/docs/FastAPI/01_fastapi_application___routing.md
index 31e6d9e..27ed055 100644
--- a/docs/FastAPI/01_fastapi_application___routing.md
+++ b/docs/FastAPI/01_fastapi_application___routing.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "FastAPI Application & Routing"
+parent: "FastAPI"
+nav_order: 1
+---
+
 # Chapter 1: FastAPI Application & Routing
 
 Welcome to your first adventure with FastAPI! 👋
diff --git a/docs/FastAPI/02_path_operations___parameter_declaration.md b/docs/FastAPI/02_path_operations___parameter_declaration.md
index bfa65a7..4fed8d1 100644
--- a/docs/FastAPI/02_path_operations___parameter_declaration.md
+++ b/docs/FastAPI/02_path_operations___parameter_declaration.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Path Operations & Parameter Declaration"
+parent: "FastAPI"
+nav_order: 2
+---
+
 # Chapter 2: Path Operations & Parameter Declaration
 
 Welcome back! In [Chapter 1: FastAPI Application & Routing](01_fastapi_application___routing.md), we learned how to set up a basic FastAPI application and organize our code using `APIRouter`. We saw how to connect a URL like `/` to a Python function using `@app.get("/")`.
diff --git a/docs/FastAPI/03_data_validation___serialization__pydantic_.md b/docs/FastAPI/03_data_validation___serialization__pydantic_.md
index f41f401..214baf2 100644
--- a/docs/FastAPI/03_data_validation___serialization__pydantic_.md
+++ b/docs/FastAPI/03_data_validation___serialization__pydantic_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Data Validation & Serialization (Pydantic)"
+parent: "FastAPI"
+nav_order: 3
+---
+
 # Chapter 3: Data Validation & Serialization (Pydantic)
 
 Welcome back! In [Chapter 2: Path Operations & Parameter Declaration](02_path_operations___parameter_declaration.md), we learned how FastAPI uses type hints to understand path parameters (like `/items/{item_id}`) and query parameters (like `/?skip=0&limit=10`). We even saw a sneak peek of how Pydantic models can define the structure of a JSON request body.
diff --git a/docs/FastAPI/04_openapi___automatic_docs.md b/docs/FastAPI/04_openapi___automatic_docs.md
index 75d7bf7..3845b38 100644
--- a/docs/FastAPI/04_openapi___automatic_docs.md
+++ b/docs/FastAPI/04_openapi___automatic_docs.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "OpenAPI & Automatic Docs"
+parent: "FastAPI"
+nav_order: 4
+---
+
 # Chapter 4: OpenAPI & Automatic Docs
 
 Welcome back! In [Chapter 3: Data Validation & Serialization (Pydantic)](03_data_validation___serialization__pydantic_.md), we saw how FastAPI uses Pydantic models to automatically validate incoming data and serialize outgoing data, making our API robust and predictable. But how do we tell others (or remind ourselves later) how to actually *use* our API? What endpoints exist? What data should they send? What will they get back?
diff --git a/docs/FastAPI/05_dependency_injection.md b/docs/FastAPI/05_dependency_injection.md
index 42cfc41..317f609 100644
--- a/docs/FastAPI/05_dependency_injection.md
+++ b/docs/FastAPI/05_dependency_injection.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Dependency Injection"
+parent: "FastAPI"
+nav_order: 5
+---
+
 # Chapter 5: Dependency Injection
 
 Welcome back! In [Chapter 4: OpenAPI & Automatic Docs](04_openapi___automatic_docs.md), we saw how FastAPI automatically generates interactive documentation for our API, making it easy for others (and ourselves!) to understand and use. This works because FastAPI understands the structure of our paths, parameters, and Pydantic models.
diff --git a/docs/FastAPI/06_error_handling.md b/docs/FastAPI/06_error_handling.md
index d4f82c9..df304be 100644
--- a/docs/FastAPI/06_error_handling.md
+++ b/docs/FastAPI/06_error_handling.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Error Handling"
+parent: "FastAPI"
+nav_order: 6
+---
+
 # Chapter 6: Error Handling
 
 Welcome back! In [Chapter 5: Dependency Injection](05_dependency_injection.md), we learned how to structure our code using dependencies to manage common tasks like pagination or database sessions. This helps keep our code clean and reusable.
diff --git a/docs/FastAPI/07_security_utilities.md b/docs/FastAPI/07_security_utilities.md
index 2ed1d67..0cf4ee7 100644
--- a/docs/FastAPI/07_security_utilities.md
+++ b/docs/FastAPI/07_security_utilities.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Security Utilities"
+parent: "FastAPI"
+nav_order: 7
+---
+
 # Chapter 7: Security Utilities
 
 Hi there! 👋 In [Chapter 6: Error Handling](06_error_handling.md), we learned how to handle situations where things go wrong in our API, like when a user requests an item that doesn't exist. Now, let's talk about protecting our API endpoints.
diff --git a/docs/FastAPI/08_background_tasks.md b/docs/FastAPI/08_background_tasks.md
index 1f68760..0afef1d 100644
--- a/docs/FastAPI/08_background_tasks.md
+++ b/docs/FastAPI/08_background_tasks.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Background Tasks"
+parent: "FastAPI"
+nav_order: 8
+---
+
 # Chapter 8: Background Tasks
 
 Welcome back! In [Chapter 7: Security Utilities](07_security_utilities.md), we learned how to protect our API endpoints using FastAPI's security features. Now, let's explore how to perform actions *after* we've already sent a response back to the user.
diff --git a/docs/Flask/01_application_object___flask__.md b/docs/Flask/01_application_object___flask__.md
index 078a8ae..a932c09 100644
--- a/docs/Flask/01_application_object___flask__.md
+++ b/docs/Flask/01_application_object___flask__.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Application Object (Flask)"
+parent: "Flask"
+nav_order: 1
+---
+
 # Chapter 1: Application Object (`Flask`)
 
 Welcome to your first step into the world of Flask! Flask is a "microframework" for building web applications in Python. "Micro" doesn't mean it's limited; it means Flask provides the essentials to get started quickly, letting you add features as needed.
diff --git a/docs/Flask/02_routing_system.md b/docs/Flask/02_routing_system.md
index 6b6e030..15ff3a7 100644
--- a/docs/Flask/02_routing_system.md
+++ b/docs/Flask/02_routing_system.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Routing System"
+parent: "Flask"
+nav_order: 2
+---
+
 # Chapter 2: Routing System
 
 Welcome back! In [Chapter 1: Application Object (`Flask`)](01_application_object___flask__.md), we learned how to create the central `app` object, the control tower for our Flask application. We even added a simple "Hello, World!" page using `@app.route('/')`.
diff --git a/docs/Flask/03_request_and_response_objects.md b/docs/Flask/03_request_and_response_objects.md
index 8335121..4dcfe64 100644
--- a/docs/Flask/03_request_and_response_objects.md
+++ b/docs/Flask/03_request_and_response_objects.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Request and Response Objects"
+parent: "Flask"
+nav_order: 3
+---
+
 # Chapter 3: Request and Response Objects
 
 Welcome back! In [Chapter 2: Routing System](02_routing_system.md), we learned how Flask uses routes (`@app.route(...)`) to direct incoming web requests to the correct Python view functions. We saw how to create static routes like `/about` and dynamic routes like `/user/<username>`.
diff --git a/docs/Flask/04_templating__jinja2_integration_.md b/docs/Flask/04_templating__jinja2_integration_.md
index 00328d1..1e81ce2 100644
--- a/docs/Flask/04_templating__jinja2_integration_.md
+++ b/docs/Flask/04_templating__jinja2_integration_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Templating (Jinja2 Integration)"
+parent: "Flask"
+nav_order: 4
+---
+
 # Chapter 4: Templating (Jinja2 Integration)
 
 Welcome back! In [Chapter 3: Request and Response Objects](03_request_and_response_objects.md), we saw how to handle incoming requests and craft outgoing responses. We even created a simple HTML form, but we had to write the HTML code directly as a string inside our Python function. Imagine building a whole website like that – it would get very messy very quickly!
diff --git a/docs/Flask/05_context_globals___current_app____request____session____g__.md b/docs/Flask/05_context_globals___current_app____request____session____g__.md
index 4a385a1..418dd71 100644
--- a/docs/Flask/05_context_globals___current_app____request____session____g__.md
+++ b/docs/Flask/05_context_globals___current_app____request____session____g__.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Context Globals"
+parent: "Flask"
+nav_order: 5
+---
+
 # Chapter 5: Context Globals (`current_app`, `request`, `session`, `g`)
 
 Welcome back! In [Chapter 4: Templating (Jinja2 Integration)](04_templating__jinja2_integration_.md), we learned how to separate our HTML structure from our Python code using templates and the `render_template` function. We saw how variables like `request` and functions like `url_for` seemed to be magically available in our templates.
diff --git a/docs/Flask/06_configuration___config__.md b/docs/Flask/06_configuration___config__.md
index d93b2c1..1301909 100644
--- a/docs/Flask/06_configuration___config__.md
+++ b/docs/Flask/06_configuration___config__.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Configuration (config)"
+parent: "Flask"
+nav_order: 6
+---
+
 # Chapter 6: Configuration (`Config`)
 
 Welcome back! In [Chapter 5: Context Globals (`current_app`, `request`, `session`, `g`)](05_context_globals___current_app____request____session____g__.md), we saw how Flask uses context globals like `current_app` and `session`. We even learned that using the `session` requires setting a `SECRET_KEY` on our application object. But where is the best place to put settings like the secret key, or maybe a database connection string, or a flag to turn debugging features on or off? We definitely don't want to hardcode these directly into our main application logic!
diff --git a/docs/Flask/07_application_and_request_contexts.md b/docs/Flask/07_application_and_request_contexts.md
index 234ab24..9bf9620 100644
--- a/docs/Flask/07_application_and_request_contexts.md
+++ b/docs/Flask/07_application_and_request_contexts.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Application and Request Contexts"
+parent: "Flask"
+nav_order: 7
+---
+
 # Chapter 7: Application and Request Contexts
 
 Welcome back! In [Chapter 6: Configuration (`Config`)](06_configuration___config__.md), we learned how to manage settings for our Flask application using the `app.config` object. And in [Chapter 5: Context Globals (`current_app`, `request`, `session`, `g`)](05_context_globals___current_app____request____session____g__.md), we met special variables like `request` and `current_app` that seem to magically know about the current request or application.
diff --git a/docs/Flask/08_blueprints.md b/docs/Flask/08_blueprints.md
index a567d0c..f71b740 100644
--- a/docs/Flask/08_blueprints.md
+++ b/docs/Flask/08_blueprints.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Blueprints"
+parent: "Flask"
+nav_order: 8
+---
+
 # Chapter 8: Blueprints
 
 Welcome back! In [Chapter 7: Application and Request Contexts](07_application_and_request_contexts.md), we explored the "magic" behind Flask's context system, understanding how variables like `request` and `current_app` work reliably even with multiple concurrent requests.