15.1 Overview

After creating a website in Website Builder, AIUNIFY PROS SUITE provides a project-management and publishing workflow for working with the website beyond its initial generation.

This chapter covers the subscriber-facing functions for:

  1. Viewing saved Website Projects
  2. Identifying projects by preview, Name, and Last Updated date
  3. Reopening a project with Edit
  4. Saving website changes
  5. Previewing desktop and mobile versions
  6. Opening a temporary full-page Preview
  7. Viewing and copying generated source code
  8. Downloading the website as index.html
  9. Publishing a website
  10. Selecting a public subdomain
  11. Opening the published website
  12. Understanding the published-site indicator
  13. Removing a website from public access
  14. Deleting a saved Website Project
  15. Distinguishing Save, View, Download, Publish, Delete from public, and Delete Project

This chapter remains system-user/subscriber only. Administrator Domain Management functions are intentionally excluded.

15.2 Website Project Lifecycle

A Website Builder project can move through several user-controlled stages:

Create

Generate

Edit

Preview

Save

Optional:

Download

Optional:

Publish

Public Website

Optional:

Continue Editing

or:

Delete from public

Optional:

Delete Project

These operations are separate and should not be confused with one another.

15.3 Opening Website Builder

Navigate to:

Sidebar → Core Tools → Website Builder

The main Website Builder page includes:

Your Projects

and:

+ New Project.

15.4 Your Projects

The Your Projects area is the primary subscriber-facing location for previously saved Website Builder projects.

The page retrieves the Website Projects available through the current Website Builder project service and renders them as project cards.

15.5 Project Cards

Each Website Project card currently contains:

  1. Website Preview thumbnail
  2. Project Name
  3. Last updated
  4. Edit
  5. Delete Project control


This gives you both a visual and text-based way to identify saved projects.

15.6 Project Preview Thumbnail

At the top of each card, Website Builder renders a miniature version of the saved website.

This preview is intended for identification rather than interactive use.

Links and forms inside the thumbnail are not intended to function as the live site.

15.7 Project Name

Below the preview, the saved Project Name appears in bold.

As established in Chapter 14, the current Website Builder automatically uses:

the initial Website Builder Prompt

or:

New Website

as the Project Name when saving.

15.8 Current Naming Limitation

The supplied user-facing source does not establish a:

  1. Rename Project
  2. Edit Project Name
  3. Project Properties

control.

Therefore, project naming remains automatic in the current version.

15.9 Last Updated

Each project card displays:

Last updated: [date].

This helps you distinguish older and more recently modified projects.

15.10 No Projects Yet

If no saved Website Projects are available, Website Builder displays:

“No projects yet. Create your first AI website!”

Use the creation workflow from Chapter 14 to begin.

15.11 + New Project

Select:

+ New Project

to open a new Website Builder Playground.

Remember that the main Website Builder creation Prompt described in Chapter 14 is generally the clearest path for creating a completely new AI-generated site with a descriptive project Name.

15.12 Reopening a Saved Project

To continue working on an existing site:

  1. Open Website Builder.
  2. Scroll to Your Projects.
  3. Find the desired project.
  4. Review its Preview and Last Updated date.
  5. Select:
  6. Edit

The project reopens inside the Website Playground.

15.13 What Edit Restores

When an existing Project ID is opened, Website Builder retrieves the saved project.

The current loader restores:

  1. Website code
  2. Saved Design Chat messages
  3. Published subdomain, when present


This means a saved Website Project is more than a screenshot—it can restore the working design and prior design conversation.

15.14 Continuing an Existing Project

After selecting Edit, you can continue using the same tools described in Chapter 14:

  1. Design Chat
  2. Visual edits
  3. Image Settings
  4. Desktop Preview
  5. Mobile Preview
  6. View
  7. Code
  8. Download
  9. Save
  10. Publish, when not already published

15.15 Save

The Website Playground toolbar contains:

Save.

Use Save to persist the current website project.

15.16 When Save Is Available

The Save control is disabled when:

  1. No generated website code exists
  2. An AI operation is currently loading
  3. A Save operation is already in progress


15.17 Saving State

While the project is being saved, the button displays:

Saving.

Avoid leaving the page until the save operation completes.

15.18 Successful Save

A successful operation displays:

Website Saved Successfully!

Use that confirmation before assuming new work has been persisted.

15.19 What Save Persists

The current Save workflow submits:

  1. Current website HTML
  2. Current Design Chat messages
  3. Existing Project ID when updating
  4. Project Name


15.20 First Save Creates the Project Identity

If the current website has not yet received a Project ID, a successful first Save can create one and update the working URL with that Project ID.

This allows subsequent saves to update the same Website Project rather than creating a separate project each time.

15.21 Save Does Not Mean Publish

This distinction is essential:

Save stores your Website Project. Publish makes the website publicly accessible through its publishing URL.

A website can be:

Saved but not Published.

15.22 Publish Does Not Mean Delete Project

Likewise:

Delete from public

and:

Delete Project

perform fundamentally different operations.

This chapter explains both separately.

15.23 Save Frequently

Recommended Save points include:

  1. After initial generation
  2. After a major Design Chat change
  3. After extensive Visual edits
  4. After replacing images
  5. Before attempting a major redesign
  6. Before leaving Website Builder
  7. Before publishing

15.24 Preview Area

The Website Playground displays the generated website inside its visual Preview workspace.

The toolbar below the Preview provides controls for:

  1. Desktop/mobile display
  2. Publish/public status
  3. Save
  4. View
  5. Code
  6. Download


15.25 Desktop Preview

Select the Monitor icon to use the:

Web/Desktop

Preview.

The design uses the available Preview width in this mode.

15.26 Mobile Preview

Select the mobile-device icon to switch to:

Mobile

Preview.

The mobile Preview is rendered at approximately 375 pixels wide in the current Website Design component.

15.27 Why Both Preview Modes Matter

A website that looks correct on desktop may still have:

  1. Overlapping elements
  2. Poor text wrapping
  3. Oversized headlines
  4. Off-screen buttons
  5. Excessive spacing
  6. Navigation problems
  7. Improper card stacking

on a mobile screen.

Always review both views before publishing.

15.28 Recommended Responsive Review

Before publishing, inspect:

Navigation

Can users understand and access it?

Hero

Does the headline wrap properly?

Buttons

Are calls-to-action visible and usable?

Images

Do they scale appropriately?

Cards

Do they stack cleanly?

Forms

Are fields readable?

Footer

Does it remain organized?

15.29 View

The Website toolbar includes:

View.

This opens the current generated website in a separate browser tab for a larger Preview.

15.30 How View Works

Website Builder constructs the current website into a complete HTML document and opens it through a temporary browser object URL.

For users, the important distinction is:

View is a temporary Preview—not a public deployment.

15.31 View Does Not Require Publishing

You can use View before the site is public.

This allows you to inspect the website in a cleaner browser environment before deciding whether to publish it.

15.32 View Does Not Create a Public URL

The browser tab opened by View should not be treated as the address you send to customers.

Use:

Publish

to create the Website Builder's public publishing address.

15.33 Code

The Website toolbar includes:

Code.

Selecting it opens a source-code viewer for the current generated website.

15.34 Code Viewer

The source viewer identifies the website file as:

index.html

and provides syntax-highlighted HTML with line numbers.

15.35 Copying Source Code

The Code viewer includes:

Copy

and confirms successful copying with:

Source code copied!

15.36 Code View Is Not an Editor

The current source viewer provides:

  1. Viewing
  2. Syntax highlighting
  3. Line numbers
  4. Copying

It does not establish direct manual source-code editing inside that dialog.

Use Design Chat or Visual edits for normal Website Builder modifications.

15.37 Download

The Website toolbar includes:

Download.

This creates an HTML copy of the current generated website.

15.38 Downloaded Filename

The current downloaded file is:

index.html.

15.39 Download Confirmation

After the file is generated, Website Builder displays:

Download successful!

15.40 Download Does Not Publish

Downloading the HTML gives you a local copy of the website.

It does not:

  1. Make the site public
  2. Assign a subdomain
  3. Change publication status
  4. Remove the saved Project

15.41 Compact Toolbar

When the available Preview space is narrow—or Visual edits is consuming additional workspace—the following controls can move into the three-dot menu:

  1. View
  2. Code
  3. Download


If those controls seem to disappear, check the menu.

15.42 Save and Publish Remain Primary Toolbar Actions

Even when the toolbar becomes compact, the current design keeps the major project/public controls separate from View/Code/Download:

  1. Publish or Delete from public
  2. Save


15.43 Publishing a Website

Once the website is ready for public access:

  1. Save the current design.
  2. Review desktop Preview.
  3. Review mobile Preview.
  4. Use View for a larger final inspection.
  5. Return to Website Builder.
  6. Select:
  7. Publish

The Publish button appears when the current project does not have a published subdomain.

15.44 When Publish Is Disabled

Publish is disabled when:

  1. No generated website exists
  2. An AI operation is loading
  3. Publishing is already in progress


15.45 Publish Website Dialog

Selecting Publish opens:

Publish Website

with:

“Enter a subdomain to host your website.”

15.46 Subdomain Field

The current field uses the placeholder:

my-awesome-site.

Enter the public identifier you want Website Builder to use.

15.47 What Is a Subdomain?

A subdomain is the website-specific portion of the public address provided by the Website Builder hosting configuration.

Conceptually:

your-site + platform-domain

can produce:

your-site.platform-domain

Depending on the deployment environment, the system can alternatively publish through a /sites/your-site style path.

15.48 Actual Public Address Depends on Deployment Configuration

The current source supports two URL patterns:

Configured Base Domain

https://[subdomain].[base-domain]

Alternate Host Configuration

[current-host]/sites/[subdomain]


Therefore, this manual does not hard-code one universal public domain.

Use the public URL displayed by your live PROS SUITE environment.

15.49 Allowed Subdomain Characters

Inside the current Publish Website dialog, Website Builder automatically:

  1. Converts input to lowercase
  2. Removes characters other than:
  3. a–z
  4. 0–9
  5. hyphen -


15.50 Good Subdomain Examples

Examples that fit the current input rules include:

company-site

enterprise-demo

summer-campaign

sales-platform

my-business

15.51 Avoid Unnecessary Complexity

A good public subdomain should generally be:

  1. Short
  2. Recognizable
  3. Easy to spell
  4. Easy to communicate
  5. Related to the project

Avoid extremely long descriptions when a concise identifier will work.

15.52 Empty Subdomain

If you attempt to publish without entering a value, Website Builder displays:

Please enter a subdomain.

The Publish button is also disabled while the field is empty.

15.53 Publishing

After entering the subdomain, select:

Publish.

During the operation, the button can display:

Publishing....

15.54 What Publish Saves

The current publishing operation submits:

  1. Current website HTML
  2. Selected subdomain
  3. Current Design Chat messages
  4. Existing Project ID, if one exists
  5. Project Name


This means Publish is not merely attaching a URL to an unsaved visual snapshot—it also persists the website information involved in the publication operation.

15.55 Publishing a Previously Unsaved Website

If the website does not yet have a Project ID, a successful Publish operation can create the project and add its new Project ID to the Website Builder URL.

Therefore:

A separate Save is recommended before publishing, but the current Publish workflow itself can also create/persist a new project as part of publishing.

15.56 Successful Publish

A successful operation displays:

Website Published to Subdomain!

Website Builder then records the project's current subdomain in the working interface.

15.57 Published Website Opens Automatically

After a successful Publish and valid Project ID, Website Builder constructs the public URL and opens it in a new browser tab.

This lets you immediately inspect the public version.

15.58 Verify the Published Site

After publication, review the public site carefully.

Check:

  1. Navigation
  2. Layout
  3. Mobile responsiveness
  4. Images
  5. Calls-to-action
  6. Buttons
  7. Forms where applicable
  8. Text accuracy
  9. Links
  10. Brand presentation

Do not assume that a successful publication message means every part of the content itself is correct.

15.59 Published URL Indicator

When Website Builder knows that the Project has a subdomain, the toolbar displays a green public-site indicator with a Globe icon and the public URL.

15.60 Opening the Public Site from the Toolbar

The displayed public URL is clickable and opens the published website in another tab.

Use this whenever you need to inspect the live/public version while editing.

15.61 Published State Changes the Toolbar

When no subdomain exists, the toolbar shows:

Publish

When a subdomain exists, the Publish button is replaced by:

Delete from public.

This is how the current Website Builder indicates whether the project is considered published through its subdomain workflow.

15.62 Save and Public Status Are Independent Concepts

A published site can still be edited in Website Builder.

You may:

  1. Open the Project.
  2. Make changes.
  3. Save them.
  4. Review the published URL.

However, because the sanitized source bundle does not include the backend public-site delivery implementation, this manual does not make an unsupported guarantee about exactly when every saved change becomes visible publicly.

After editing a published project:

Save the project and verify the public URL yourself.

15.63 Reopening a Published Project

When a saved project is reopened, the loader restores the saved subdomain into Website Builder.

If the subdomain is restored successfully, the toolbar can again display the public URL and Delete from public.

15.64 Delete from Public

To remove the current Website Builder publication, select:

Delete from public.

This is the current user-facing unpublish control.

15.65 “Delete from Public” Does Not Delete the Website Project

This distinction is extremely important.

Delete from public

clears the project's public subdomain association.

It does not invoke the Website Project deletion function.

The current unpublish operation sends the existing Project ID with:

clearSubdomain: true.

15.66 Published Removal State

While removing the project from public access, the toolbar temporarily displays:

Deleting.

This wording refers to deleting the public publication association—not deleting the Website Project itself.

15.67 Successful Unpublish

When the public removal succeeds, Website Builder displays:

Website unpublished!

The working projectSubdomain is then cleared.

15.68 Toolbar After Unpublishing

Once the public subdomain is cleared:

  1. The public URL indicator disappears.
  2. Delete from public is replaced with Publish.

This allows you to publish again later if needed.

15.69 Unpublishing Keeps the Saved Project

After Website unpublished!, the project itself can remain available under:

Your Projects

because the unpublish workflow clears only the subdomain rather than invoking project deletion.

15.70 When to Use Delete from Public

Use Delete from public when:

  1. The site should no longer be publicly accessible through its current Website Builder subdomain.
  2. You need to temporarily take the website offline.
  3. You want to keep editing the saved project privately.
  4. You intend to publish again later under another subdomain.

15.71 When Not to Use Delete from Public

Do not use it merely because you want to:

  1. Save an edit
  2. Preview a site
  3. Download the HTML
  4. Close the editor

Those actions do not require removing the public publication.

15.72 Publish vs. Delete from Public

Think of publication status as:

Saved Project + No Subdomain

Publish

Saved Project + Public Subdomain

Delete from public

Saved Project + No Subdomain

The Website Project remains separate from that cycle.

15.73 Deleting a Website Project

Project deletion is performed from:

Website Builder → Your Projects

not through Delete from public.

Each saved project card contains a Trash/Delete control.

15.74 Delete Project Confirmation

Selecting the Delete control opens:

Delete Project

with:

“Are you sure you want to delete this project? This action cannot be undone.”

and:

Delete.

15.75 Project Deletion Is Destructive

The confirmation explicitly states:

“This action cannot be undone.”

Do not confirm deletion unless you intend to permanently remove the saved Website Project.

15.76 Preserve Important Work Before Deleting

Before deleting a project, consider:

  1. Open the Project.
  2. Review it.
  3. Use Download to preserve index.html if needed.
  4. Copy any source code you need.
  5. Confirm whether the project is still publicly published.
  6. Then decide whether permanent deletion is appropriate.

15.77 Successful Project Deletion

After successful deletion, Website Builder displays:

Project deleted

and refreshes the Project list.

15.78 Delete Project Errors

If deletion fails, Website Builder can display:

Failed to delete project

or:

Error deleting project.

If that happens, do not assume the project was removed.

15.79 Delete Project vs. Delete from Public

The distinction can be summarized as:

Delete from public

Removes publication/subdomain

Project remains saved.

Delete Project

Removes the saved Website Project

Confirmation warns that the action cannot be undone.

This distinction should be understood before using either control.

15.80 Preview vs. Publish

Another important distinction:

Preview

Used by the owner while editing.

Includes:

  1. Embedded editor Preview
  2. Desktop/mobile Preview
  3. View

Publish

Creates a public Website Builder address.

Use Preview for review.

Use Publish only when the website is ready for public access.

15.81 Download vs. Publish

Download

Creates:

index.html

on your device.

Publish

Places the Website Project at its configured public Website Builder URL.

Downloading does not automatically deploy that downloaded file anywhere.

15.82 Code vs. Download

Code

Lets you inspect and Copy the generated source.

Download

Creates the current website as:

index.html

Both use the generated website source but serve different purposes.

15.83 Save vs. Download

Save

Persists the project inside Website Builder.

Download

Creates an external HTML copy.

For important projects, you may choose to do both.

15.84 Save vs. Publish

Save

Persists the editable Project.

Publish

Persists the publishing state and assigns the public subdomain.

A good production workflow usually uses:

Save → Review → Publish

15.85 Editing a Published Website

A published Website Project remains editable.

Recommended workflow:

Open Project

Edit

Desktop Preview

Mobile Preview

Save

Open Public URL

Verify Changes

Because public delivery is handled outside the included user-interface source, verification is important.

15.86 Major Changes to a Published Site

Before substantially redesigning a published site:

  1. Download the current index.html if an external backup is useful.
  2. Save the current Project.
  3. Make the new changes.
  4. Review both Preview sizes.
  5. Save again.
  6. Open the public URL.
  7. Confirm the public site remains correct.

15.87 Public URL Should Be Tested Outside the Editor

After publishing, use the public URL shown in the toolbar.

Do not rely solely on the embedded Website Preview.

This helps verify the website in the environment visitors will actually access.

15.88 Test Important Links

Before sharing the public URL, review:

  1. Navigation links
  2. Call-to-action buttons
  3. External links
  4. Anchor links
  5. Forms or interactive elements where applicable

AI-generated designs should be tested before business use.

15.89 Test on More Than One Screen Size

Website Builder provides desktop and mobile Preview controls, but it can also be useful to inspect the public website using actual devices or browser responsive tools.

The built-in controls provide the initial verification step.

15.90 Subdomain Naming Best Practice

Choose a public subdomain that communicates the project clearly.

For example:

Company Website

company

Product Demo

product-demo

Campaign

summer-campaign

Customer Portal Mockup

client-portal

Avoid meaningless identifiers if customers will see the URL.

15.91 Subdomain Availability

The current client source validates the format of the entered subdomain, but the sanitized bundle does not establish client-side availability checking before Publish.

If a requested value cannot be accepted, the publishing service can return an error.

Do not assume a syntactically valid subdomain is necessarily available.

15.92 Publishing Errors

If publication fails, Website Builder can display the returned error or:

Failed to publish website

with the applicable status.

The catch path can also display:

Error publishing website: [message].

15.93 Troubleshooting — Publish Button Is Disabled

Check whether:

  1. Website code has been generated.
  2. An AI operation is still running.
  3. Another Publish/Unpublish operation is in progress.

The current Publish control is disabled under those conditions.

15.94 Troubleshooting — Publish Dialog Will Not Continue

Confirm that a subdomain value has been entered.

If empty, Website Builder displays:

Please enter a subdomain.

15.95 Troubleshooting — Capital Letters Disappear

This is expected.

The Publish dialog automatically converts the value to lowercase.

15.96 Troubleshooting — Spaces or Special Characters Disappear

The current publishing field strips characters outside:

  1. Lowercase letters
  2. Numbers
  3. Hyphens


Use a hyphen instead of spaces.

15.97 Troubleshooting — Public URL Does Not Appear

A public URL indicator is only rendered when Website Builder has a projectSubdomain for the current Project.

Confirm that:

  1. Publish succeeded.
  2. You received Website Published to Subdomain!
  3. The Project was saved/created successfully.

15.98 Troubleshooting — Publish Succeeded but Public Site Looks Wrong

Compare:

  1. Editor Preview
  2. View Preview
  3. Public URL

Then:

  1. Return to Website Builder.
  2. Correct the design.
  3. Save.
  4. Reopen the public URL.
  5. Verify again.

15.99 Troubleshooting — Delete from Public Looks Like It Will Delete Everything

The wording can be confusing.

The source verifies that Delete from public invokes the unpublish workflow, which clears the subdomain association.

The permanent project deletion function is separate and appears under Your Projects with a confirmation dialog.

15.100 Troubleshooting — Website Is Still in Your Projects After Delete from Public

That is expected.

Delete from public is not Project deletion.

The site should remain a saved Website Project unless you separately select Delete Project.

15.101 Troubleshooting — Accidentally Deleted the Project

The current confirmation explicitly states that deletion:

cannot be undone.

The supplied subscriber source does not establish:

  1. Trash
  2. Restore Project
  3. Undo Delete
  4. Recycle Bin

This is why downloading important versions before destructive deletion can be valuable.

15.102 Troubleshooting — Cannot Find View, Code, or Download

Check the toolbar's:

three-dot menu

The controls are moved there when the toolbar enters compact mode.

15.103 Troubleshooting — Cannot Find Publish

If a website is already published, the toolbar replaces:

Publish

with:

Delete from public.

Look for the displayed public URL.

15.104 Troubleshooting — Cannot Find the Published URL After Reopening

A saved project's loader restores its subdomain when that value exists.

If it does not appear:

  1. Confirm the correct Project was opened.
  2. Confirm it is still published.
  3. Verify that the previous publication operation succeeded.

15.105 Troubleshooting — Save Fails

The current Save process can display:

Failed to save website

or:

Error saving website: [message].

Do not close the page until you know whether your latest changes were successfully persisted.

15.106 Troubleshooting — Last Updated Does Not Match Your Expectations

The Project list formats the project's returned updatedAt date using the browser's local date formatting.

Use it as a project-recency indicator rather than as a detailed activity log.

15.107 Website Builder Does Not Provide Version History

The current subscriber-facing source does not establish a project version-history interface.

There is no verified:

  1. Restore Previous Version
  2. Version Timeline
  3. Revision Comparison
  4. Rollback

function.

Save carefully and Download important milestones when needed.

15.108 Website Builder Does Not Provide Duplicate Project

The current project-card source establishes:

  1. Edit
  2. Delete

but not:

Duplicate.

If you need to preserve a version before experimentation, use Save and Download as appropriate.

15.109 Website Builder Does Not Provide Project Folders

There is no source-verified user control for organizing Website Projects into:

  1. Folders
  2. Categories
  3. Tags
  4. Workspaces

The current Your Projects view presents project cards directly.

15.110 Current Custom-Domain Status

The source bundle does contain a separate component titled:

Domain Management

with tabs for:

  1. Subdomain
  2. Custom Domain

and code for adding and verifying custom domains.

However, this component must not be treated as an active subscriber capability merely because its source file exists.

15.111 No Verified Subscriber Path Opens Domain Management

A complete source search found the DomainManager component definition but no separate import/render invocation connecting it to the ordinary Website Builder user interface.

Therefore, the current User Operations Manual does not instruct subscribers to look for or open a Custom Domain panel that is not source-verified as reachable.

15.112 Why Custom-Domain DNS Instructions Are Not Included as User Steps

The unused component contains interface code for:

  1. Add Custom Domain
  2. Pending
  3. Active
  4. Verify
  5. Configure your DNS records
  6. CNAME
  7. A Record


But source presence alone does not prove that an ordinary subscriber can access these controls.

Accordingly:

These are not documented as current subscriber operations.

This follows the same source-verification standard used throughout this User Operations Manual.

15.113 Administrator Domain Management Is Excluded

The bundle also contains a separate:

src/views/admin/AdminDomains.tsx

whose interface says:

“Manage all domains and websites created in the playground.”

That is explicitly an Admin view and is not part of this subscriber manual.

15.114 Current Verified User Publishing Capability

The Website Builder subscriber workflow that is directly rendered and source-verified is:

Publish

Publish Website

Enter a subdomain to host your website

Publish

Website Published to Subdomain!

Public URL

This is the publishing workflow users should rely on in the current version.

15.115 If Custom Domains Become Exposed Later

If a future subscriber release visibly adds a Custom Domain interface, the User Operations Manual should be updated from the actual released UI.

At that point, documented user steps can cover whatever the released interface verifies, such as:

  1. Domain entry
  2. DNS values
  3. Verification
  4. Status
  5. Removal

Until then, those controls remain outside the verified user workflow.

15.116 Best Practice — Keep Saved and Published Concepts Separate

A simple way to think about the Website Builder is:

PROJECT

Your editable saved website.

PREVIEW

What you inspect before release.

PUBLICATION

Whether Website Builder exposes the project through its public URL.

They are related but not identical.

15.117 Best Practice — Always Save Before Leaving

After Website Builder changes:

Edit

Preview

Save

Wait for:

Website Saved Successfully!

Then leave the workspace.

15.118 Best Practice — Review Before Publishing

Recommended sequence:

Save

Desktop Preview

Mobile Preview

View

Correct Any Problems

Save Again

Publish

Verify Public URL

15.119 Best Practice — Preserve an Important Release

Before major changes to a production/published site:

  1. Open the Project.
  2. Save the current state.
  3. Download index.html.
  4. Make your changes.
  5. Preview.
  6. Save again.
  7. Verify the public site.

This gives you an external copy of an important milestone even though Website Builder does not currently provide a version-history interface.

15.120 Best Practice — Do Not Delete a Project to Take It Offline

If your goal is only to remove the website from public access:

Use:

Delete from public

Do not use:

Delete Project

unless you also intend to permanently remove the saved project.

15.121 Best Practice — Use a Meaningful Subdomain

A customer-facing URL should be intentional.

Before publishing, ask:

  1. Is it easy to remember?
  2. Does it reflect the business or campaign?
  3. Is it spelled correctly?
  4. Will it still make sense several months from now?

The subdomain becomes part of the public address.

15.122 Best Practice — Verify the Public URL After Every Important Change

The user-interface source verifies saving and publication controls, but the backend public-rendering implementation is outside the sanitized source bundle.

Therefore, after modifying a published site:

Save → Open Public URL → Verify

is the safest operating practice.

15.123 Project Management Checklist

Before leaving a Website Project:

  1. I selected the correct Project.
  2. I reviewed the current Preview.
  3. I checked desktop mode.
  4. I checked mobile mode.
  5. I used View if I needed a larger Preview.
  6. I reviewed Code if necessary.
  7. I Downloaded index.html if I need an external copy.
  8. I selected Save after important changes.
  9. I received Website Saved Successfully!
  10. I understand Save does not automatically mean Publish.

15.124 Publishing Checklist

Before publishing:

  1. The website content is complete.
  2. The brand presentation is correct.
  3. Desktop Preview looks correct.
  4. Mobile Preview looks correct.
  5. Important links have been reviewed.
  6. Images display correctly.
  7. Calls-to-action are correct.
  8. I have successfully saved the latest version.
  9. I selected an appropriate public subdomain.
  10. The subdomain uses valid lowercase letters, numbers, and/or hyphens.
  11. I selected Publish.
  12. I received Website Published to Subdomain!
  13. I opened the public URL.
  14. I verified the live/public website.

15.125 Unpublishing Checklist

Before selecting Delete from public:

  1. I understand this is an unpublish action.
  2. I understand it is not Project deletion.
  3. I want to remove the current public Website Builder URL.
  4. I want to keep the saved Website Project.
  5. I am prepared for the public URL indicator to disappear.

Afterward:

  1. I received Website unpublished!
  2. The toolbar returned to Publish.

15.126 Project Deletion Checklist

Before selecting Delete in the Delete Project confirmation:

  1. I opened the correct Project.
  2. I do not need to keep editing it.
  3. I downloaded index.html if I need a copy.
  4. I preserved any source/content I may need.
  5. I understand the confirmation states that deletion cannot be undone.
  6. I understand this is different from Delete from public.
  7. I truly intend to permanently remove the saved project.

15.127 Website Project Control Reference

The current subscriber controls can be understood as:

EDIT

Reopen the saved Website Project.

SAVE

Persist the current editable project.

DESKTOP / MOBILE

Change Preview size.

VIEW

Open a temporary full-page Preview.

CODE

Inspect/copy generated HTML.

DOWNLOAD

Create index.html.

PUBLISH

Assign a public Website Builder subdomain.

PUBLIC URL

Open the published site.

DELETE FROM PUBLIC

Remove the project's public subdomain/publication.

DELETE PROJECT

Permanently remove the saved Website Project.

15.128 Website Project State Model

A website can conceptually exist in these states:

State 1 — Working, Not Saved

Generated/edited in the current session.

State 2 — Saved, Not Published

Stored under Your Projects but without a public URL.

State 3 — Saved and Published

Stored as a Project and associated with a public subdomain.

State 4 — Unpublished

Saved Project remains, but the public subdomain has been cleared.

State 5 — Deleted

Saved Project has been removed through Delete Project.

Understanding these states makes Website Builder much easier to operate.

15.129 What the Current Subscriber Website Manager Supports

The source verifies the following user-facing project-management capabilities:

Projects

  1. Your Projects
  2. Project preview thumbnails
  3. Project Name
  4. Last Updated
  5. Edit
  6. Delete Project
  7. Destructive confirmation

Preview

  1. Desktop Preview
  2. Mobile Preview
  3. View in new tab

Source

  1. Code viewer
  2. Copy source
  3. Download index.html

Persistence

  1. Save
  2. Saved Design Chat messages
  3. Saved HTML
  4. Reopening existing Projects

Publishing

  1. Publish
  2. Subdomain input
  3. Lowercase/character normalization
  4. Public URL
  5. Published-state indicator
  6. Delete from public / Unpublish

15.130 What the Current Subscriber Website Manager Does Not Establish

The source does not establish an ordinary-user function for:

  1. Project rename
  2. Project duplication
  3. Project folders
  4. Project tags
  5. Version history
  6. Restore deleted project
  7. Project sharing/collaboration
  8. User-access permissions per website
  9. Direct code editing in the Code viewer
  10. ZIP export
  11. WordPress export
  12. Git repository export
  13. Source-verified subscriber Custom Domain UI
  14. Source-verified subscriber DNS management

The presence of unused components or administrator views is not treated as proof of subscriber functionality.

15.131 Website Publishing at a Glance

The verified current workflow is:

YOUR PROJECTS

EDIT

DESKTOP / MOBILE PREVIEW

SAVE

Optional:

VIEW

CODE

DOWNLOAD

PUBLISH

PUBLISH WEBSITE

Enter:

my-awesome-site

PUBLISH

Website Published to Subdomain!

PUBLIC URL

If you later want it offline:

DELETE FROM PUBLIC

Website unpublished!

Project remains under:

YOUR PROJECTS

If you instead want to permanently remove the project:

YOUR PROJECTS → DELETE PROJECT → DELETE

15.132 Chapter Summary

AIUNIFY PROS SUITE Website Builder provides a persistent Your Projects workspace for managing websites that have been saved.

Each Project card displays a visual Preview, Project Name, Last updated, Edit, and a Delete control.

Selecting Edit opens the Project in the Website Playground, where its saved design, Design Chat messages, and existing subdomain can be restored.

The Website toolbar provides:

  1. Desktop Preview
  2. Mobile Preview
  3. Save
  4. View
  5. Code
  6. Download

and the current Download action creates:

index.html.

A successful Save displays:

Website Saved Successfully!

When a website is ready for public access, select:

Publish

The dialog displays:

Publish Website

and:

“Enter a subdomain to host your website.”

The current subdomain field automatically converts the entry to lowercase and permits letters, numbers, and hyphens.

A successful publication displays:

Website Published to Subdomain!

and can automatically open the published website in another tab.

Once published, Website Builder displays the public URL and replaces Publish with:

Delete from public.

Selecting Delete from public clears the subdomain and displays:

Website unpublished!

It does not delete the Website Project.

Permanent deletion is handled separately under Your Projects through:

Delete Project

with the warning:

“Are you sure you want to delete this project? This action cannot be undone.”

Finally, although the codebase contains a component with Custom Domain/DNS controls, no subscriber-facing source invocation of that component was found. The separate active Domain Management view identified elsewhere in the source belongs under, so it is excluded from this system-user manual.

The verified subscriber workflow is therefore:

Create → Edit → Preview → Save → Publish to Subdomain → Verify Public Site → Continue Editing or Unpublish → Delete Project Only When Permanently Finished

Write Your Comment