diff --git a/advanced/subpath/route53-cloudfront.mdx b/advanced/subpath/route53-cloudfront.mdx
index 9207be3fd..4a68a76e6 100644
--- a/advanced/subpath/route53-cloudfront.mdx
+++ b/advanced/subpath/route53-cloudfront.mdx
@@ -1,146 +1,143 @@
---
-title: "AWS Route 53 and Cloudfront"
+title: "AWS Route 53 and CloudFront"
sidebarTitle: "AWS"
description: "Host documentation at a /docs subdirectory using AWS services"
---
import Propagating from "/snippets/custom-subpath-propagating.mdx";
-## Create Cloudfront Distribution
+This guide walks you through configuring AWS CloudFront and Route 53 to serve your documentation at `/docs` while keeping your main site intact. You'll create a CloudFront distribution that routes `/docs` traffic to your Mintlify documentation and all other traffic to your primary site.
-Navigate to [Cloudfront](https://aws.amazon.com/cloudfront) inside the AWS console and click on `Create distribution`
+
+Before starting, ensure you have AWS console access with permissions for CloudFront and Route 53. You'll also need your Mintlify subdomain (found in your dashboard) and a staging URL for your main site.
+
+
+## Set up CloudFront distribution
+
+Navigate to [CloudFront](https://aws.amazon.com/cloudfront) in the AWS console and select **Create distribution**.
- 
+ 
-For the Origin domain, input `[SUBDOMAIN].mintlify.dev` where `[SUBDOMAIN]` is the project's unique subdomain. Click on `Use: [SUBDOMAIN].mintlify.dev`
+For the origin domain, enter `[SUBDOMAIN].mintlify.dev` where `[SUBDOMAIN]` is your project's unique subdomain from the dashboard. Select **Use: [SUBDOMAIN].mintlify.dev** from the dropdown.
-
+
-For **Cache key and origin requests**, select `Caching Optimized`.
+Under **Cache key and origin requests**, select **Caching Optimized**.
- 
+ 
-And for **Web Application Firewall (WAF)**, enable security protections
+For **Web Application Firewall (WAF)**, enable security protections.
- 
+ 
-The remaining settings should be default. Click `Create distribution`.
+Leave other settings as defaults and select **Create distribution**.
-## Add Default Origin
+## Add your main site origin
-After creating the distribution, navigate to the `Origins` tab.
+After creating the distribution, go to the **Origins** tab.
-
+
-We want to find a staging URL that mirrors where the main domain (example.com). This is highly variant depending on how your landing page is hosted.
+You need a staging URL that mirrors your main domain. This varies based on your hosting provider:
-
-For instance, if your landing page is hosted on Webflow, you can use the
-Webflow's staging URL. It would look like `.webflow.io`.
-
-If you use Vercel, you use the `.vercel.app` domain available for every project.
+
+Common staging URL patterns:
+- Webflow: `yoursite.webflow.io`
+- Vercel: `yourproject.vercel.app`
+- Netlify: `yourproject.netlify.app`
+- GitHub Pages: `username.github.io/repository`
+
-
-
-If you're unsure on how to get a staging URL for your landing page, [contact
-support](/contact-support) and we'd be happy to help
-
+Can't find your staging URL? Check your hosting provider's dashboard or contact support for help identifying the correct URL.
-Once you have the staging URL, ours for instance is [mintlify-landing-page.vercel.app](https://mintlify-landing-page.vercel.app), create a new Origin and add it as the **Origin domain**.
+Create a new origin using your staging URL as the **Origin domain**.
- 
+ 
-By this point, you should have two Origins - one with `[SUBDOMAIN].mintlify.app` and another with with staging URL.
-
-## Set Behaviors
+You should now have two origins: your Mintlify subdomain and your main site's staging URL.
-Behaviors in Cloudfront enables control over the subpath logic. At a high level, we're looking to create the following logic.
+## Configure routing behaviors
-- **If a user lands on /docs**, go to `[SUBDOMAIN].mintlify.dev`
-- **If a user lands on any other page**, go the current landing page
+Behaviors control how CloudFront routes requests. You'll create rules that send `/docs` traffic to your documentation and everything else to your main site.
-We're going to create three behaviors by clicking on the `Create behavior` button.
+Create three behaviors by selecting **Create behavior**:
-### `/docs/*`
+### `/docs/*` behavior
-The first behavior should have a **Path pattern** of `/docs/*` with **Origin and origin groups** pointing to the `.mintlify.dev` URL (in our case `acme.mintlify.dev`)
+Set **Path pattern** to `/docs/*` and **Origin and origin groups** to your `.mintlify.dev` URL.
-
+
-For **Cache policy**, select `CachingOptimized` and create behavior.
+Set **Cache policy** to **CachingOptimized** and create the behavior.
-### `/docs`
+### `/docs` behavior
-The second behavior should be the same as the first one but with a **Path pattern** of `/docs` and **Origin and origin groups** pointing to the same `.mintlify.dev` URL.
+Create another behavior with **Path pattern** `/docs` pointing to the same `.mintlify.dev` origin.
-
+
-### `Default (*)`
+### Update default behavior
-Lastly, we're going to edit the `Default (*)` behavior.
+Edit the **Default (*)** behavior to point to your main site's staging URL.
- 
+ 
-We're going to change the default behavior's **Origin and origin groups** to the staging URL (in our case `mintlify-landing-page.vercel.app`).
+Change **Origin and origin groups** to your staging URL and save changes.
- 
+ 
-Click on `Save changes`.
+## Test your distribution
-## Preview Distribution
-
-You can now test if your distribution is set up properly by going to the `General` tab and visiting the **Distribution domain name** URL.
+Go to the **General** tab and visit your **Distribution domain name** URL to test the setup.
- 
+ 
-All pages should be directing to your main landing page, but if you append `/docs` to the URL, you should see it going to the Mintlify documentation instance.
+Verify that:
+- The root URL shows your main site
+- Adding `/docs` to the URL displays your documentation
-## Connecting it with Route53
+## Connect with Route 53
-Now, we're going to bring the functionality of the Cloudfront distribution into your primary domain.
+Now you'll route your primary domain through the CloudFront distribution.
- For this section, you can also refer to AWS's official guide on [Configuring
- Amazon Route 53 to route traffic to a CloudFront
- distribution](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html#routing-to-cloudfront-distribution-config)
+This follows AWS's guide on [routing traffic to a CloudFront distribution](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html#routing-to-cloudfront-distribution-config). You'll need Route 53 managing your domain's DNS.
-Navigate to [Route53](https://aws.amazon.com/route53) inside the AWS console, and click into the `Hosted zone` for your primary domain. Click on `Create record`
+In [Route 53](https://aws.amazon.com/route53), open your domain's **Hosted zone** and select **Create record**.
-Toggle `Alias` and then **Route traffic to** the `Alias to CloudFront distribution` option.
+Enable **Alias** and set **Route traffic to** as **Alias to CloudFront distribution**. Select your distribution from the dropdown.
-Click `Create records`.
+Select **Create records**.
-
- You may need to remove the existing A record if one currently exists.
-
+
+You may need to delete existing A records for your domain before creating the alias record.
+
-And voila! Your documentation will be served at `/docs` for your primary domain.
+Your documentation will now be available at `yourdomain.com/docs`.
diff --git a/editor.mdx b/editor.mdx
index b4b2a25b8..8cc8feb4c 100644
--- a/editor.mdx
+++ b/editor.mdx
@@ -16,59 +16,51 @@ icon: "mouse-pointer-2"
alt="Mintlify web editor interface in dark mode"
/>
-## Introduction
+## What you'll learn
-The web editor is a visual interface for creating, editing, and reviewing documentation directly in your browser.
+By the end of this tutorial, you'll be comfortable creating, editing, and publishing documentation using the web editor. You'll understand how to work safely with branches and collaborate with your team through pull requests.
-- **Visual editing**: Make changes to your documentation using a what-you-see-is-what-you-get (WYSIWYG) editor that shows how your content will look when published.
-- **Git synchronization**: All changes automatically sync with your Git repository to maintain version control.
-- **Real-time collaboration**: Multiple team members can work on documentation simultaneously, with changes visible to everyone.
-- **No setup required**: Start writing immediately from your dashboard.
+## Why use the web editor?
-### Web editor flow
+The web editor lets you focus on creating great content without worrying about technical setup. Whether you're a content creator, technical writer, or team member who prefers working in a browser, the web editor provides everything you need to maintain professional documentation.
-Here is how you'll typically work in the web editor:
+Key benefits that make your work easier:
+- **Visual editing**: See exactly how your content will look as you write it
+- **No downloads required**: Everything works in your browser
+- **Automatic backups**: Your changes sync with Git automatically
+- **Team collaboration**: Work alongside colleagues in real-time
+- **Professional results**: Create polished documentation without coding experience
+
+## Getting started: Your first edit
+
+Let's start with something simple to get you comfortable with the editor.
-
- Create a branch or make changes directly to your deployment branch.
+
+ From your dashboard, click into the web editor and select any page from the file list on the left. Don't worry about making mistakes – we'll show you how to work safely with branches.
-
- Navigate to an existing file or create a new one.
+
+ The editor opens in visual mode by default, which shows you exactly how your content will appear to readers. Click anywhere in the text and make a small change, like updating a sentence.
-
- Make changes in the web editor using either visual mode or Markdown mode.
+
+ Notice how your edits appear immediately, just like editing in a word processor. This instant feedback helps you create content that looks exactly the way you want.
-
- See how your changes will appear in visual mode.
-
-
- If you're working on your deployment branch, publish your changes directly from the web editor. On other branches, publish your changes through a pull request.
+
+ Click the mode toggle in the top right corner to see the underlying code. Don't worry if it looks unfamiliar – you can always switch back to visual mode.
-## Editor modes
-
-The web editor has two modes to accommodate different editing preferences and needs.
+
+The beauty of the web editor is that you can work entirely in visual mode and still create professional documentation. Markdown mode is there if you want it, but it's never required.
+
-You can switch between modes at any time using the toggle in the top right corner of the editor toolbar.
+## Understanding the two editing modes
-
- 
- 
-
+The web editor gives you two ways to work, and you can switch between them anytime to match your comfort level and needs.
-### Visual mode
+### Visual mode: Your main workspace
-Visual mode provides a WYSIWYG experience where the changes that you make in the editor are the changes that will be published to your documentation site. This mode is ideal for when you want to see how your changes will look in real-time.
+Think of visual mode like a word processor designed specifically for documentation. What you see is exactly what your readers will see, making it easy to create professional-looking content.
![]()
-### Markdown mode
+In visual mode, you can:
+- Type and format text naturally
+- Add components by pressing **/** to open the component menu
+- See how images, code blocks, and callouts will look to readers
+- Focus on your content without worrying about syntax
-Markdown mode provides direct access to the underlying `MDX` code of your documentation. `MDX` combines Markdown syntax with React components, giving you full control over your content structure. This mode is ideal for when you need precise control over component properties or when you prefer to write in Markdown syntax.
+### Markdown mode: For precise control
+
+Markdown mode shows you the underlying structure of your content. This is helpful when you need to fine-tune component settings or if you prefer working with code-like syntax.
![]()
-## Git fundamentals
-
-The web editor performs Git operations behind the scenes. Understanding these concepts will help you work more effectively with the web editor and collaborate with team members who are working in their local environments.
-
-
-
- Your documentation's source where all files and their history are stored. The web editor connects to your repository to access and modify content.
-
-
-
- A saved snapshot of your changes at a specific point in time.
-
-
-
- A separate workspace for making changes without affecting your live documentation. Think of it as a safe sandbox for experiments and larger updates.
-
-
-
- The main branch that contains your live documentation content. Changes to this branch are automatically published to your documentation site. Often called `main`.
-
-
-
- A way to propose merging your branch changes into your live documentation. Allows for review and discussion before changes go live. Commonly called a PR.
-
-
-
- A diff (or difference) shows the specific changes between two versions of a file. When reviewing pull requests, diffs highlight what has been added, removed, or modified.
-
-
-
-### What the web editor automates
-
-The web editor connects to your Git repository through our [GitHub App](/settings/github) or [GitLab integration](/settings/gitlab) and handles Git automatically. When you:
-
-- **Open a file**: Fetches the latest version from your repository.
-- **Make changes in a file**: Tracks your changes as a draft that can become a commit.
-- **Save changes**: Creates a commit with your changes.
-- **Create a branch**: Creates a new branch in your repository.
-- **Publish on your deployment branch**: Creates a commit and pushes directly to your deployment branch.
-- **Publish on other branches**: Creates a commit and opens a pull request.
-
-### When to use branches
-
-Branches let you work on changes without affecting the content on your live site. When your changes are ready, you can merge them into your deployment branch with a pull request.
-
-**Best practice: Always work from branches.** This ensures your live documentation stays stable and enables proper review workflows.
-
-## Creating a branch
-
-1. Select the branch name in the editor toolbar (usually `main` by default).
-2. Select **New Branch**.
-3. Enter a descriptive name for your branch like `update-getting-started` or `fix-installation-steps`.
-4. Select **Create Branch**.
+You might use Markdown mode to:
+- Copy and paste content that's already in Markdown format
+- Adjust specific component properties
+- Work with complex layouts that need precise control
- You may need to select your new branch from the dropdown menu if the editor does not automatically switch to it.
+You can always switch between modes using the toggle in the top right corner. Your content stays the same – you're just choosing how to view and edit it.
-### Saving changes on a branch
+## Working safely with branches
-To save your changes on a branch, select the **Save Changes** button in the top-right corner of the editor. This creates a commit with your changes and pushes it to your branch.
+Before making significant changes, let's learn about branches – your safety net for experimenting and collaborating without affecting your live documentation.
-### Switching branches
+### Why branches matter for your workflow
-1. Select the current branch name in the editor toolbar.
-2. Select the branch you want to switch to from the dropdown menu.
+Think of your main branch as your published documentation that readers see. A branch is like a private workspace where you can:
+- Try out major changes without affecting your live site
+- Work on content over multiple sessions
+- Get feedback from colleagues before publishing
+- Keep a clean history of what changes and when
-
- Any unsaved changes will be lost when switching branches. Make sure to save or publish your work before switching.
-
+This approach gives you confidence to experiment and iterate on your content.
-## Making changes
+### Creating your first branch
-Edit existing content, create new pages, and organize your site structure in the web editor.
+
+
+ In the editor toolbar, click the current branch name (usually **main**). This opens the branch menu.
+
+
+ Click **New Branch** to create your own workspace.
+
+
+ Use names that describe what you're working on, like:
+ - `update-getting-started-guide`
+ - `add-troubleshooting-section`
+ - `fix-installation-steps`
+
+ Good names help you and your team understand what each branch contains.
+
+
+ Click **Create Branch**. The editor automatically switches to your new branch, and you can start making changes safely.
+
+
-### Navigating files
+
+If you're ever unsure whether a change might break something, create a branch first. It's much easier to experiment when you know your live documentation is protected.
+
-Use the sidebar file explorer to browse your documentation, or press Command + P (Ctrl + P on Windows) to search for files.
+## Creating and organizing content
-### Editing content
+Now that you understand how to work safely, let's explore how to create and structure your documentation.
-Make changes to your pages using visual mode or Markdown mode.
+### Adding content with the component menu
-In visual mode, press / to open the dropdown component menu. Add content blocks, callouts, code blocks and other components to customize your documentation.
+The web editor's component menu gives you access to all the elements that make documentation engaging and useful.
![]()
/ to open the dropdown component menu. Add cont
/>
+To add components:
+1. Place your cursor where you want to add something
+2. Press **/** to open the component menu
+3. Browse the options or type to search (try typing "step" or "code")
+4. Click the component you want to add
+
+Popular components and when to use them:
+- **Callouts** (Info, Warning, Tip): Highlight important information
+- **Steps**: Break down processes into clear, sequential actions
+- **Code blocks**: Share code examples with syntax highlighting
+- **Accordions**: Organize information that readers can expand when needed
+
### Creating new pages
-1. Select the **Create a new file** icon in the file explorer.
+
+
+ In the file explorer sidebar, click the **Create a new file** icon (+ symbol).
+
+ 
- 
-1. Enter a filename.
-1. Press Enter to create the file.
-
-Your new page will open in the editor, ready for content to be added.
-
-### Updating navigation
-
-Add, remove, and reorder pages in your navigation by editing your `docs.json` file:
-
-1. Navigate to your `docs.json` in the file explorer.
-1. Update the `navigation` property to get the navigation structure that you want. See [Navigation](/navigation) for more information.
-
-This example shows how to add a Themes page to the Profile group.
-
-```json title="Adding a Themes page" highlight="18"
+ src="/images/editor/files-menu-dark.png"
+ className="hidden dark:block rounded-2xl border border-white/10 shadow-lg"
+ style={{
+ width: '268px',
+ height: 'auto',
+ }}
+ alt="Files menu in the web editor in dark mode."/>
+
+
+ Enter a filename that clearly describes the page content. Use lowercase letters and hyphens, like:
+ - `getting-started.mdx`
+ - `troubleshooting-guide.mdx`
+ - `api-overview.mdx`
+
+ The `.mdx` extension is added automatically.
+
+
+ Your new page opens in the editor, ready for content. The editor provides a basic template to get you started.
+
+
+
+### Organizing your site structure
+
+Your site's navigation is controlled by the `docs.json` file. Think of this as your site's table of contents – it determines how readers find and navigate through your content.
+
+To update navigation:
+1. Open `docs.json` from the file explorer
+2. Find the `navigation` section
+3. Add your new pages to the appropriate groups
+
+Here's an example of adding a new "Themes" page to an existing "Profile" group:
+
+```json title="Adding a page to navigation" highlight="18"
{
"navigation": {
"groups": [
@@ -257,14 +253,15 @@ This example shows how to add a Themes page to the Profile group.
}
```
-## Publishing changes
+
+The page names in `docs.json` should match your filenames without the `.mdx` extension. So `themes.mdx` becomes `themes` in the configuration.
+
-Select the **Publish** button to save your changes and make them available.
+## Publishing your work
-How your changes are published depends on which branch you are working on:
+You've created great content – now let's get it published. How your changes get published depends on whether you're working on your main branch or a feature branch.
-* **Deployment branch**: Updates your live site immediately.
-* **Other branches**: Creates a pull request so you can review changes before they go live.
+### Understanding your publishing options
![]()
-## Pull requests and reviewing changes
+When you click **Publish**, what happens depends on your current branch:
-Pull requests let you propose changes from your branch so that other people can review them before merging into your live documentation. This helps ensure that your changes are correct and gives your team a chance to collaborate on content.
+**On your main branch**: Changes go live immediately on your documentation site. This is perfect for quick fixes and updates you're confident about.
-
- Even if you're working solo, pull requests are valuable for previewing changes before they go live and maintaining a clear history of updates.
-
+**On a feature branch**: The editor creates a pull request, which lets you (and your team) review changes before they go live. This is ideal for larger updates or when you want feedback.
-### Creating a pull request on a branch
+### Publishing directly (main branch)
-When you're ready to publish changes from your branch:
+If you're making small, confident changes directly on your main branch:
+
+
+
+ Look over what you've edited to make sure everything looks correct.
+
+
+ Click the **Publish** button in the top-right corner.
+
+
+ Write a brief description of what you changed. This helps you track updates over time.
+
+
+ Click **Publish** to make your changes live. They'll appear on your documentation site within a few minutes.
+
+
-1. Make sure all your changes are saved on your branch.
-1. Select **Publish Pull Request** in the top-right corner of the editor.
-1. Add a title and description for your pull request. A good title and description help reviewers understand the changes you've made.
-1. Select **Publish Pull Request**.
+### Creating a pull request (feature branches)
+
+When you're working on a branch and want to review changes before publishing:
+
+
+
+ Make sure all your changes are saved by clicking **Save Changes** if needed.
+
+
+ Instead of just "Publish," you'll see **Publish Pull Request** when working on a branch.
+
+
+ Help reviewers (including future you) understand what changed:
+ - **Good title**: "Update installation guide with new prerequisites"
+ - **Good description**: "Added Node.js requirement and clarified OS compatibility based on user feedback"
+
+
+ Click **Publish Pull Request**. The editor provides a link to view and manage your pull request.
+
+
![]()
-The web editor will create a pull request in your Git repository and provide a link to view it.
+## Collaborating with pull requests
-### Reviewing pull requests
+Pull requests are your gateway to team collaboration and quality control. Even if you work alone, they're valuable for previewing major changes before they go live.
-Once your pull request is created:
+### Why pull requests improve your workflow
-1. **Review your changes**: You and your team members can review your pull request in your Git provider like GitHub or GitLab.
-1. **Make additional changes**: After reviewing, make any changes in your web editor. Saving your changes will update your pull request.
-1. **Merge when ready**: When your pull request is ready, merge it to deploy changes to your live documentation site.
+Pull requests provide:
+- **Preview opportunity**: See exactly how changes will look before publishing
+- **Team input**: Get feedback and suggestions from colleagues
+- **Change history**: Keep a clear record of what changed and why
+- **Quality control**: Catch issues before they affect your readers
-## Troubleshooting
+### Reviewing and refining your pull request
-Here are solutions to common issues you might encounter with the web editor.
+After creating a pull request:
-
-
- **Possible causes:**
+
+
+ Click the link to view your pull request in your Git provider (GitHub or GitLab). You'll see a comparison of what changed.
+
+
+ Return to the web editor to make any refinements. When you save changes, they automatically update your pull request.
+
+
+ Team members can add comments, suggestions, or approve your changes. Use their feedback to improve your content.
+
+
+ Once you and your team are satisfied, merge the pull request to publish your changes to the live site.
+
+
+
+
+Even solo writers benefit from pull requests. They give you a final chance to review major changes in context before they go live, helping you catch issues you might miss when focused on writing.
+
+
+## Essential Git concepts made simple
+
+The web editor handles Git automatically, but understanding these concepts helps you work more confidently and collaborate effectively with developers on your team.
- - Deployment is still in progress
- - Caching issues in your browser
+
+
+ Think of your repository as the master filing cabinet for all your documentation files and their complete history. The web editor connects to this cabinet to access and modify your content safely.
+
- **Solutions:**
+
+ Every time you save changes, you create a commit – a snapshot of your work at that moment. Commits include your changes plus a description of what you did, creating a helpful timeline of your documentation's evolution.
+
- 1. Check deployment status in your Mintlify Dashboard.
- 2. Try hard refreshing your browser (Ctrl + F5 or Cmd + Shift + R).
- 3. Clear your browser cache.
+
+ A branch gives you a separate space to work on changes without affecting your live documentation. It's like having a draft copy where you can experiment freely before publishing.
-
- **Possible causes:**
- - Insufficient permissions to the Git repository
- - Authentication issues with your Git provider
+
+ This is the branch (usually called `main`) that contains your published documentation. When readers visit your docs site, they see the content from this branch.
+
- **Solutions:**
+
+ A pull request lets you propose merging your branch changes into your live documentation. It's your opportunity to review, discuss, and refine changes before they go public.
+
- 1. Verify you have correct access to the repository.
- 2. Check if your Git integration is properly configured.
- 3. Review the [Editor Permissions](/advanced/dashboard/permissions) documentation.
+
+ A diff shows the specific differences between two versions of your content, highlighting what was added, removed, or modified. This helps you understand exactly what each change does.
-
- **Possible causes:**
+
+
+### What the web editor handles for you
- - Network connectivity problems
- - Large documentation repositories
+You don't need to learn Git commands – the web editor manages everything behind the scenes:
- **Solutions:**
+- **Opening files**: Automatically fetches the latest version from your repository
+- **Tracking changes**: Keeps track of your edits as you work
+- **Saving work**: Creates commits with your changes and helpful descriptions
+- **Managing branches**: Creates and switches between branches as needed
+- **Publishing**: Pushes changes to your live site or creates pull requests for review
- 1. Check your internet connection.
- 2. Refresh the page and try again.
- 3. Contact support if the issue persists.
+This automation lets you focus on creating great content while maintaining professional version control practices.
+
+## Troubleshooting common issues
+
+Even with the web editor's user-friendly design, you might occasionally encounter issues. Here are solutions to the most common problems:
+
+
+
+ This usually happens because deployments take a few minutes or your browser is showing cached content.
+
+ **Try these solutions:**
+ 1. Wait 2-3 minutes for deployment to complete, then check your site again
+ 2. Hard refresh your browser: **Ctrl + F5** (Windows) or **Cmd + Shift + R** (Mac)
+ 3. Clear your browser cache if the issue persists
+ 4. Check your dashboard for deployment status – there might be an error to resolve
+
+
+
+ This typically indicates a permissions issue with your Git repository or authentication problems.
+
+ **Check these items:**
+ 1. Verify you have write access to the documentation repository
+ 2. Ensure your Git integration (GitHub or GitLab) is properly connected
+ 3. Try refreshing the page and attempting the save again
+ 4. Contact your admin if you're unsure about your permissions
+
+
+
+ Network issues or large repositories can sometimes cause loading problems.
+
+ **Try these steps:**
+ 1. Check your internet connection stability
+ 2. Refresh the page and wait a bit longer for loading
+ 3. Try using a different browser or clearing your browser cache
+ 4. If you have a very large documentation repository, loading may take longer than usual
+
+
+
+ Don't panic! Git keeps a complete history of all your changes, so nothing is permanently lost.
+
+ **Recovery options:**
+ 1. If you haven't saved yet, use **Ctrl + Z** (Windows) or **Cmd + Z** (Mac) to undo
+ 2. If you've already saved, ask a team member with Git experience to help restore from the repository history
+ 3. Check if you have the content backed up elsewhere and can re-add it
+ 4. Contact support if you need help recovering important content
+
+## Next steps: Building your documentation workflow
+
+You now have the foundation to create, edit, and publish documentation confidently using the web editor. Here are some ways to build on these skills:
+
+**Immediate actions you can take:**
+- Practice creating a branch and making a small edit to get comfortable with the workflow
+- Explore the component menu by pressing **/** and trying different content types
+- Set up a simple pull request workflow, even if you work alone
+
+**As you grow more comfortable:**
+- Develop naming conventions for your branches that work for your team
+- Create templates for common page types to speed up content creation
+- Establish review processes that help maintain content quality
+
+**Advanced techniques to explore later:**
+- Learn how navigation organization affects user experience
+- Experiment with different component combinations to create engaging content
+- Collaborate with developers on your team who might work with the CLI tools
+
+The web editor gives you everything you need to create professional documentation without technical barriers. Focus on creating valuable content for your users – the editor handles the technical complexity for you.
\ No newline at end of file