Make Sure App Checks Point to the Website You Own
Before a service checks or manages your website, it should confirm that you control the address. This keeps actions focused on your real app and away from the wrong target.
before you start
Prove that you control the website address before allowing checks, settings, or ongoing monitoring.
Understand which website must be checked
in plain words
The website entered into a checking service must be the same one your customers actually visit.
An app can have several website addresses without you realizing it. Your AI builder may provide a temporary preview, your team may have a test copy, and an older version may still be online. Meanwhile, customers may use the address printed in emails or payment receipts. If a checking service watches the preview instead of the customer website, its results can look reassuring while missing changes on the app people actually use. Start by asking which exact address a new customer would open today. Visit it in a private browsing window and confirm that it shows the expected name, sign-in page, products, and contact details.
The main part of a website address, such as example.com, has a technical name: the domain. Confirm every part of the address, including whether it begins with www and whether extra words appear before the main name. Then compare it with the address shown inside your AI builder and the company account that keeps the app online. The technical name for that company is a hosting provider. Looking familiar is not enough because an old copy can have the same colors and logo. You need to connect the check to the exact public destination used by customers.
- ▸Open the customer address in a private browsing window.
- ▸Compare it with the addresses in your builder and website accounts.
- ▸Label every other address as current, test, old, or unknown.
common risk
You connect a checking service to the temporary address created by your AI builder, but customers use a different address. A harmful public change on the customer website is not included in the check.
what to do now
Record the complete customer-facing address and identify every test or old address connected to the app.
ask your AI
Inspect this project and list every website address connected to it. Label each address as customer website, temporary preview, test, old, or unknown. Identify the exact address customers should use today, explain where each address is configured in plain language, and do not change anything.
Prove that you control the address
in plain words
A service should require a small change that only the person managing the website address can make.
Knowing a website name does not prove that you own or manage it. Before a service allows checks, settings, or continuing observation, it should ask for evidence that you control the address. The technical name for this process is domain ownership verification. Think of it as placing a temporary note in a locked shop window: anyone can see the shop, but only someone with the right key can place the note. This step helps stop a stranger, former contractor, or mistaken teammate from registering somebody else's website and using the service's controls against the wrong target.
The service may give you a short piece of text to place in the account that directs visitors to your website. Developers call that account area domain settings, and they call the short text a verification record. Another approved method may place a harmless file on the public website or confirm control through the company that manages the address. Use only a method displayed by the service you chose. Copy the provided information exactly, wait for confirmation, and follow its instructions about removal. If you cannot make the requested change, find the person who manages the address instead of trying unrelated changes.
- ▸Use the company account that manages the website address.
- ▸Choose an offered proof method you understand and can reverse.
- ▸Confirm who else can change the address before continuing.
common risk
A former contractor still controls the website account and connects your address to a service you did not choose. A proper ownership check reveals that your current team cannot complete the required change.
what to do now
Sign in to the account that manages the address, review who can use it, and complete one approved proof method.
ask your AI
Help me verify control of this app's customer website without changing customer features. Identify where the website address is managed, describe the ownership proof options supported by the chosen service, give me exact step-by-step instructions for the safest reversible option, and warn me before any action that could interrupt the website. Never ask me to publish a password, payment key, or code that opens customer information.
Keep the proof separate from important keys and passwords
in plain words
Proving control of a website should never require publishing anything that can open data, approve charges, or manage the app.
A safe ownership check proves control with limited information created for that one purpose. It does not require your database password, administrator password, payment key, customer sign-in code, or a code that opens customer information. Do not paste those items into a public page, downloadable file, support conversation, or ownership form. A payment key could allow unwanted payment activity. A database password could expose customer names, addresses, orders, or messages. An administrator password could let another person change the app. If instructions ask you to publish any of these objects, stop and confirm that you are following the official method for the service.
Important keys and passwords should stay in protected settings that perform work away from files sent to visitors. Developers call this the server side. The ownership proof should instead use a separate, limited piece of text that cannot sign in, read customer information, or approve a payment. VibeCodeWall checks the public app from the outside and watches for important changes over time. It does not need to see private code or receive passwords and payment keys. This boundary matters: proving that you control an address is different from giving a service the ability to control your app or spend money.
- ▸Use a limited proof created specifically for ownership confirmation.
- ▸Keep passwords and payment keys in protected app settings.
- ▸Reject any method that asks you to publish customer information or a code that opens it.
common risk
While trying to prove ownership quickly, someone places a payment key in a public file. Visitors may be able to download it even after the ownership check finishes.
what to do now
Review the proposed proof and confirm that it cannot sign in, read customer information, change the app, or approve a charge.
ask your AI
Review this project's public pages, downloadable files, and configuration for any exposed database password, administrator password, payment key, customer sign-in code, or code that can open customer information. Explain each finding in plain language, identify what visitors could obtain, and propose a safe correction that keeps those items in protected server-side settings. Do not reveal the full contents of any discovered key or password, and do not make changes until I approve them.
Check again whenever ownership may have changed
in plain words
A successful proof describes who controls the address now, so important changes should trigger another review.
Ownership confirmation is not permanent. Your app may move to another company, receive a new address, or be rebuilt in a different AI tool. A teammate may leave while keeping permission to change the address. An old preview may continue showing a copy of your app. Repeat the ownership check after any of these events and decide what should happen to every old address. Keep an old address only when it has a clear purpose and a current owner. Otherwise, remove the app from it or make it send visitors to the current customer website using the instructions from the company that manages it.
After confirmation, enable only checks you understand and direct notices to an inbox that someone regularly reads. VibeCodeWall can observe the public app from the outside and continue watching for important changes, but that observation is useful only when it follows the real customer address. Keep a short record containing the current address, the account that manages it, the people allowed to make changes, the proof method, and the review date. When the address, provider, or team changes, update that record, repeat the proof, and confirm that ongoing monitoring follows the new public app rather than an abandoned copy.
- ▸Repeat the proof after changing the address or the company keeping the app online.
- ▸Review permissions when a teammate or contractor joins or leaves.
- ▸Confirm that ongoing monitoring follows the current customer website.
common risk
Your app moves to a new company, but the checking service continues watching the old copy. Notices remain quiet even though the new customer website has changed.
what to do now
Create a review reminder for every website move, address change, builder change, and team membership change.
ask your AI
Create an ownership and monitoring checklist for this app. Include the current customer website, old and test addresses, who manages each address, when ownership must be proved again, where notices should be sent, and how to confirm that outside monitoring follows the current public app after a website move, address change, builder change, or team change. Use plain language and include checkboxes.
Quick checklist
- 01Write down the exact website address your customers use.
- 02Open that address in a private browsing window and confirm it shows the current app.
- 03Sign in to the company account that manages the address.
- 04Check which teammates or former contractors can change the address.
- 05Use only a proof method offered by the checking service.
- 06Never publish a password, payment key, or code that opens customer information.
- 07Remove old test addresses from services you no longer use.
- 08Repeat the proof after changing the address, app provider, or team.
- 09Send ongoing monitoring notices to an inbox your team reads.
FAQ
Why can a service not simply accept the address I enter?
Anyone can type an address. Requiring a small change in the account that manages it helps show that the request comes from someone who actually controls that website.
Does proving ownership reveal my private code?
No. The proof can use a limited change connected to the public address. VibeCodeWall checks the public app from the outside and does not need private code.
What if another person manages my website address?
Ask that person or company to complete the service's approved proof, or give the appropriate permission to a trusted current team member. Do not share personal passwords.
Should I also prove ownership of a test address?
Do so if a service will check or watch that address. Give first priority to the exact website used by real customers, and clearly label every test address.
Can I use a payment key or database password as proof?
No. Ownership proof should use limited information made for that purpose. A payment key, database password, administrator password, or code that opens customer information must never be published as proof.