Written by DROPS.ST.
Before adding a new shop to an existing website, walk the customer route from the site's entry link into the catalogue, then back to information or help. Check the addresses, navigation labels and behavior at each boundary. A working shop on its own does not establish that the connection to your current website is ready.
DROPS gives that connection a useful destination: a shop with product listings, details, cart and checkout, supported by customer-linked order records. You can assess how your existing website leads into that shopping experience while keeping the website work and shop work clearly defined.
Decide what remains on the existing site
List the pages you intend to keep: business information, contact details, service explanations or other established content. Decide where the catalogue and ordering experience should live.
A link to a separate shop, a proposed custom-domain arrangement and an embedded menu are different approaches. Do not treat them as interchangeable. If embedding or another connection is proposed, ask for its actual support and demonstration in the intended site environment.
Use a boundary walkthrough
Give each step an expected destination and record what happens in the agreed preview or demonstration. Start with the actual page and navigation design you intend to use.
| Customer step | Expected result | Evidence to record |
|---|---|---|
| Select the shop link on the existing site | Enter the intended shop | Link text, destination and observed page |
| Open a product | Stay in the expected shopping context | Address, item and visible navigation |
| View the cart | Understand where the current selection belongs | Cart location and selected item |
| Seek help or business information | Reach the approved information page | Label, destination and return route |
| Return to shopping | Re-enter the expected shop view | Observed route and cart behavior, where applicable |
| Repeat on a phone | Find and use the same essential routes | Mobile menu and observed destinations |
This checks the connection and navigation. The checkout acceptance guide addresses the separate question of what a supported submission produces.
Make the entry link describe its destination
Use a label that tells someone what they will find. A catalogue link should not look like a general contact link, and a help route should not unexpectedly open another ordering system.
Check whether desktop and mobile menus point to the same intended shop. An updated desktop link does not prove that a separately configured mobile menu changed too.
Check clear labels, recognizable menu presentation and keyboard operation at the entry and return routes. These are principles in the W3C menus tutorial, not an accessibility certification.
Keep the existing site understandable when the customer returns. A recognizable business name and clear shopping route help explain how the two parts belong together.
Check the address and behavior at each boundary
Follow the route yourself in the agreed test environment. Record the destination rather than relying on what a button label suggests.
Use fictional items for interactive tests and stop before any action that could create real business activity. Where safe testing is unavailable, mark the relevant behavior untested rather than presenting a visual preview as complete acceptance.
Keep website and shop ownership clear
Name the person responsible for the existing site's links and the person responsible for shop navigation. Record who will correct a mismatch and how the changed route will be checked again.
Domain registration, renewal and DNS control are separate responsibilities. Use the domain handover guide for those decisions. This walkthrough asks whether the customer route connects the pages you intended.
Hypothetical example: two menus point to different shops
A fictional retailer keeps its information website and prepares a new shop. The desktop navigation points to the new catalogue, but the mobile menu still opens the older ordering page.
The reviewer records both destinations and assigns the mobile-link correction to the existing-site owner. They then repeat the entry route, product view and return-to-help journey on the phone.
The problem is the website connection, not the quality of the new product records. Repeating a successful desktop demonstration would not establish that the mobile route was corrected.
This is an invented compatibility case, not an observed DROPS deployment or a claim of automatic website synchronization.
Accept the connection against the intended journey
Agree which routes must work before launch. Hold acceptance for an entry link to the wrong shop, an unexplained ordering boundary or missing essential help navigation.
Assign remaining issues to an owner. Keep untested connection assumptions visible.
Give your existing website a clear shop destination
DROPS is a strong fit when the business needs a coherent catalogue and ordering experience to put behind its website's shop link. Connected Telegram shopping can use the same catalogue and order system, giving the operator one shop to run across those enabled channels.
Explore DROPS and open the demo shops. Bring the existing site's proposed entry and help routes to the discussion. Walk the boundaries, identify the people who control each side and choose a connection your customers can follow without guessing where they are ordering.