6 minute read · Practical marketing guidance
On this page 6 sections
Before changing one WordPress page URL, write down the exact old address, the approved replacement and how you will check the public result. A cleaner-looking address is only part of the job. Customers may still arrive through a saved email, a service menu or an older guide.
For a Las Vegas or Henderson business, a useful handoff lets the owner approve the change and the website administrator implement it without guessing. Keep the work limited to one page unless the review reveals a larger problem.
First, identify what actually needs to change
A page title is the name people read. The slug is part of its address. WordPress documents the individual slug control in its page and post settings sidebar. Copy the full published URL before editing; do not treat a proposed title as an approved address.
If the title or introduction is unclear, improving that wording may be enough. Ask what the URL change would accomplish for this business. “We prefer the new wording” is a decision to discuss, rather than evidence that a move will improve search results.
The site-wide WordPress permalink settings control URL structures and other bases. That is a different scope from editing one page slug. Have the administrator confirm the page’s current structure and any parent-page relationship. A request to rename one service page should not become an unreviewed change to global permalink rules.
Find the routes that currently use the address
Start with the public page. Record its purpose, the service limitations it explains and the next step offered to a visitor. Then look for the address in menus, footer links, buttons, related articles and reusable content blocks. Record each location precisely enough that another person can find it.
Also list business-controlled references outside the website: a profile link, an active ad destination, an email template or a downloadable document. Separate editable references from old printed materials and links on someone else’s site. The latter may remain in circulation after your own edits are complete.
This inventory preserves an existing route. If you also need to decide where a new contextual link belongs, use our internal-link planning guide. Avoid turning a small address change into a rewrite of every connected page.
Approve one mapping and one implementation plan
Copy this original worksheet into your handoff notes. Keep “proposed,” “approved,” “implemented” and “verified” as separate statuses. Each unanswered field needs a responsible person before the work begins.
| Plan item | Record and acceptance condition |
|---|---|
| Reason and scope | Why the address needs to change; which page is involved; whether title-only editing would solve the problem. |
| Exact mapping | Complete old URL and proposed new URL, including host and trailing slash. Owner approval and date; administrator confirms the destination is available. |
| Content continuity | What a visitor expects from the old page and where the replacement provides it. Hold if the destination is an unrelated answer. |
| Reference inventory | Each owned link or document, its editor and update status; externally controlled references recorded separately. |
| Redirect responsibility | Administrator, approved permanent redirect method and expected destination; any existing rule that could conflict. |
| Page signals | Administrator checks the replacement’s canonical address and sitemap entry, where applicable, against the approved URL. |
| Change window and recovery | Implementation time, available reviewer and technical recovery owner. Record what requires a pause and how unresolved work is handed over. |
| Live evidence and acceptance | Actual old-address response, final address, replacement response and visitor-route checks; timestamp, reviewer and remaining issues. |
For a genuinely permanent move, Google recommends a server-side redirect where possible; 301 and 308 indicate a permanent move. The administrator should select the implementation appropriate to the hosting environment. Saving a different slug does not supply the verification record.
Google’s URL-change guidance recommends an old-to-new mapping, direct redirects to the final destination, updated links and new-URL canonical annotations. It warns against irrelevant homepage redirects. Apply those principles to the one page being moved. If there is no suitable replacement, pause and discuss removal separately rather than assigning a convenient destination.
A hypothetical Henderson lampshade repair page
This entire example is invented. The shop, decisions, inventory and addresses illustrate a handoff; they are not client work. The example.com addresses below are illustrative placeholders.
Imagine a Henderson shop that repairs and recovers lampshades but does not repair electrical components. Its owner wants the service address to match the specific name used in current shop materials. After considering a title-only edit, the owner approves this single mapping:
- Hypothetical old URL:
https://example.com/services/shade-repair/ - Hypothetical new URL:
https://example.com/services/lampshade-repair/
The destination will retain the same service explanation, electrical-work exclusion and inquiry instructions. The administrator must confirm that the proposed address is available. The services parent page stays outside the approved change.
The fictional inventory finds the old address in the service menu, a fabric-care guide and a staff email template. The website administrator owns the first two edits; the shop manager owns the template. An older printed care card cannot be edited, so its address becomes a test case.
The hypothetical owner schedules the work for October 12, 2026, at 8:30 a.m. Pacific, with a reviewer available afterward. This is a chosen example window, not a recommended time for every business. Acceptance requires the approved redirect and the visitor checks below. No one records those checks as passed in advance.
Save the live result, including failed checks
After implementation, open the old address while signed out of WordPress. Have the administrator record its HTTP response and destination. For this hypothetical plan, the expected evidence is one 301 response to the approved new URL, followed by a 200 response from the replacement. A browser reaching a page does not, by itself, establish those response codes.
Read the destination as a customer. Does it still explain lampshade work and exclude electrical repairs? Can someone reach the stated inquiry route? Follow the edited menu and guide links on a phone as well as from the old care-card address.
Ask the administrator to check that the replacement’s canonical annotation uses the approved new address and that the sitemap reflects the change. Save the actual results alongside the live checks. These observations establish what the website currently does; they do not prove Google has indexed the replacement or guarantee its search performance.
Write failures concretely: “Old address reaches the homepage,” “Menu still opens the old address,” or “Replacement inquiry button opens an unavailable page.” Give each issue an owner and leave acceptance pending. After correction, repeat the affected test and record the new result instead of erasing the earlier finding.
Close the handoff with responsibilities intact
The final record should distinguish the administrator’s implementation from the owner’s acceptance. Keep the approved mapping, dated evidence and unresolved external references together. Agree who maintains the redirect and who reviews it before a later redesign or plugin change.
For preparation and recovery questions, our WordPress maintenance checklist covers the broader checks. Recovery decisions belong to the responsible technical owner; the URL worksheet should identify that person without becoming a restoration tutorial.
Rank.Vegas web design services can include redirect and internal-link review within agreed website work. Email sales@rank.vegas with your website, the current page URL, proposed replacement and reason for the change. Describe the references you want checked; do not send passwords or private customer records. Implementation, migration and ongoing support depend on the agreed scope.