Website preview running locally on a laptop
Website file being edited and saved
Webbie pointing at a checklist
Webbie says

A website becomes real when the files are saved in the right places.

This is where planning becomes structure. You are not publishing yet. You are building a local working copy that you can inspect, improve, and trust before it ever goes online.

What this step is really about

Saving files and testing locally sounds simple, but it teaches some of the most important habits in web work:

  • putting the right files in the right folders
  • using the filenames you already approved
  • keeping shared files like site.css and site.js centralized
  • making sure images live in the right image folder
  • opening pages in the browser and checking what actually works

This is the first point where your project starts behaving like a real website instead of a stack of notes.

What you should already have before this step

By now, you should already know:

  1. what the site is
  2. who it is for
  3. what the sections are
  4. what the filenames are
  5. what image assets you plan to use

If those parts are still unclear, go back and tighten them first.

Core principle

Save deliberately, not casually.

Random files on the desktop lead to random websites. One clean project folder leads to a stronger site.

Make one clear local website folder

Start with one main project folder. For example:

C:\website\

Everything for this site should live inside that folder. This makes the project easier to understand and much easier to publish later.

A clean local starter structure

C:\website\
├── index.html
├── site.css
├── site.js
├── images\
├── en\
│   ├── index.html
│   ├── about.html
│   ├── faq.html
│   ├── training\
│   └── tools\
└── ja\
    ├── index.html
    ├── about.html
    ├── faq.html
    ├── training\
    └── tools\

This is not about having every page completed immediately. It is about giving the site a stable home.

What files belong at the top level?

File or folder Why it belongs there
index.html Main root entry page
site.css Shared styling for the whole site
site.js Shared behavior and interaction
images/ Central image library
en/ English pages
ja/ Japanese pages

What belongs inside subfolders?

Each section should contain the pages you already decided in Step 03.

Example

C:\website\en\tools\
├── index.html
├── putty-basics.html
├── winscp-basics.html
└── vi-basics.html

This is where filename discipline starts paying off. You already know what belongs in the folder because you planned it first.

How to save your first real files

At a minimum, save:

  • one or more HTML pages
  • the shared site.css
  • the shared site.js
  • the image files you are ready to use

Example save pattern

C:\website\site.css
C:\website\site.js
C:\website\en\training\step-01-build-locally-first.html
C:\website\en\training\step-02-define-the-site.html
C:\website\images\webbie-pointing.jpg

Try to avoid saving files in temporary random places and promising yourself you will sort them out later.

Important

Use the approved filenames, not improvised variations.

If the file tree says step-02-define-the-site.html, do not save it as define-site-final.html or step2.html. That weakens the whole workflow.

How to connect pages to shared CSS and JS

Every HTML page should reference the shared site files consistently.

If you are using root-based paths, you may write:

<link rel="stylesheet" href="/site.css">
<script defer src="/site.js"></script>

But when you are testing purely from local files, some people prefer relative paths depending on the setup. For example:

<link rel="stylesheet" href="../../site.css">
<script defer src="../../site.js"></script>

What matters most is that the references match your local file structure.

Example: one simple local page with shared files

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>My Training Page</title>
  <link rel="stylesheet" href="../../site.css">
</head>
<body>
  <main>
    <h1>My Training Page</h1>
    <p>This page is being tested locally before publishing.</p>
  </main>
  <script defer src="../../site.js"></script>
</body>
</html>

Save that file in:

C:\website\en\training\step-01-build-locally-first.html

Then open it in the browser and see whether the layout and shared styles are working.

How to save images locally

Keep your images together in the site’s image folder:

C:\website\images\

Example:

C:\website\images\make-website-hero-main.jpg
C:\website\images\webbie-pointing.jpg
C:\website\images\website-workflow-diagram.jpg

Then your HTML can reference them in a consistent way.

Example image line

<img src="../../images/webbie-pointing.jpg" alt="Webbie pointing at a checklist">

Or, depending on your local layout and how you preview files, another relative path pattern may be appropriate. The key lesson is the same: the image file should really exist in the location your HTML expects.

Image workflow showing assets and their use in website building

How to test a page locally

Once a page is saved, test it in a browser. The most basic method is simply:

  1. navigate to the file on your computer
  2. double-click the HTML file
  3. open it in a browser
  4. inspect the page carefully

You are checking for practical things like:

  • does the page open at all?
  • does the CSS load?
  • does the JS load?
  • do the images appear?
  • do the internal links go where they should?
  • does the layout look reasonable on desktop?

What to check when you preview locally

Check What to look for
Title Does the browser tab show the expected page title?
Navigation Do links point to the correct local pages?
Images Are all planned images visible?
Shared CSS Does the styling look correct?
Shared JS Do expected interactions work?
Spacing and readability Does the page feel clear and calm?

How local testing teaches real website skills

This step is about more than just “opening a page.” It teaches you:

1

File awareness

You learn which files are actually affecting the page and where they live.

2

Path awareness

You begin to understand how pages, CSS, JavaScript, and images connect to one another.

3

Revision discipline

You stop treating pages as magical output and start treating them as files you can inspect and improve.

4

Publishing readiness

When the site eventually goes online, it will already be more stable because it was tested first.

Example: testing one training page locally

Let us say you saved:

C:\website\en\training\step-03-decide-filenames.html

You open it in your browser and check:

  1. does the page title appear correctly?
  2. does the hero eyebrow show “Step 03”?
  3. does the image load?
  4. does the “Next step” button point to Step 04?
  5. does the CSS apply correctly?

If not, you fix it locally first.

What if something looks wrong?

Good. That is why you are testing locally.

If something is broken, check:

  • did I save the file in the correct folder?
  • did I use the correct filename?
  • does the CSS path match the file location?
  • does the image actually exist in the image folder?
  • did I misspell a path?
Good habit

When something breaks, inspect paths first.

A surprising amount of local website trouble comes from a wrong path, a wrong folder, or a wrong filename.

Local testing does not need to be fancy

At this stage, you do not need advanced deployment systems or complicated local hosting tools. The point is to prove that:

  • the files are organized
  • the page opens
  • the structure works
  • the site can be reviewed calmly

Later you can add more advanced methods. Right now, clarity matters more than complexity.

How this step prepares you for publishing later

If your local files are already clean, publishing later becomes much easier. You will already know:

  • which HTML files exist
  • which shared files exist
  • which image files belong to the site
  • what paths the pages expect
  • what should happen when the site goes live

That is exactly why this step belongs before uploading.

Diagram showing shared site.css and site.js used across pages

Common beginner mistakes

1. Saving files in inconsistent places

One page in Downloads, one page on the Desktop, one image somewhere else—this is how confusion begins.

2. Forgetting the shared files

If a page references site.css or site.js, those files need to exist where the page expects them.

3. Using the wrong filename

If the approved tree says winscp-basics.html, do not save winscp.html and hope to clean it up later.

4. Testing only one page and assuming the whole site works

Each page should be opened and checked, especially when the internal links and image paths vary by folder depth.

5. Waiting until upload time to discover broken paths

Local testing exists so you can discover those problems before publishing.

Important workflow lesson

A broken local page is useful information. A broken live page is public embarrassment.

That is why local testing comes before upload.

What you should have by the end of this step

By the end of Step 05, you should have:

  • a clean local website folder
  • the approved HTML files saved in the correct directories
  • site.css and site.js saved at the root level
  • the image assets saved in the image folder
  • at least a few pages opening locally in the browser
  • a working habit of checking structure before publishing
Practical principle

Saving files properly is part of website design.

It is not merely housekeeping. Clean file placement leads to cleaner builds, better testing, and less dependence on other people later.

Mini cheat sheet

At this step:
- save all files into one clean local project folder
- use the approved filenames and folders
- save site.css and site.js at the root level
- save images in the images folder
- open pages in a browser and inspect them
- fix path problems before publishing
Ready check

Can you do these six things?

Completed: 0/6

Next step Once the local files are in place, the next lesson covers when and how to upload images and files when the project is ready.
Next: Upload Images When Ready