Practice: Build a small CMS site

Course

Level 1 · Web Introduction

Module

CMS and findability

Required-path effort

360–600 minutes

Submission

Show the restored site and project files to your teacher

Assignment type

Individual implementation

Estimate assumptions: This provisional estimate covers the required path, including brief selection, project and repository setup, WordPress Playground setup, five pages, media, navigation, search-information checks, Git checkpoints, GitHub pushes, ZIP exports, visitor testing, restoration, support use, debugging, and re-entry. It assumes that you completed the preceding CMS, findability, and Git lessons. Optional extensions are not included. Optional extensions are not included.

Outcome

Build an independent five-page WordPress site in WordPress Playground. The site will have a planned hierarchy, stable paths, a static front page, prepared media, descriptive content links, primary navigation with a submenu, page-specific search information, visitor test evidence, and a restorable final ZIP export.

The requirements define one complete CMS result. You choose one content brief and write the site content. Use the assistance levels when you want more structure.

What you will practice

• Turn a content brief into a small CMS information architecture.
• Create and connect pages, media, settings, and navigation in WordPress.
• Use titles, summaries, headings, paths, links, and image text to describe each route.
• Test the visitor result across routes, input methods, narrow width, and zoom.
• Export and restore the complete CMS state instead of depending on one browser session.
• Use Git and GitHub to preserve the project plan and evidence while keeping CMS backup files separate.

Why this project matters

A CMS project combines content, settings, database state, templates, media, URLs, and navigation. The visible page is only one part of the product. A complete delivery must also preserve the CMS state and show how a visitor can find and understand each route.

What is new and what is reused

• New: Building a complete CMS result from a new brief without extending the lesson reference site.
• Reused: WordPress Playground, administration and visitor views, blocks, static front pages, page hierarchy, slugs, descriptive links, Navigation blocks, submenus, media alternatives, page-specific summaries, rendered titles, visitor testing, and complete ZIP exports.

Starting point

Before you start

• A current browser with a reliable internet connection and permission to download ZIP files.
• Access to WordPress Playground at https://playground.wordpress.net/.
• One prepared WebP image from the page-assets assignment or image lesson.
• A Level 1 projects folder where you can create a dedicated project repository.
• Git and a GitHub account that you can sign in to.
• The CMS foundations, content and navigation, and SEO foundations lessons for reference.

Current state

You have a completed CMS reference workflow, but the independent site, planning file, and exports for this assignment do not exist.

First action

Create a local folder named cms-site-practice, open it in VS Code, create cms-site-notes.md and .gitignore, and choose one content brief from this page.

First checkpoint

cms-site-practice has its own repository and private GitHub remote. The notes define the brief, visitor, five page roles, paths, and navigation order before WordPress content work begins.

Help trigger

Open the assistance for the current checkpoint or ask for help if Playground does not load, a page receives an unexpected path, a parent relationship or submenu will not save, the visitor view differs from the editor, an export fails, or an imported final ZIP does not restore the required state.

Keep complete exports outside the browser

A Playground tab is not the only copy of this project. Browser storage and temporary sessions can be cleared. Download the required checkpoints to cms-site-practice before you close the tab or begin a destructive import test.

Git does not replace the CMS exports

Git tracks cms-site-notes.md and .gitignore in this project. The .gitignore file excludes the complete Playground ZIP exports because Git cannot show useful line-by-line changes inside those binary backups. Keep both ZIP files in the project folder and submit them separately from the repository history.

Requirements

The required assignment is complete when every applicable criterion below is met.

Required deliverables

• cms-site-practice contains cms-site-notes.md, cms-structure-checkpoint.zip, and cms-site-final.zip.
• cms-site-final.zip is a complete WordPress Playground site export and is greater than 0 bytes.
• The final ZIP restores into a new Playground with the required settings, pages, media, hierarchy, navigation, and visitor result.

Version control and backup boundaries

• cms-site-practice is a Git repository on main with a private GitHub repository connected as origin.
• Git tracks cms-site-notes.md and .gitignore. The repository history contains the four required evidence commits.
• .gitignore excludes *.zip, so the complete CMS exports remain local deliverables instead of Git history.
• The final working tree is clean, the GitHub main branch contains the latest notes commit, and both required ZIP files remain in cms-site-practice.

Site structure and content

• The site has one accurate title, one short tagline, and a static Home front page.
• Five published pages provide the roles Home, About, Work, one Work detail page, and Contact. You can adapt the displayed labels to the selected brief.
• The Work detail page is saved as a child of Work and has a path nested below the Work path.
• Every page has one unique visible page title, a page-specific opening summary, and at least one additional section with a descriptive heading.
• The Home page contains one prepared WebP image from the Media Library with context-appropriate alternative text and a useful caption when the source needs one.

Navigation and link behavior

• Primary navigation exposes four top-level destinations in this order: Home, Work, About, Contact.
• The Work detail page appears inside a Work submenu rather than as a fifth top-level item.
• The submenu can open without pointer hover, and every navigation item works with the keyboard.
• Home contains a descriptive link to Work, Work links to the detail page, and the detail page provides a descriptive return path to Work.
• No published page depends on WordPress Admin as its only incoming route.

Basic search information

• Each page has a short, stable, descriptive slug and an accurate rendered HTML title.
• Page titles, opening summaries, headings, paths, link labels, and image text agree with the page purpose.
• Visible content contains no repeated keyword list, hidden text, false claim, or promise of search ranking.
• cms-site-notes.md separates verified page evidence from unverified crawling, indexing, traffic, or ranking outcomes.

Visitor experience and accessibility

• The visitor view, not only the editor preview, shows every required page and route.
• Page headings form a logical order and do not use heading levels for visual size alone.
• Link text identifies its destination or purpose without relying on nearby text.
• Required content, navigation labels, submenu controls, focus, and image information remain available at about 320 CSS pixels and 200% browser zoom.
• Browser Back and Forward preserve a usable route through the site in the same tab.

Technical constraints

• Build the required site in WordPress Playground or a teacher-approved equivalent CMS that supports complete backup and restore.
• Use a block theme and WordPress core features for the required result. A plugin is not required and must not replace the assessed page, navigation, media, or content decisions.
• Use a complete Playground ZIP export. The WordPress Tools export, screenshots, or copied page text do not replace the required restorable site checkpoint.
• Do not modify the lesson reference site and submit it as the independent assignment.

Design and content freedom

• Choose one supplied brief, write original safe content, select block arrangements, and choose a restrained visual style within the active theme.
• You can rename Work and its detail page when the new labels still communicate the same parent-child relationship and the final navigation remains clear.

Out of scope

• The required site does not need a public domain, hosting account, search-console property, e-commerce, forms that store data, user accounts, analytics, a custom theme, or custom PHP.
• The assignment does not prove that a search engine can crawl, index, rank, or display the Playground site.
• You do not need to complete an optional extension.

Definition of done

The required assignment is complete when every applicable requirement is met, all self-check routes pass in the visitor view, the four required evidence commits are on the private GitHub repository, cms-site-notes.md contains the final evidence, and cms-site-final.zip restores the same complete site in a new Playground instance.

Choose one content brief

Choose one brief. Keep the five required page roles even when you adapt their displayed names.

Brief A: Web student portfolio

• Visitor: A teacher or potential collaborator reviewing current web practice.
• Purpose: Explain the student’s focus and make one detailed project available for review.
• Work detail: A responsive profile-page case study.

Brief B: Fictional creative studio

• Visitor: A small organization comparing creative services.
• Purpose: Explain the studio’s focus and make one sample project available for review.
• Work detail: A fictional visual-identity or website case study.

Brief C: Community event information site

• Visitor: A person deciding whether to attend a fictional public event.
• Purpose: Explain the event and make one program item available for review.
• Work detail: A session, workshop, or activity page. You can display the parent label as Program instead of Work.

Use fictional names, reserved contact information, and public-safe content. Do not copy claims from a real organization or imply that a fictional event is real.

Checkpoint 1: Plan the site before opening the editor

Create this structure in cms-site-practice:

• Directorycms-site-practice/

  • .gitignore
  • cms-site-notes.md
  • cms-structure-checkpoint.zip
  • cms-site-final.zip

Add this rule to .gitignore:

cms-site-practice/.gitignore

*.zip

Add this plan to cms-site-notes.md:

cms-site-notes.md — site plan

# CMS site practice

## Brief

- Selected brief:
- Intended visitor:
- Site purpose:
- Site title:
- Tagline:

## Sitemap

- Home — `/` — static front page
- Work — `/work/` — parent page
  - [Detail title] — `/work/[detail-slug]/` — child page
- About — `/about/`
- Contact — `/contact/`

## Primary navigation

1. Home
2. Work
   - [Detail title]
3. About
4. Contact

## Page inventory

| Page | Visitor need | Opening summary | Incoming link | Main next route |
| --- | --- | --- | --- | --- |
| Home | | | Site root | Work |
| Work | | | Home and navigation | Detail page |
| Detail | | | Work and submenu | Work |
| About | | | Navigation | Contact |
| Contact | | | Navigation and About | Home |

Write one sentence in each empty table cell. Stop planning after the page purpose, path, opening summary, incoming link, and next route are clear. Detailed block layout can be decided in WordPress.

Create the project repository

From the cms-site-practice workspace root, run:

Create the CMS evidence repository

git init -b main
git add .gitignore cms-site-notes.md
git diff --staged
git commit -m "Create CMS project plan"

Create an empty private GitHub repository named cms-site-practice. Do not add a README, .gitignore, or license on GitHub. Copy its HTTPS URL, then connect and push the project:

Connect and push the CMS evidence repository

git remote add origin https://github.com/YOUR-USERNAME/cms-site-practice.git
git push -u origin main

Run git remote -v and reload GitHub. Confirm that the remote name is correct, the first commit is visible, and no ZIP file appears in the repository.

Check

The plan identifies one site purpose, one visitor, five distinct page roles, one parent-child relationship, four top-level navigation items, one submenu item, and at least one incoming route for every page.

Assistance for Checkpoint 1

1Assistance 1 — Choose a brief and preserve the required structure

Select the brief with the clearest content for you. Copy the required sitemap before you rename any label. Keep Home, About, Contact, one parent page, and one child detail page as distinct roles.

2Assistance 2 — Check whether each page has a separate purpose

Complete this sentence for each page: “A visitor opens this page to…” If two pages have the same answer, narrow the detail page to one case, item, or activity and keep the parent page as the overview.

Checkpoint: The site has a bounded information architecture

What now works

cms-site-notes.md records the bounded information architecture, and the first evidence commit is on the private cms-site-practice repository.

Files changed

cms-site-practice/.gitignore, cms-site-practice/cms-site-notes.md

What remains

Create the WordPress site identity, pages, hierarchy, prepared media, and first restorable checkpoint.

Next action

Open WordPress Playground, enter WordPress Admin, and set the planned site title and tagline.

If it does not work

If the plan keeps expanding, return to the five required roles and move every extra page or feature to a Later list.

Record the CMS evidence checkpoints with Git

Use Git for the text evidence that changes during the assignment. Keep the ZIP backups in the same project folder, where .gitignore excludes them from commits.

Working state	Required commit message
Site plan and repository are ready	Create CMS project plan
Structure export and its evidence are recorded	Record CMS structure checkpoint
Navigation and search audit evidence is complete	Document CMS navigation and search evidence
Final tests and restore result are recorded	Record final CMS verification

After Checkpoints 2, 4, and 5, update cms-site-notes.md, then run:

Record and push CMS evidence

git status
git diff
git add cms-site-notes.md
git diff --staged
git commit -m "CHECKPOINT MESSAGE"
git push

Replace the placeholder with the matching message from the table. Run git status --ignored when you want to confirm that the ZIP files exist locally and Git ignores them.

Checkpoint 2: Build the content structure and media state

Open WordPress Playground in a new browser tab. Wait for the site to load, then open WordPress Admin.

1. Set the planned site title and tagline in the general settings.
2. Create Home, Work, About, and Contact as separate pages.
3. Create the detail page and set Work as its parent.
4. Set short descriptive slugs. Confirm the detail path is nested below the Work path.
5. Add one unique opening summary and at least one additional descriptive section heading to every page.
6. Upload the prepared WebP image to the Media Library. Record its alternative text from its role on Home.
7. Place the image in relevant Home content and add a caption when the source or context needs one.
8. Publish all five pages.
9. Set Home as the static front page.
10. Open every page in the visitor view and compare it with the inventory.

Do not judge the primary navigation yet. Theme-provided page links can be incomplete before Checkpoint 3.

Export the structure checkpoint

Use Export in the WordPress Playground Dock and select the complete ZIP download. Rename the downloaded file cms-structure-checkpoint.zip and move it into cms-site-practice.

Confirm that the ZIP is greater than 0 bytes. Keep it unchanged when you create later exports.

In cms-site-notes.md, record the export file name, date, size, and the site state that it restores. Use this evidence for the Record CMS structure checkpoint commit.

Check

The visitor site root shows Home. All five published pages have distinct content. The detail page uses the planned parent path. The prepared image appears with suitable alternative text. The structure ZIP exists outside the browser.

Assistance for Checkpoint 2

2Assistance 2 — Diagnose a page path or hierarchy mismatch

Compare the saved slug and parent setting with the plan. If WordPress adds -2, inspect published pages and Trash for another item with the same slug. If the detail path is top-level, save Work as its parent and then inspect the visitor URL again.

3Assistance 3 — Build one complete page state at a time

Use this order for each page: title, slug, parent when required, opening summary, section heading, body content, publish, visitor check. Complete Home and its image before you move to Work, detail, About, and Contact.

Checkpoint: The complete content state is restorable

What now works

The site identity, static Home page, five published pages, parent-child path, prepared media, summaries, and headings work in the visitor view, and the structure ZIP exists.

Files changed

cms-site-practice/cms-site-notes.md, cms-site-practice/cms-structure-checkpoint.zip

What remains

Connect the pages with descriptive content links, primary navigation, and a keyboard-usable submenu.

Next action

Edit Home and add a descriptive link to the Work overview.

If it does not work

If the visitor view differs from the editor, confirm publication status and front-page settings before you change theme presentation.

This is a safe stopping point. Keep the structure ZIP and record the first missing link if you stop here.

Checkpoint 3: Build the link network and primary navigation

Add these content routes:

1. Home links to Work with a label that describes the destination.
2. Work links to the child detail page with a specific item or project name.
3. The detail page links back to Work with a clear return label.
4. About links to Contact when the content gives a reason to continue there.

Follow the complete route in the visitor view before you edit the site header.

Then open the Site Editor and configure the Navigation block used by the header:

• top level: Home, Work, About, Contact;
• submenu below Work: the child detail page;
• responsive mobile behavior enabled; and
• click-to-open submenu behavior enabled when the active block provides that choice.

Save the navigation and any changed Header template part. Review the save list before you confirm it.

Check

Use only the keyboard in the visitor view. Open the main navigation, open the Work submenu without hover, follow every item, and use browser Back and Forward. Every page remains reachable and focus stays visible.

Assistance for Checkpoint 3

1Assistance 1 — Identify the active menu and required order

Work in the Navigation block that the visitor header actually displays. Use List View to confirm the four top-level items and the one indented child before you change colors, spacing, or other template blocks.

2Assistance 2 — Repair an orphan page or hover-only submenu

A published page needs at least one usable incoming route. Confirm that the child page has a content link from Work and a submenu item. If the submenu works only with a pointer, enable click-to-open behavior when available and test Enter and Space again.

3Assistance 3 — Verify links before navigation presentation

Test the content route Home → Work → detail → Work first. Then test the four top-level navigation items. Finally test the submenu with the keyboard and at a narrow width. This order separates link errors from header-layout errors.

Checkpoint: Every published page has a usable route

What now works

Descriptive content links form a complete route, primary navigation has four ordered top-level items, and the child page works inside a keyboard-usable Work submenu.

Files changed

cms-site-practice/cms-site-notes.md

What remains

Audit page-specific search information and verify the rendered source evidence.

Next action

Open Home in the visitor view and compare its title, opening summary, headings, path, links, and image text with the page inventory.

If it does not work

If the wrong menu appears, inspect the visitor header and confirm which Navigation block it uses before you create or rename another menu.

Checkpoint 4: Audit basic search information

For each page, verify and record:

• the visitor need;
• visible page title;
• path;
• opening summary;
• section headings;
• incoming descriptive link;
• image-text decision when an image appears; and
• rendered HTML title.

Add these columns to the page inventory:

cms-site-notes.md — evidence columns

| Page | Rendered HTML title | Verified evidence | Limit |
| --- | --- | --- | --- |
| Home | | Visitor view and rendered source inspected | Playground is not a public indexing test |
| Work | | | |
| Detail | | | |
| About | | | |
| Contact | | | |

Use browser developer tools or rendered page source to inspect the HTML title for each route. Record what the browser renders, not what you expect WordPress to generate.

Search the visible site content for:

• repeated keyword lists;
• identical opening summaries;
• vague link labels such as click here;
• hidden search text;
• claims that the site is indexed or ranked; and
• a page title or heading that does not match its content.

Repair one confirmed issue at a time. Retest the affected route and a related navigation route after each repair.

Check

All five page records contain page-specific evidence. Titles, summaries, headings, paths, links, and image text describe the same page purpose. The notes do not claim crawling, indexing, traffic, or ranking.

Assistance for Checkpoint 4

2Assistance 2 — Separate a verified signal from a search outcome

“The rendered title identifies the Work page and site” is a page-level finding you can inspect. “Google will rank this page” is not verified by a private Playground site. Record the first as evidence and the second as outside the assignment scope.

3Assistance 3 — Audit one route through a stable sequence

For one page, read the visible title, opening summary, headings, path, incoming link, image text, and rendered HTML title. Repair and retest that page before you move to the next page.

Checkpoint: The page signals are specific and evidence-based

What now works

Every route has an accurate title, summary, heading structure, path, incoming link, image-text decision, rendered title record, and honest search-evidence boundary.

Files changed

cms-site-practice/cms-site-notes.md

What remains

Run the complete visitor test, export the final site, and prove that the export restores.

Next action

Return to the site root in the visitor view and begin the final route test with the keyboard.

If it does not work

If a page feels generic, compare its opening summary with the other four summaries and name the visitor need that only this page answers.

Checkpoint 5: Test, export, and restore the delivery

Run the final test in the visitor view:

1. Start at the site root and confirm that Home is the static front page.
2. Follow Home → Work → detail → Work through content links.
3. Follow each top-level navigation item.
4. Open and follow the submenu without pointer hover.
5. Use browser Back and Forward through the same route.
6. Repeat the navigation route at about 320 CSS pixels.
7. Test each required route at 200% browser zoom.
8. Confirm that titles, text, media, controls, and focus remain visible without unintended horizontal page scroll.
9. Record the browser, operating system, conditions, actual results, repairs, and retests in cms-site-notes.md.

Export the complete site as a Playground ZIP. Rename it cms-site-final.zip, store it beside the structure checkpoint, and confirm that it is greater than 0 bytes.

Prove the export restores

Keep the active final site and ZIP unchanged. Open a new Playground instance and use New → Import zip in the Dock. Select cms-site-final.zip.

After import, repeat these high-value checks:

• site title and static Home;
• all five pages and the parent-child path;
• prepared image and alternative text;
• primary navigation and submenu;
• one complete content-link route; and
• one narrow keyboard route.

Record the restoration date and actual result in cms-site-notes.md.

Assistance for Checkpoint 5

2Assistance 2 — Diagnose a final ZIP that does not restore

Confirm that you used the Playground Dock complete-site export, not WordPress Tools → Export. Check that the ZIP is greater than 0 bytes and was not edited after download. Preserve both Playground tabs while you ask for help or repeat the export.

3Assistance 3 — Use a focused restoration proof

Restore the ZIP, then check site identity, front page, page count, hierarchy, media, navigation, and one complete route in that order. Stop at the first mismatch and compare that state with the active final site before changing either copy.

Checkpoint: The final CMS delivery restores and works

What now works

The final visitor routes pass in the named conditions, cms-site-final.zip restores the required CMS state in a new Playground, and cms-site-notes.md records the evidence and limits.

Files changed

cms-site-practice/cms-site-notes.md, cms-site-practice/cms-structure-checkpoint.zip, cms-site-practice/cms-site-final.zip

What remains

Complete the self-check and show the restored delivery to your teacher.

Next action

Run the self-check against the restored site and correct the first unmet requirement in the active working copy before exporting again.

If it does not work

Keep the last restorable ZIP unchanged, identify the first state that differs after import, and repair that state in the working site before creating a newly named final export.

Self-check

Complete these checks against the required result.

1. Open cms-site-notes.md and confirm that the selected brief, visitor, site purpose, sitemap, navigation order, page inventory, evidence, test results, and search limits are complete.
2. Open the restored visitor site at its root. Confirm the planned site identity and static Home content.
3. Visit all five published pages. Confirm unique titles, opening summaries, descriptive headings, planned paths, and one useful incoming link for each page.
4. Inspect the Work detail page. Confirm that it is a child of Work, uses the nested path, appears in the submenu, and has a descriptive return link.
5. Inspect the Home image. Confirm that the prepared WebP loads from the Media Library and that its alternative text matches the image role.
6. Use only the keyboard to open the main menu and submenu and follow every item. Confirm visible focus and no hover-only required action.
7. Use browser Back and Forward, about 320 CSS pixels, and 200% zoom. Confirm that required content and controls remain available without clipping or unintended horizontal page scroll.
8. Compare visible titles, summaries, paths, links, image text, and rendered HTML titles with the notes. Confirm that every recorded claim is supported by the inspected page.
9. Confirm that cms-structure-checkpoint.zip and cms-site-final.zip are separate, greater than 0 bytes, stored outside the browser, and that the final ZIP completed the documented restore test.
10. Run git log --oneline and confirm that it contains the four required evidence commits.
11. Run git status and confirm that the working tree is clean. Run git status --ignored and confirm that both ZIP files are ignored but still exist locally.
12. Open the private GitHub repository and confirm that it contains the latest notes commit and no ZIP backup or credential.

Assignment-wide assistance

The checkpoint sections contain support for the current state. Use the deeper structures below when the complete information architecture or evidence record is the active barrier.

4Assistance 4 — Review a partial five-page content frame

Use these page intentions, then write your own content:

• Home: Identify the site, visitor, and main value. Link to Work.
• Work: Summarize the available work and link to one detail page.
• Detail: Explain the goal, process, and result of one item. Link back to Work.
• About: Explain the person or organization behind the site. Link to Contact when relevant.
• Contact: State a safe contact route and what the visitor can expect next. Link to Home.

Each page still needs its own opening summary, section heading, stable slug, and evidence record.

5Assistance 5 — Review one complete reference architectureExample solution

This reference uses the web student portfolio brief. Adapt the facts and wording instead of copying a claim that your site does not support.

Page	Path	Purpose	Opening summary	Incoming route
Home	/	Introduce the portfolio and route visitors to current work	“This portfolio presents selected Level 1 web-development work and the decisions behind it.”	Site root and Home navigation item
Projects	/projects/	List and compare selected projects	“Review coded and CMS projects with a short statement of purpose and result.”	Home link and navigation
Responsive Profile Page	/projects/responsive-profile-page/	Explain one project’s goal, implementation, tests, and limits	“This case study explains how a semantic profile page was adapted for narrow and wide layouts.”	Projects link and submenu
About	/about/	Explain the current role, focus, and working approach	“Learn which web-development skills this portfolio practices and which areas remain in progress.”	Navigation
Contact	/contact/	Provide a safe next route	“Use the listed practice address to request more information about the work shown here.”	About link and navigation

Primary navigation: Home, Projects with the Responsive Profile Page submenu, About, Contact.

Verified evidence can include published visitor routes, the saved parent relationship, rendered titles, keyboard operation, narrow and zoom tests, and successful ZIP restoration. Do not list indexing or ranking as verified evidence.

Optional extensions

The required assignment is complete when it meets every requirement and passes the self-check. The routes below do not affect completion. Choose any route that provides a useful challenge.

1. Add a second child page. Create a distinct second detail page under Work, link it from the parent, add it to the submenu, and repeat keyboard, narrow, rendered-title, and restore tests.
2. Run a second theme test. Export the passing site, switch to another block theme in the working copy, and compare navigation, heading presentation, image behavior, and required template changes. Keep the original final ZIP unchanged.
3. Add a teacher-approved description field. In a non-production copy, use a teacher-approved SEO feature to add unique meta descriptions. Inspect the rendered elements and record the difference without claiming that search systems will display them unchanged.
4. Prepare a public-deployment checklist. Document the additional evidence needed for HTTPS hosting, stable canonical URLs, crawl controls, XML sitemap, server responses, performance, privacy, and search-console verification. Do not publish the Playground site as part of this route.

Submission

Submission destination: Show the restored site and project files to your teacher.

Show the site restored from cms-site-final.zip, not only the original working tab. Also show cms-site-notes.md, cms-structure-checkpoint.zip, the local one-line Git log, and the private GitHub repository. Keep both ZIP files in cms-site-practice; the repository and screenshots do not replace a restorable ZIP.

Safe stopping point

At the end of a session, add this block to cms-site-notes.md:

Resume note

## Resume here

- Last restorable checkpoint:
- What works in the visitor view:
- First incomplete page or route:
- Next action in WordPress:
- Required administration or visitor state:
- Next test and expected result:

Download a complete checkpoint before leaving any state that would be expensive to rebuild. When you resume, restore or open that checkpoint and confirm the recorded working route before you continue.