MGU Computer Science Series — Web Development: HTML, CSS, and JavaScript

Part VI: Quality, Accessibility, Testing, and Publishing

Hosting · Domains · Deployment · Version Control · Maintenance

Chapter 30 of 30

MGU Computer Science Series · Web Development: HTML, CSS, and JavaScript · Library Textbook Edition

Chapter 30:
Publishing and
Maintaining a Web Project

From a local project folder to a public website — hosting, domain names, deployment, version control, maintenance, documentation, and presenting your finished work

■ Part VI of VII ■

■ 11 Sections • Capstone Chapter 30 of 30 ■

Final chapter of the course — brings HTML, CSS, JavaScript, accessibility, and responsive design together into one published website

Chapter 30 — Front Matter

Chapter Introduction and Learning Objectives

For twenty-nine chapters, your website has lived in one place: your own computer. You have opened it in a browser using an address that begins with file://, visible only to you. That is about to change. This chapter takes the project you have been building — structured with HTML, styled with CSS, brought to life with JavaScript — and walks it through the final stretch: review, cleanup, testing, hosting, a domain name, deployment, and the habits that keep a website healthy long after it goes live.

Publishing a website is not the end of web development. It is the beginning of a different kind of work: maintenance. A published website is a living thing. Browsers update. Links break. Content goes out of date. The skills in this chapter — reviewing, testing, documenting, and planning for maintenance — are what separate a website that quietly decays from one that stays useful for years.

Opening Question

You have built pages, styled them, made them interactive, and organized them into a small site. Right now, the only person who can see that site is you, sitting at the same computer where you built it. What has to happen for a stranger on the other side of the world to type a web address and see your work — correctly, on their device, in their browser? And once that happens, what keeps it working a year from now? This chapter answers both questions, and gives you a plan for keeping the answer "yes" long after launch day.

11Sections

12Objectives

17Key Terms

30Total Chapters

Learning Objectives

By the end of this chapter, you should be able to:

1Explain the difference between a local project and a published website.
2Conduct a final project review that checks content, structure, style, and functionality across every page.
3Clean and organize a project's files and folders before publishing.
4Test links, images, and script paths systematically, and recognize common path mistakes.
5Compare common hosting options for a beginner website at an introductory level.
6Explain what a domain name is and how it relates to hosting through DNS.
7Describe the basic steps of deploying a finished website to a live server.
8Explain the purpose of version control and describe repositories and commits at an introductory level.
9Explain why published websites require updates, backups, and ongoing maintenance.
10Write documentation, including a README, that helps others — and future you — understand a project.
11Prepare and present a finished website clearly to an audience.
12Apply a complete publishing checklist to a real project before launch.

Chapter 30 — Contents

Sections at a Glance

30.1From Local Project to Public WebsiteLocal files versus published websites; what "going live" means; the gap between file:// and https://
30.2Final Project ReviewReviewing content, structure, style, and functionality across every page before launch
30.3Cleaning Files and FoldersRemoving unused files, fixing inconsistent names, organizing assets, trimming dead code
30.4Testing Links and PathsChecking internal links, external links, image paths, and script paths; finding and fixing broken references
30.5Hosting Options at an Introductory LevelWhat a web host does; static hosting, shared hosting, and choosing a host for a learning project
30.6Domain Names at a Basic LevelWhat a domain name is; how DNS connects names to servers; registrars and subdomains
30.7DeploymentMoving files from a local project folder to a live server; verifying the site after deployment
30.8Version Control at an Introductory LevelWhat version control is; repositories, commits, and history; why solo developers use it too
30.9Updates, Backups, and MaintenanceWhy finished websites still need attention; building a simple maintenance plan; backups
30.10Documenting a Web ProjectWriting a README; documenting structure and decisions for future maintainers, including future you
30.11Presenting the Final WebsiteWalking an audience through a finished project; demonstrating accessibility and responsiveness

Section 30.1

From Local Project to Public Website

Throughout this book, your website has existed as a folder of files on one computer. When you opened index.html in a browser, the address bar showed something like file:///Users/yourname/web-project/index.html. That address only means something on your machine. No one else can type it into their own browser and see your page.

A published website is different. It lives on a server — a computer that stays on and connected to the internet, waiting to respond to requests — and it is reachable through a web address that anyone, anywhere, can type or click. Chapter 2 introduced clients, servers, and requests in the abstract. Publishing a website is where that abstraction becomes real for a project you built yourself.

Going live involves more than copying files. It means your HTML, CSS, JavaScript, images, and data files all need to work correctly outside the safety of your own folder structure — on a different computer, accessed by browsers you do not control, by people who may have slower connections, smaller screens, or assistive technology you have not tested with directly.

Side by Side

What changes between your computer and the public web

AddressLocal: file:///.../web-project/index.html, meaningful only on your computer. Published: https://yoursite.example/, reachable by anyone with the link.
AudienceLocal: just you, testing as you build. Published: any visitor, on any device, browser, or connection speed.
File pathsLocal: relative paths point to folders on your hard drive. Published: the same relative paths now point to folders on the host's server — which is why the clean project structure from Chapter 3 matters so much.
PermanenceLocal: you can fix a mistake before anyone sees it. Published: visitors may see a broken page or outdated content until you notice and redeploy.

Why This Chapter Comes Last

Every earlier chapter assumed your project might still change. This chapter assumes you are close to finished — at least for now. The review, clean, test, and deploy sequence in this chapter works for any milestone where you want to share your project, not only one permanent launch day.

Section 30.2

Final Project Review

Before any project goes live, it deserves one last careful look — not a quick glance at the homepage, but a deliberate pass through every page, checking the same four things every time. A final review is not about finding new features to add. It is about confirming that what you already built actually does what you intended.

Review Area 1

Content

Is every page complete? Are there placeholder words, "TODO" notes, or unfinished sentences left behind? Is the information accurate and current?

Review Area 2

Structure and Semantics

Does every page use a logical heading order (Chapter 6)? Are landmarks like header, nav, main, and footer used correctly? Does the markup validate?

Review Area 3

Style and Layout

Does the site look intentional on a phone, a tablet, and a desktop (Chapter 17)? Are spacing, color, and typography consistent across every page?

Review Area 4

Functionality and Accessibility

Do all interactive features — forms, accordions, tabs — work as intended? Can the site be used with a keyboard alone? Do images have meaningful alt text?

Common Pitfall

A website that looks perfect on the screen you built it on can look broken on someone else's. Resize your browser window, test on a phone if you can, and use the browser's responsive preview tool (Chapter 4) before you call a page finished.

Section 30.3

Cleaning Files and Folders

Projects accumulate clutter as they grow. Draft pages you meant to delete, images you tried and replaced, debugging code you forgot to remove, files named inconsistently because you were moving quickly — all of it can still be sitting in your project folder, even though it does nothing useful anymore.

Cleaning a project means going through it deliberately and removing or fixing anything that does not belong in the finished, published version.

The Cleanup Rule

If a file is not linked from anywhere and not used by anything, remove it or archive it outside the project folder. A published website should contain only what visitors' browsers actually need to load. Leftover draft files are not just clutter — they can confuse you later, can be reached directly if someone guesses the address, and add unnecessary size to your project.

Clutter Type	What It Looks Like	Cleanup Action
Old draft pages	`about-draft.html`, `about2.html`	Delete, or merge useful content into the final page
Leftover images	`screenshot.png`, `test.jpg`, unused hero images	Remove unused files from the images folder
Debug code	`console.log()` calls, large commented-out blocks	Remove before publishing
Inconsistent naming	`About Us.html`, `Contact_Page.html`	Rename using lowercase letters and hyphens (Chapter 3)
Duplicate stylesheets	`style.css` and `style-old.css` both still linked somewhere	Keep one current stylesheet; remove the rest

Section 30.4

Testing Links and Paths

Broken links and missing images are among the most common — and most avoidable — problems on published websites. A path that worked perfectly while you were building the site can break the moment files move to a different folder structure on a host. The only reliable defense is to test every path deliberately, rather than assuming it still works.

Example 30.4.1

A simple link-testing routine

List pagesWrite down every HTML file in your project so you do not miss one during testing.
Click every linkInternal links should load the correct page; external links should open the correct site.
Check mediaA broken image shows a missing-image icon or its alt text instead of a picture; confirm that every src path resolves.
Check CSS and JS linksOpen the browser console (Chapter 4); a failed file load reports an error there even if the page still "looks fine" without scripting.
Test from a fresh copyCopy your project folder to a new location, or another computer, and test again — paths that secretly depended on your original folder structure will reveal themselves here.

Tip

Relative paths (Chapter 3) are usually the right choice for a project hosted in one folder, because they keep working no matter what domain the project is eventually published under. Absolute paths that point back to your own local computer are a common source of broken links after deployment.

Section 30.5

Hosting Options at an Introductory Level

A web host is a service that stores a website's files on a server and makes them available to visitors over the internet. Choosing a host is one of the first decisions in publishing a project, and for a beginner HTML, CSS, and JavaScript site — with no server-side code — the choice is simpler than it might first appear.

Hosting Type	Description	Good Fit For
Static hosting services	Hosting designed specifically for fixed HTML, CSS, and JavaScript files, often connected directly to a version-control repository	Student projects, portfolios, small sites with no server-side processing
Shared hosting	Rented space on a server shared with other websites' files, typically managed through FTP or a web-based file manager	Sites that may later add server-side languages or databases
School or library hosting	Hosting provided through an educational institution, often with simplified publishing tools	Class projects and learning exercises
Self-managed servers	A server an individual or organization configures and maintains directly	Advanced projects; outside the scope of this book

Because your project so far contains only static files — files that are the same every time they are requested, with no server-side program generating them on the fly — a static hosting service is usually the most direct fit. The site only needs somewhere to sit and be delivered, not a server running programs on your behalf.

Looking Ahead

Later courses on databases and full-stack development introduce hosting environments that run server-side code. The static hosting concepts in this chapter remain useful even then, because most full systems still serve at least some static files — images, stylesheets, and client-side scripts — exactly the way you will practice here.

Section 30.6

Domain Names at a Basic Level

A domain name is a unique, registered name — such as example.com — that identifies a website in a form people can remember and type. Behind the scenes, DNS (the Domain Name System) translates that human-readable name into the address computers actually use to find the correct server, the way a phonebook translates a name into a number.

A Key Insight About Domain Names

A domain name does not store your website. It is a label that points, through DNS, to wherever your website's files actually live. Choosing a host and registering a domain name are two separate decisions — you can register a name with one company and host your files with a completely different one, then connect the two through DNS settings.

Domain Name Part	Example	What It Identifies
Subdomain	`www` in `www.example.com`	A named section of a larger domain
Domain name	`example` in `example.com`	The unique, registered name an organization or person owns
Top-level domain (TLD)	`.com`, `.org`, `.edu`	A category, often historically tied to a type of organization or a country

Many hosts, especially static hosting services aimed at students and beginners, provide a working address automatically — no domain purchase required. Registering a custom domain name through a registrar is a separate, optional step usually taken when a project is ready for a more permanent, memorable address.

Section 30.7

Deployment

Deployment is the process of moving a website's files from a local project folder onto a live server. It is the step where review, cleanup, and testing (Sections 30.2–30.4) stop being preparation and become the actual content the public will see.

Example 30.7.1

A typical deployment sequence

PrepareConfirm your final review, cleanup, and link testing from Sections 30.2–30.4 are complete using your local copy.
UploadTransfer the entire project folder structure to the host, keeping relative paths between HTML, CSS, JavaScript, and image folders exactly as they were locally.
ConnectIf using a custom domain, point its DNS settings to the host as instructed by the host and the registrar.
VerifyVisit the live public address yourself, ideally on more than one device, and repeat the link- and path-testing routine from Section 30.4.
ShareShare the link, or submit it for review, only after verification.

Common Pitfall

Uploading only the files you think changed, and forgetting a new image, script, or page, is one of the most common deployment mistakes. When in doubt, upload the entire project folder rather than guessing at the difference.

Section 30.8

Version Control at an Introductory Level

Version control is a system for tracking changes to a project's files over time — recording what changed, when, and why — and allowing earlier versions to be recovered if something goes wrong. Git is the most widely used version control system today, and many static hosting services connect directly to a Git repository as their deployment method.

Term

Repository

A folder of files tracked by a version control system, along with the complete history of changes made to those files.

Term

Commit

A saved snapshot of a project at a point in time, paired with a short message explaining what changed and why.

Term

History

The complete sequence of commits, which lets you see how a project evolved and revert to an earlier state if needed.

Term

Remote

A copy of a repository stored elsewhere, often a hosting service, used for backup, sharing, and deployment.

Study Note

This chapter introduces version control only at a conceptual level. A full treatment of Git commands belongs in a dedicated tool or later course; what matters here is understanding why developers — even those working alone on small projects — treat "save a commit with a clear message" as seriously as "save the file."

Section 30.9

Updates, Backups, and Maintenance

A published website does not stay finished on its own. Content goes stale. External sites you linked to may move or disappear, a problem called link rot. Browsers and devices keep changing. A maintenance plan — a documented schedule of recurring tasks — keeps a website healthy long after launch day, instead of leaving its health to chance.

Maintenance Task	Suggested Frequency	Why It Matters
Check for broken links	Monthly	External sites move or close; broken links erode trust
Review content accuracy	Monthly or after major changes	Outdated information is misleading
Test on current browsers and devices	Every few months	Browsers and devices update continuously
Back up the project	Before and after major changes	Protects against accidental loss or a bad deployment
Review accessibility	Periodically and after redesigns	New content or features can introduce new accessibility issues

The Maintenance Mindset

A website is not a document you finish once; it is a system you keep healthy. Treat backups the same way you treat commits in version control (Section 30.8): frequent, small, and labeled clearly enough that you can tell what each one represents.

Section 30.10

Documenting a Web Project

A README is a plain-language document, usually placed at the top level of a project, that explains what the project is, how it is organized, and how to use or run it. Good documentation answers the questions a stranger — or you, six months from now — would ask before touching the project at all.

Example 30.10.1

A simple README outline

PurposeA sentence or two describing what the website is and who it is for.
StructureA short list or diagram of the main folders — css/, js/, images/, data/ — and what each contains.
How to view itInstructions for opening the project locally, such as opening index.html in a browser.
CreditsAttribution for any fonts, images, or external code used, consistent with the copyright awareness covered in Chapter 8.
Known limitsAnything left unfinished or intentionally out of scope, so future readers do not mistake a limitation for an oversight.

Tip

Write documentation as if you will not remember any of this later — because you probably will not. A README written immediately after finishing a feature is almost always better than one written from memory months afterward.

Section 30.11

Presenting the Final Website

A finished website deserves to be shown, not just shared as a link. Presenting a project clearly — to an instructor, a class, or a future employer — means walking through it with purpose: explaining what it is for, demonstrating that it works, and being ready to talk honestly about decisions and trade-offs.

Presentation Guide

A simple structure for presenting your finished site

IntroduceState the purpose of the site and its intended audience in one or two sentences.
TourNavigate through the main pages in a logical order, narrating what each page is for.
ResponsivenessResize the browser window or use a device preview tool (Chapter 4) to show the layout adapting.
InteractivityTrigger at least one JavaScript feature, such as a form validation message or an accordion.
AccessibilityShow a heading outline, meaningful alt text, or keyboard-only navigation through a key feature.
ReflectName one decision you are proud of and one thing you would improve with more time.

Chapter 30 — Back Matter

Chapter Summary

Section 30.1A local project lives only on your computer, reachable through a file:// address. A published website lives on a server and is reachable by anyone through a web address. Publishing means making HTML, CSS, JavaScript, and media work correctly outside the folder where you built them.
Section 30.2A final project review checks four areas across every page: content completeness, structural and semantic correctness, visual style and layout, and functionality and accessibility — not just on the device used to build the site.
Section 30.3Cleaning a project means removing unused drafts, debugging code, and inconsistent filenames before publishing, so the live site contains only what visitors' browsers actually need.
Section 30.4Every internal link, external link, image path, and script path should be tested individually, ideally from a fresh copy of the project folder, to catch path problems before they reach visitors.
Section 30.5A web host stores a site's files and serves them to visitors. Static hosting services fit beginner HTML, CSS, and JavaScript projects well; shared hosting and other options support more advanced needs covered in later courses.
Section 30.6A domain name is a label that points, through DNS, to wherever a website's files actually live. Choosing a host and registering a domain name are separate decisions that can be made independently and connected afterward.
Section 30.7Deployment moves a reviewed, cleaned, and tested project from a local folder to a live server, and is followed by testing the public address itself — not only the local copy.
Section 30.8Version control tracks a project's history of changes through commits stored in a repository, giving developers — including solo students — a safety net and a record of how a project evolved.
Section 30.9Published websites need ongoing maintenance: checking for broken links and link rot, reviewing content accuracy, testing on current devices, and keeping backups, ideally on a documented recurring schedule.
Section 30.10Documentation, especially a clear README, explains a project's purpose, structure, and decisions to anyone who encounters it later, including the original author after time has passed.
Section 30.11Presenting a finished website means walking an audience through its purpose, navigation, responsiveness, interactivity, and accessibility, and being ready to explain key decisions and possible improvements.

Key Terms

backup

A separate, saved copy of a website's files kept somewhere other than the live hosting account, used to recover work after data loss or a bad deployment.

commit

A saved snapshot of a project at a point in time, recorded by a version control system together with a short message describing what changed.

deployment

The process of transferring a website's files from a local project folder to a live server so the public can access it.

DNS

The Domain Name System — translates human-readable domain names into the addresses computers use to locate servers on a network.

domain name

A unique, registered name, such as example.com, that identifies a website and can be pointed at a host through DNS.

FTP

File Transfer Protocol — a method for transferring files between a local computer and a remote server, traditionally used to upload a website to a host.

web host

A service or company that stores a website's files on a server and makes them available to visitors over the internet.

link rot

The gradual breaking of links over time as the pages or sites they point to are moved, renamed, or removed.

maintenance plan

A documented schedule of recurring tasks, such as checking links and reviewing content, that keeps a published website healthy after launch.

README

A plain-language document, typically at the top level of a project, explaining what the project is, how it is organized, and how to use it.

registrar

A company through which a domain name is registered and renewed.

remote

A copy of a version-controlled repository stored on another computer or service, often used for backup, sharing, and deployment.

repository

A project folder tracked by a version control system, along with its complete history of changes.

static hosting

Hosting designed specifically for websites made of fixed HTML, CSS, JavaScript, and media files, without server-side processing.

subdomain

A named subdivision of a domain, such as www in www.example.com or blog in blog.example.com.

version control

A system for tracking changes to a project's files over time, recording what changed, when, and why, and allowing earlier versions to be recovered.

TLD

Top-level domain — the final segment of a domain name, such as .com, .org, or .edu, historically associated with a category of organization or a country.

Concept Check

Answer these questions before beginning the full review activities below. They check basic understanding, not deep analysis.

What is the difference between a local file address (file://) and a published website address (https://)?
List the four areas a final project review should check.
Give two examples of files or code that should usually be removed before publishing a project.
Why should you test links and paths using a fresh copy of your project folder rather than only your original working folder?
What is the difference between choosing a web host and registering a domain name?
What is a commit, and why might a solo developer use version control even without a team?
Name two tasks that belong in a website's ongoing maintenance plan.

Common Misconceptions

Misconception 1

"Once a website is published, the work is finished."

Publishing is the start of a new phase, not the end of one. Content goes out of date, external links break, and devices and browsers keep changing. A maintenance plan (Section 30.9) treats a published website as something to keep healthy, not something to walk away from.

Misconception 2

"You must buy a custom domain name to publish a real website."

Most hosting services provide a working public address automatically, at no extra cost. A custom domain name is a separate, optional step usually taken when a project is ready for a more memorable, permanent address — not a requirement for publishing at all.

Misconception 3

"Version control is only useful for teams of programmers."

A solo developer benefits from version control too: it provides a safety net for undoing mistakes, a record of how a project evolved, and — for many static hosting services — the actual mechanism by which a deployment happens.

Misconception 4

"If a website works correctly on the computer where it was built, it will work correctly everywhere."

Different operating systems, browsers, devices, and even file-naming rules on a host's server can reveal problems invisible on your own machine. This is exactly why Section 30.4 recommends testing from a fresh copy of the project folder, not only the original.

Misconception 5

"Backing up a website and using version control are the same thing."

Version control tracks a detailed history of changes to a project's files, useful for understanding and reverting specific edits. A backup is a broader safeguard against total loss — including loss of the hosting account or repository itself. The two serve related but different purposes, and a careful project uses both.

Pre-Launch Publishing Checklist

Confirm every item before sharing your website's public address

Content and Structure

Every planned page exists and contains finished content, with no placeholder text remaining.
Headings on every page follow a logical order, and each page has exactly one main heading.
Every page uses appropriate semantic landmarks: header, nav, main, and footer.

Style and Responsiveness

The site looks intentional at a phone width, a tablet width, and a desktop width.
Spacing, color, and typography are consistent across every page.
No CSS rules reference styles or fonts that were never linked.

Functionality and Accessibility

Every link, button, form, and interactive component has been tested and works as intended.
Every image has meaningful alternative text, and decorative images are marked appropriately.
Every form field has a visible, properly associated label.
The site can be navigated using a keyboard alone.

Hosting and Deployment

Unused files, draft pages, and debug code have been removed from the project folder.
Every internal link, image path, and script path has been tested from a fresh copy of the project folder.
A hosting option has been chosen and, if applicable, a domain name has been connected.
The live, public version of the site has been tested after deployment — not only the local copy.
A backup of the finished project exists outside the hosting account itself.

ActivitiesBuild a Maintenance Plan

Use Section 30.9 as a starting point to design a maintenance plan for your own project.

Using the table in Section 30.9 as a model, list at least six specific maintenance tasks for your own project — for example, "confirm the contact form still sends its confirmation message," rather than only generic tasks.
Assign a realistic frequency to each task: weekly, monthly, every few months, or "after any major change."
Decide who is responsible for each task. For a class project, this is probably you; for a team project, assign an owner to each item.
Identify one task on your list that, if skipped for six months, would most likely cause a visitor-facing problem. Explain why.
Write one sentence describing where and how you will keep backups of your project, and how often you will update them.

Final Website Rubric

Use this rubric to evaluate your own finished project, or have a classmate evaluate it, before considering it complete.

Category	Developing	Proficient	Exemplary
HTML Structure & Semantics	Markup is mostly valid; some headings or landmarks are missing or out of order	Markup is valid; headings follow a logical order; semantic landmarks are used appropriately throughout	All of Proficient, plus markup remains clean and meaningful even in complex sections, with no unnecessary generic elements where a semantic one would fit
CSS Style & Responsiveness	Styling is inconsistent across pages; layout breaks at some screen sizes	Styling is consistent; layout adapts cleanly across phone, tablet, and desktop widths	All of Proficient, plus the design uses a deliberate visual hierarchy and a maintainable system of reusable classes or variables
JavaScript Interactivity	Few or no interactive features; existing features behave unpredictably	At least one interactive feature works reliably and gives clear feedback to the user	All of Proficient, plus interactions are accessible by keyboard and degrade gracefully if a feature fails
Accessibility	Alt text, labels, or heading order are missing in multiple places	Images have meaningful alt text, form fields have labels, and the site can be navigated by keyboard	All of Proficient, plus color contrast, focus order, and assistive-technology behavior have been deliberately checked, not just assumed
Project Organization & Documentation	Files are inconsistently named or organized; little or no documentation exists	Files follow a clean, consistent structure; a README explains the project's purpose and organization	All of Proficient, plus documentation explains key decisions and would let an unfamiliar developer maintain the project confidently
Publishing & Maintenance Readiness	The project has not been deployed, or deployment has not been tested	The project is deployed, the live version has been tested, and a basic maintenance plan exists	All of Proficient, plus backups, version history, and a maintenance schedule are already in active use

Cumulative ReviewCumulative Web Development Review

These questions draw on concepts from across the entire course, not only this chapter.

Explain, in your own words, the difference between HTML, CSS, and JavaScript, and the kind of question each one answers about a web page.
A page's navigation menu looks correct on a desktop browser but overlaps the page content on a phone. Which earlier chapters' concepts would you use to diagnose and fix this, and why?
Explain why semantic HTML (Chapter 6) and accessible forms (Chapter 9) matter even on a website with no JavaScript at all.
Describe how the cascade, specificity, and source order (Chapter 12) interact when two CSS rules apply conflicting styles to the same element.
Explain the difference between an event listener (Chapter 21) and the DOM update it usually triggers (Chapter 22), using an example that does not appear in the textbook.
A site fetches data from a local JSON file (Chapter 28) to build a list of resources. What should happen on the page while the data is loading, and what should happen if the fetch fails?
Explain why responsive design (Chapter 17) and accessibility (Chapter 29) are described throughout this book as ongoing concerns rather than topics confined to a single chapter.
Trace the journey of a single web page from a folder on your computer (Chapter 3) to a live address a stranger can visit (this chapter). Name at least four checkpoints along the way.
Explain why a clean, well-organized project folder (Chapter 3) makes both debugging (Chapter 4) and publishing (this chapter) easier.
Choose one mini-project from an earlier chapter. Describe what you would check before considering it ready to add to a published portfolio site.

ReflectionFinal Reflection

Write honestly. These prompts are for your own understanding, not for a single correct answer.

Describe the moment in this course when a concept that initially confused you finally made sense. What changed?
Which is more comfortable for you right now: HTML and CSS, or JavaScript? Why do you think that is, and what would help close the gap?
Choose one mistake or bug you encountered while building your project. Explain what caused it and what you learned from fixing it.
If you were teaching Chapter 1 of this book to a friend with no web development background, what is the one idea from the entire course you would make sure they understood first?
What is one specific skill from this course you want to deepen in a future course — JavaScript Programming, Databases, Full-Stack Web Development, or another path — and why?

Course Completion Checklist

Confirm your overall command of the course before beginning a new pathway

Part I — Foundations of the Web

I can explain the difference between the internet, the web, a website, and a web page.
I can describe the roles of clients, servers, requests, and responses.
I can organize a project using files, folders, and correct relative paths.
I can use browser developer tools to inspect, debug, and test a page.

Part II — HTML: Structure and Meaning

I can build a valid, well-structured HTML document from scratch.
I can use semantic elements and a logical heading order to organize content and meaning.
I can build accessible navigation, links, images, lists, tables, and forms.
I can write metadata that communicates clearly with browsers and search engines.

Part III — CSS: Style and Layout

I can write CSS selectors and reason about the cascade, specificity, and inheritance.
I can style text, color, spacing, and borders to support readability.
I can build layouts using both Flexbox and Grid, and explain when to choose each.
I can make a layout responsive using relative units and media queries.
I can use CSS custom properties to build a small, reusable design system.

Part IV — JavaScript: Interaction and Logic

I can write and call functions, and trace simple JavaScript programs by hand.
I can use event listeners to respond to clicks, input, and form submissions.
I can select and update the DOM safely in response to user interaction.
I can use conditionals and loops to build dynamic, repeated content.
I can validate form input and give users clear, accessible feedback.

Part V — Web Projects and Components

I can build reusable page sections and apply them consistently across pages.
I can organize a multi-page site with shared navigation and consistent structure.
I can build common interface patterns, such as accordions or tabs, accessibly.
I can render data from a local JSON file onto a page, including loading and error states.

Part VI — Quality, Accessibility, Testing, and Publishing

I can audit a website for accessibility, performance, and validation problems.
I can review, clean, and test a project before publishing it.
I can choose a hosting option and deploy a finished website.
I can explain the basic purpose of version control, even at an introductory level.
I can build and follow a maintenance plan for a published website.
I can document a project so that someone else — or future me — can understand it.

What Comes Next

Beyond Web Development: HTML, CSS, and JavaScript

This chapter closes the course, but it does not close the subject. The skills in this book — structured HTML, organized CSS, interactive JavaScript, accessibility, responsive design, and now publishing and maintenance — are the foundation for several paths forward. JavaScript Programming builds on the language basics from Part IV into deeper, more general-purpose programming. Databases introduces the data layer behind dynamic, server-backed websites. Full-Stack Web Development brings server-side code, databases, and front-end skills together into complete web applications. Whichever path comes next, the habits from this course — reading code carefully, tracing examples, testing deliberately, and treating accessibility and maintenance as part of the job, not an afterthought — will keep serving you well.

MGU Library Connection

Web Development: HTML, CSS, and JavaScript — Appendix M: Full Glossary of Web Development Terms
Web Development: HTML, CSS, and JavaScript — Appendix K: Website Quality Checklist
Web Development: HTML, CSS, and JavaScript — Appendix L: Publishing and Maintenance Reference
Companion resource: Website Publishing Checklist
Companion resource: Final Web Project Rubric
Next course: JavaScript Programming (recommended for deeper language fundamentals)
Next course: Databases (recommended for students continuing toward full-stack development)
MGU Digital Literacy — background reading on maintaining a public digital presence

Chapter 30:Publishing andMaintaining a Web Project

Chapter Introduction and Learning Objectives

Learning Objectives

Sections at a Glance

From Local Project to Public Website

Final Project Review

Cleaning Files and Folders

Testing Links and Paths

Hosting Options at an Introductory Level

Domain Names at a Basic Level

Deployment

Version Control at an Introductory Level

Updates, Backups, and Maintenance

Documenting a Web Project

Presenting the Final Website

Chapter Summary

Key Terms

Concept Check

Common Misconceptions

Final Website Rubric

Chapter 30:
Publishing and
Maintaining a Web Project