Inventory the pages people already use.
Combine the current crawl and sitemap with Search Console, analytics landing pages, important inbound links, and the team’s knowledge of customer journeys. Include service pages, articles, campaign destinations, files, and individual event or product pages.
Record each URL’s purpose, status, title, canonical, and intended treatment. Traffic is one input; a low-volume page may still answer an important customer question or support an established link.
Map each change to a relevant destination.
Keep established URLs where the underlying page still serves the same purpose. For a useful page that moves, map the old address directly to the matching new page with a permanent redirect. Update internal links to the final address.
Avoid sending every retired page to the homepage. If there is no relevant replacement, decide whether the content should be restored, rewritten at its original URL, or deliberately retired. Document that choice rather than leaving an accidental dead end.
Keep the content and search signals aligned.
Preserve useful service explanations, project evidence, and customer information as the design changes. Check that every important page has a descriptive title, a meaningful main heading, a correct canonical, and internal links.
Review structured data against visible facts. A venue’s individual event page should describe that event, with the correct date, timezone, and purchase path. A calendar redesign should not replace all event detail URLs with one generic listing.
Four places to look first.
Four areas of a website review: whether the message is understandable, the experience works on a phone, search engines can understand the pages, and customers can call or send a message.
01
Message
Is your offer easy to understand?
02
Experience
Can people use the site on a phone?
03
Visibility
Can search engines understand your pages?
04
Inquiries
Is it easy to call or send a message?
Separate staging protection from public indexing.
Keep development copies out of search. Before launch, check the intended public pages for accidental noindex directives, robots restrictions, authentication barriers, and incorrect development-domain canonicals. Check HTTP headers as well as the HTML.
Generate a sitemap from the intended public routes. Include canonical pages that return successfully, and remove obsolete redirects and unintended internal pages. A processed sitemap helps discovery; it does not guarantee indexing or rankings.
Rehearse the customer journeys and the URL map.
Test the old and new addresses on the candidate build. Check redirect destinations and chains, page status, canonicals, navigation, mobile layout, forms, and any ticket or checkout handoff. Test inquiries with a stub or an approved provider test environment.
Keep a recovery plan that preserves newer customer records. Replacing a live database with an older development copy can undo inquiries and content added during the redesign. Use a targeted release and retain the relevant prechange files.
Check the public result after launch.
Verify the site through normal public DNS and trusted HTTPS. Recheck priority routes, the sitemap, representative individual pages, and the customer journeys. Watch Search Console indexing and search performance alongside analytics and real inquiries.
Compare complete periods, record the launch date, and expect small samples and reporting delays. Search inclusion and traffic changes require observation; a successful deployment or valid sitemap is not proof that Google has indexed every page.
Keep individual shows discoverable.
The Nissi’s refresh connects show browsing, dining, and private-event journeys while retaining individual event addresses and event sitemap entries. Those checks protect technical continuity; they do not establish a traffic or ticket-sales increase.
See the Nissi’s website refresh