URL guidance (currently focused for the NHS website)

[bencullimore]

What

We need URL standards for the NHS website (NHS.UK)

This includes, how URLs are used, their formatting requirements and considerations around short URLs for promotional purposes (see nhs.uk/coronavirus)

References: Open University: http://www.open.ac.uk/about/digital-governance/digital-standards-and-guidelines/url-standard-public/url-best-practice GOV.UK: https://www.gov.uk/guidance/content-design/url-standards-for-gov-uk

Why

URLs are important, especially in a health information context where users need reassurance that the information is trustworthy.

URLs always need always need to be clear, unambiguous, easy to read, easy to type and easy to share.

There currently isn't a standard for URLs on NHS.UK in place

Anything else

The Information Architecture team on NHS.UK has been using GOV's URL standards as a baseline https://www.gov.uk/guidance/content-design/url-standards-for-gov-uk but feel aspects could be tailored in regards to users with health needs.

We should adopt the GOV.UK url policy. Relevant sections for the NHS Website are 1-11, 12-16 are relevant for other parts of the NHS. https://www.gov.uk/guidance/content-design/url-standards-for-gov-uk

Exceptions

1. The NHS acronym GOV.UK's policy 3. c)

URLs must use words and should not contain acronyms, wherever possible.

"nhs" should always be used in URLs instead of "national-health-service"

Good: https://www.nhs.uk/about-us/nhs-website-datasets/ Bad: https://www.nhs.uk/about-us/national-health-service-website-datasets/

Additions

1. Query string parameters Use of query string parameters should be avoided where possible

2. Canonical URLs Where the same content can be accessed through multiple URLs we recommend you define a canonical URL for the content, or equivalent content. (A canonical URL allows you to tell search engines that certain similar URLs are actually one and the same) https://support.google.com/webmasters/answer/139066?hl=en&ref_topic=4617741

3. Governance Both GOV.UK and Open University have a governance process for top level URL redirects to prevent conflicts and exhausting common words.

NHS does not - perhaps it should.

One thing worth pointing out is that good, user-friendly URLs are the result of good information architecture - they're the programmatic representation of meaningful structures and information relationships which have been properly researched with users.

[bencullimore]

A finding from the NHS website's Information Architecture team is that URLs should mirror the site structure and page headings.

@karlgoldstraw identified instances where contractions such as Finding out you're pregnant were being used as page headings and queried how these should be reflected in the URL:

• should we use the contraction "you're" with apostrophes finding-out-you're-pregnant

• without apostrophes finding-out-youre-pregnant which isn't grammatically correct

• or remove the contraction finding-out-you-are-pregnant - meaning it won't match the page heading exactly.

Karl checked with our SEO consultancy who suggested that apostrophes should not be used in URLs. The SEO consultant suggested that both options without the apostrophe would be fine from a search engine perspective.

Content designers on NHS.UK had a wider discussion around the use of contractions on the website in general. It was suggested that the advice in the service manual's style guide on contractions would need revisiting as NHS teams have observed people misreading them, as have teams building other government services.

It was also suggested that content designers on the NHS website avoid using contractions as page headings:

We don't tend to use contractions in H1 headings because this style of heading doesn't make for a great page title. It's more likely to be used in an H2 or H3. However, if we were to use a contraction in the H1, we definitely wouldn't add it to the url.

But this guidance has yet to be captured formally.

[chrimesdev]

+1 for this, this is something I've come across needing again and again during the coronavirus projects. It's common that production URLs are just being the made as whatever the prototype URLs were, but this isn't the right approach as a prototype is usually just a quick and easy name that someone has come up with. Having a standard would be very beneficial.

[bencullimore]

From an IA perspective, the structure of the website shouldn’t be masked through shortened, truncated addresses. URLs should be a canonical representation of where the page sits.

For example, hypothetically - if you have a fingernail removal service and structurally this service belongs to the finger section, the main and URL should be

www.nhs.uk/health-a-to-z/hand/finger/nail/nail-removal-service not www.nhs.uk/nail-removal-service

By masking the location of that specific page through the URL we will break a number of things

• The integrity of the sites information architecture
• Supporting navigational elements; such as breadcrumbs, main menu nav and sideways navigation.
• SEO - search engines won’t understand the pages place within the website, so less likely to show ‘related’ pages if a user was to search, for example, “nail removal”

By breaking these things we’re hindering our user's ability to navigate our website. In this hypothetical example, a user might want to find out about nail removal but not actually book an appointment to remove their nail (just yet). By breaking IA, navigational elements and SEO we’re stopping them from finding the thing they need.

User-friendly/Vanity URLs We understand that in some situations, even shorter URLs are needed. Some NHS information and services get promoted offline. Where this is the case, it’s helpful if the URL is especially memorable and easy to say or type. If a URL is going to be read aloud (on the radio or on an automated call centre message) it may make sense to request a redirect. In our nail example, we suggest having a vanity URL of:

www.nhs.uk/nail-removal-service which redirects to the proper url of www.nhs.uk/health-a-to-z/hand/finger/nail/nail-removal-service

[bencullimore]

With canonical URLs in mind, how best should we structure transactional service's URLs beyond the start page?

For our hypothetical start page we have www.nhs.uk/health-a-to-z/hand/finger/nail/nail-removal-service with redirects from our vanity url www.nhs.uk/nail-removal-service

Should subsequent service URLs follow the proper URL? For example

1.  www.nhs.uk/health-a-to-z/hand/finger/nail/nail-removal-service
2.  www.nhs.uk/health-a-to-z/hand/finger/nail/nail-removal-service/login
3.  www.nhs.uk/health-a-to-z/hand/finger/nail/nail-removal-service/appointment-times
4.  www.nhs.uk/health-a-to-z/hand/finger/nail/nail-removal-service/book-appointment

or do we revert to the vanity URL?

1. www.nhs.uk/health-a-to-z/hand/finger/nail/nail-removal-service
2. www.nhs.uk/nail-removal-service/login
3. www.nhs.uk/nail-removal-service/appointment-times
4. www.nhs.uk/nail-removal-service/book-appointment

This question was discussed internally with input from technical and design leads. Here's a few comments:

If the start page for a service is the NHS website and that page logically falls into place to have its related content, breadcrumbs, (basically stuff that prevents it being the end of the road) then I think [canonical URLs are] massively important.

For truly transactional services what happens after that I don’t believe needs to have any navigational relationship to the rest of NHS.UK.

Basically, if the service doesn’t have our header and breadcrumbs… once you’ve clicked start then it can do whatever URL wise. It won’t be indexed on search, it doesn’t have breadcrumbs so can’t get confused. And the application root will be consistent for easy development and eventually decommissioning.

Running the entire journey under the /conditions/blah/blah/book-my-vaccine path for example very much complicates things technically and ensuring the users requests get to the right backend/third-party application gets messy. Particularly as we will be routing to different services behind the scenes throughout the journey. We would be introducing risk and complexity.

[bencullimore]

The NHS websites SEO consultants have provided guidance supporting the Information Architectures team's principle of

The structure of the website shouldn’t be masked through shortened, truncated addresses. URLs should be a canonical representation of where the page sits.

Their advice is as follows:

In SEO, we usually recommend organising content into “hubs” – having a parent / child page structure and grouping content thematically. This is because:

• It gives topical relevance to other pages in the same “hub”, i.e. search engines will understand that “glaucoma”, “cataracts” and “diabetic retinopathy” are all eye conditions because they sit under the “/eye/” section.
• It helps search engines understand the “importance” of the page in the hierarchy, for example: the “eye” page is a broader landing page for all eye conditions in that section.

However, it’s worth saying that this would create more levels of landing pages in the site (e.g. a page each for hands, fingers, nails), that would also need to be designed.

In SEO we used to suggest content by grouping keywords, but now we group by topics, as this is more similar to how Google’s entity / knowledge graph works. Ultimately, we recommend organising content and creating landing pages based on search volumes. For example (not a true / tested example!): “more people search for body parts, like hands, than symptoms, like itchy skin, so that’s how we will group content”.

Other important SEO considerations

• Another important factor for search engines is internal linking (creating a structure by linking to parent, sibling and child pages, etc.).
• Breadcrumbs perform a similar purpose – helping search engines understand a page’s location in the architecture.
• A vanity URL isn’t an issue for SEO because the page redirects to the full, canonical URL.

[bencullimore]

I've detailed considerations around the use of contractions in URLs here: https://github.com/nhsuk/nhsuk-service-manual-backlog/issues/266#issuecomment-718028122

[bencullimore]

URL standards for the NHS website (nhs.uk) (draft)

How URLs are used on the NHS website (nhs.uk), their formatting requirements and why short URLs are sometimes created for promotional purposes.

1. The NHS website (nhs.uk) URLs are designed to be naturally user (and SEO) friendly, and to follow a consistent, predictable, format. These guidelines set out how URLs should be constructed, and our approach to setting up additional URLs for marketing purposes.

2. These standards apply to the NHS website (nhs.uk) and its sub-domains. Separate standards apply to the wider use of the nhs.uk domain, for example by Public Health England.

The NHS website (nhs.uk) URL style

3. The style for the NHS website (nhs.uk) URLs is that:

a) URLs always need to be clear, unambiguous, easy to read, easy to type and easy to share

b) all URLs must be in lower case

c) URLs must use words and should not contain acronyms, wherever possible (see 8 for an exception on the NHS acronym)

d) dashes should be used to separate words within URLs so they are easy to read - for example, https://www.gov.uk/set-up-business (need NHS example) (see 5, 7 for exceptions on campaign landing pages and service sub-domain URLs)

e) articles (a, an, the) and other superfluous words should not be used. For example, use /benefits or /benefits-guides rather than /a-guide-to-benefits (need NHS example)

f) URLs should use the verb stem, where possible. For example, /apply instead of /applying

g) each page must have a URL which is as short, memorable and unambiguous as possible, especially if a URL is going to be referred to offline

h) URLs should be based on user need rather than the (current) name of a policy, scheme or service, which might change. For example, the URL https://www.gov.uk/advertise-job is intended for people who want to advertise a job on the Department for Work and Pensions’ (DWP) Universal Jobmatch service (need NHS example)

Campaign sites and URL promotion

4. Trailing slashes should not be used when sharing or printing URLs, or for providing third parties with links to NHS website (nhs.uk) content. For example, use www.nhs.uk/nice-url-here rather than www.nhs.uk/nice-url-here/

5. Campaign landing pages exist on NHS website (nhs.uk) as a means of providing supporting digital content for campaign and promotional activity. These URLs need to be aligned with the title of the marketing campaign. They should be as short as possible and contain only lowercase a-z characters - for example, www.gov.uk/sortmytax, www.gov.uk/workplacepensions. (need NHS example)

‘Friendly’ URLs (furls) and redirects for existing content

6. For marketing or promotional activity where a campaign landing page does not exist, then a top level redirect may be requested (see 10).

7. In some situations, even shorter URLs are needed. Some government information and services get promoted offline. Where this is the case, it’s helpful if the URL is especially memorable and easy to say or type. If a URL is going to be read aloud (on the radio or on an automated call centre message) it may make sense to request a redirect. By default, short URLs do not use hyphens.

The NHS acronym

8. "NHS" should always be used in URLs instead of "national-health-service"

Good: https://www.nhs.uk/about-us/nhs-website-datasets/ Bad: https://www.nhs.uk/about-us/national-health-service-website-datasets/

Top-level redirects

10. These are redirects which exist at www.nhs.uk/url, such as those used for organisation pages. Due to the large amount of content that already exists at the top level of GOV.UK, only a limited number of redirects will be allowed here. Requests will be considered by ??????? on a case-by-case basis and will only be granted if the following conditions are satisfied:

a) the URL conforms to all other requirements of the NHS website (nhs.uk) URL policy

b) the content being promoted originates from, or is significantly relevant to, more than one department or organisation

c) the URL needs to be specific to the content and make sense forever. For example, include a year when using a re-direct for one-off promotion of an annual event

d) the URL will be used for significant offline marketing and promotion

Query string parameters

11. Use of query string parameters should be avoided where possible

Canonical URLs

12. Where the same content can be accessed through multiple URLs we recommend you define a canonical URL for the content, or equivalent content. (A canonical URL allows you to tell search engines that certain similar URLs are actually one and the same) https://support.google.com/webmasters/answer/139066?hl=en&ref_topic=4617741

Governance

13. Both GOV.UK and Open University have a governance process for top-level URL redirects to prevent conflicts and exhausting common words. NHS does not - perhaps it should.

Service URLs

14. If the start page for a service is on the NHS website then that page needs to fit canonically so related content, breadcrumbs etc. - stuff that prevents it being the end of the road for users is available - so must follow our canonical URL standard and not be unnecessarily truncated. What happens beyond the start page doesn't need to have any navigational relationship to the rest of the NHS website as the users has entered 'a service'.

Running the entire service journey under the canonical URL path for example www.nhs.uk/health-a-to-z/hand/finger/nail/nail-removal-service complicates things technically - ensuring the users requests get to the right backend/third-party application gets messy. Particularly when routing to different services behind the scenes throughout the journey. We would be introducing risk and complexity.

Transactional service pages should not have a presence in the site other than the start page as a user will need to follow a transactional flow, only reaching specific URLs when answering questions or 'logging in'. In service scenarios a user shouldn't jump forward in a journey.

In the example of a transactional service following a start page on a canonical URL, subsequent service URLs can be truncated. E.g.

1. www.nhs.uk/health-a-to-z/hand/finger/nail/nail-removal-service
2. www.nhs.uk/nail-removal-service/login
3. www.nhs.uk/nail-removal-service/appointment-times
4. www.nhs.uk/nail-removal-service/book-appointment

[bencullimore]

One issue we’ve come across is around vanity or “friendly” URLs – URL addresses set up to promote specific campaigns, for example, www.nhs.uk/friendsandfamily

These URLs are used on marketing materials; posters, leaflets etc. which have been dictated by Marketing teams.

I don’t believe these URLs are accessible – from the perspective of someone with access tech either having to read them out from a poster or use them to navigate to a webpage.

I recall a campaign a few years ago asking people to use upper and lower case characters in hashtags to support access needs… which we could employ, meaning the URL would become nhs.uk/FriendsAndFamily but, in the context of a URL; I’ve been advised that upper case characters are classed as ‘special’ and may cause technical issues.

[bencullimore]

Vanity URLs continued

After an extensive debate on cross-government slack with experts in accessibility and security, with no evidence-based decisions on what makes a good vanity URL yet.

With point number 3 of the URL policy in mind:

3. The style for the NHS website (nhs.uk) URLs is that: a) URLs always need to be clear, unambiguous, easy to read, easy to type and easy to share

We have potential options:

/urlwithnospaces are hard to read and you could argue are ambiguous (potential to spell out other, non-related words)

/CamelCaseUrl are easier to read, need to check with access technologies

/url-with-hyphens is clear, unambiguous need to check with access tech

/word (one word) could work, could be ambiguous

/l (letter) is unclear and ambiguous

/faf (acronym) is unclear and ambiguous

I discussed having multiple vanity URLs based on promotional channel (voice; tv/radio/web, print; newspaper/letter) creating versions with and without hyphens, with the intention that the version with hyphens will be used in printed materials (hypothesis = easier to read) and the version with no hyphen will be used when spoken with National Cyber Security Center.

They raised concerns about having multiple/similar variants of an address - for example if a user sees the URL in a letter and gets an SMS with a link - if the two don’t match they could potentially cause distrust (they had no evidence to this).

Issues with having the URL without hyphens when spoken - does the speaker have to preface the address which multiple joined-up words with “no spaces?”

I’ve been testing URLs without hyphens. Some try to pronounce them as a new word www.nhs.uk/malecondom sounds like "mallaécondom" whilst other screen readers read it out as two separate words which leads me to think that users might try to input space into the URL which would mean not getting to/finding the information.

[Tosin-Balogun]

This was ranked joint 5th from the in progress group at the content backlog prioritisation workshop held on 24-Nov-2020

[bencullimore]

Update on ‘Friendly’ URLs (furls) and redirects for existing content

We've reached out to several accessibility experts including Nomensa and haven't found any specific guidance around what makes an accessible, friendly URL - in the context of promotional

@mcheung-nhs the accessibility lead for the NHS website has run tests with the potential options detailed in my post above using JAWS, NVDA and Apple Voiceover, here's a link to his test page https://mcheung-nhs.github.io/accessibility/tests/urls.html

We've noted issues around the use of lowercase acronyms - for example nhs.uk/stiscreening is incomprehensible by all screenreaders (they try to read stiscreening as a word), only when the acronyms are upper case (nhs.uk/STIscreening) it can be understood.

There's inconsistency with hyphens on screenreaders - Apple Voiceover doesn't read them out, so nhs.uk/covid-vaccine is read out as "covid vaccine" which could lead to users inputting the wrong URL.

All lowercase URLs are problematic too, dependant on the words some screen readers will try and pronounce as a new word, as mentioned previously - www.nhs.uk/malecondom sounds like "mallaécondom"

The only option which appears to be consistent across all three screenreaders is the use of upper and lower case letters or camel case. The use of camel case is also supported by the RNIB who has published guidance on using CamelCase in hashtags

> Use CamelCase in hashtags

When you're using hashtags, always use CamelCase and capitalise the first letter of every word. This means that the words in the hashtag are read out correctly by screen readers. It also makes them easier to read for everybody else. For example, you would write #HowISee, rather than #howisee. https://www.rnib.org.uk/rnibconnect/technology/making-your-social-media-accessible

I've discussed the above findings with the Accessibility Working Group at NHS Digital and it was recommended that try and reach out to dyslexia charities to understand what problems camel case might cause.

[jackiemellorbrownlee]

Expanding the discussion to services / staff-facing services

From discussion on Design Slack

So I see the recommendation for us in NHS is Page name - Site name

The HMRC discussion goes for a more specific [page title] - [section name] - [service name] - GOV.UK [page title] should mirror h1 on that page. https://github.com/hmrc/design-patterns/issues/90

Given that the more complex services have additional depth, and also ours is staff-facing so doesn't hang off the website, we are proposing the homepage to our internal service (temporarily titled 'Create and manage identities') would be:

create-and-manage-identities

and the page title would be

Create and manage identities - NHS

And then an example of a subsequent page would be

enter-name Enter their name - Add a user - Create and manage identities - NHS

[jackiemellorbrownlee]

Next question Is it separated by a hyphen or an em?

[henocookie]

At the December Design System Working Group session, URL guidance was presented by @bencullimore. This was discussed and voted on by the DSWG members.

Key points of discussion:

• Needs qualitative evidence to proceed
• Be clear why vanity URLs and full URLs are different use cases (camel and non camel case), which is why they have distinct guidance
• Are there any hosting constraints that NHS services may face when following this guidance. @mcheung-nhs mentioned certain operating systems of servers may prevent certain URL formats to be created
• RNIB on Twitter shared some guidance on camel case being a good format for screen readers
• General rule for new guidance added to the service manual is that we don't apply things retrospectively so no need for teams to adjust URLs unless doing new work

Vote to publish:

5 - Ready to publish now 9 - Needs a little more work 0 - Needs a lot more work 0 - Not right now

Next steps

• [x] Service manual team to investigate what tech stacks a range of NHS services use to see if there are any technical constraints that would prevent services following the drafted URL guidance. @DomBaker is this something you'd be able to ask the developer community about?
• [ ] @henocookie to prototype the guidance within the service manual so a visualisation can be presented at the next DSWG session

[henocookie]

Asked people in the #dev channel on the NHS.UK Slack workspace for experiences of setting up URLs for NHS services to look at the proposed guidance for URL standards on this issue and share experiences where it wouldn't have been able to be followed, so we know if the guidance needs adjusting to better suit developers in the NHS

[henocookie]

@ethanmills on the UK Government Digital Slack added:

One thing to bear in mind is that sites that want to track link clicks with UTM params will be using query parameters on their start URL.

Possibly something extra to include in the URL standards.

[chrimesdev]

Maybe a separate topic but should there be guidance around domain names? An obvious one for most of us but it's very common in the GP website space; use practice-name.nhs.uk rather than practice-name.co.uk.

Also subdomains, such as https://covid-status.service.nhsx.nhs.uk/ using the nhsx.nhs.uk subdomain, shouldn't this just be .nhs.uk if it's a public facing service? Do users know what NHSX? If not, do you lose trust from users by having it on an nhsx.nhs.uk subdomain

[bencullimore]

GP practices - they're private businesses so unsure if they're able to have NHS domain URLs. Would need to work with Policy/contract teams to understand the implications of this.

In the COVID service example, I believe the URL was linked to commissioning/budgets. It was also created prior to the URL standards being published, some great points - especially around trust. I'll speak to the COVID pass team and see if they've had any user insight around URL trust.

[jiggott]

On the subject of Camel Case for friendly URLs, I am about to request a short URL for https://www.nhs.uk/conditions/coronavirus-covid-19/self-isolation-and-treatment/ but I feel that www.nhs.uk/SelfIsolation is probably more difficult to read than www.nhs.uk/self-isolation because of the upper case I and its proximity to the lower case l and f.

[henocookie]

On the subject of Camel Case for friendly URLs, I am about to request a short URL for https://www.nhs.uk/conditions/coronavirus-covid-19/self-isolation-and-treatment/ but I feel that www.nhs.uk/SelfIsolation is probably more difficult to read than www.nhs.uk/self-isolation because of the upper case I and its proximity to the lower case l and f.

Thanks for this @jiggott :) In this case, the following point in the drafted standards should cover using dashes and not Camel Case:

3. d) dashes should be used to separate words within URLs so they are easy to read - for example, https://www.gov.uk/set-up-business (need NHS example) (see 5, 7 for exceptions on campaign landing pages and service sub-domain URLs)

[sarawilcox]

A few comments on the draft guidance above. (I'm reading it with a Publishing Platform issue in mind.)

How would someone find out about the separate standards for the wider nhs.uk domain? Are there some wider standards?

The draft above says not to use "a, an" etc. On our start page pattern, we have a small section on urls. We should make sure it's aligned with these URL standards when published. At the moment, it includes an example which does contain the word "an": https://www.nhs.uk/nhs-services/hospitals/book-an-appointment. Some other services include "a" or "an":

• https://www.nhs.uk/nhs-services/prescriptions-and-pharmacies/order-a-repeat-prescription/
• https://www.nhs.uk/service-search/find-an-optician

We have other examples that don't include "a" or "an", e.g.

• https://www.nhs.uk/conditions/coronavirus-covid-19/coronavirus-vaccination/book-coronavirus-vaccination/
• https://www.nhs.uk/conditions/coronavirus-covid-19/get-digital-covid-pass/

How important is it that we avoid "a" and "an"?

In https://www.nhs.uk/nhs-services/online-services/find-nhs-number/ we left out "your".

In the "furls" section, point 7, would we want to mention: https://www.nhs.uk/referrals (used in the start page example)?

[sarawilcox]

A few other thoughts about the draft standards:

• The GOV.UK guidance says that URLs should align with the title of the page - probably worth adding. (Note: there is a bit of a contradiction here as matching the page title may make it less easy to type and share.) Wagtail automatically uses words from the title when it creates the slug.
• Do we want to specify not including "a, an or the" if Wagtail automatically puts them in the slug? (I think it does.)

[jiggott]

One possible benefit to using short URLs in comms to citizens is that they can reduce costs of sending SMS by helping to keep messages short. (Sending SMS is usually charged per 160 characters.)

[jiggott]

I wonder if sometimes we go too far on nhs.uk in using the H1 of a page for its URL slug. Once you get a few levels down this can result in really long URLs, eg: https://www.nhs.uk/conditions/coronavirus-covid-19/coronavirus-vaccination/coronavirus-vaccine-people-with-severely-weakened-immune-system/ https://www.nhs.uk/conditions/coronavirus-covid-19/coronavirus-vaccination/pregnancy-breastfeeding-fertility-and-coronavirus-covid-19-vaccination/

To my mind, both these URLs duplicate info about the content of the page and therefore make it harder to scan and get an idea of what you'll get if you click on them. They could both be shortened to something like this: https://www.nhs.uk/conditions/coronavirus-covid-19/vaccination/people-with-severely-weakened-immune-system/ https://www.nhs.uk/conditions/coronavirus-covid-19/vaccination/pregnancy-breastfeeding-fertility/

Thoughts?

[henocookie]

I wonder if sometimes we go too far on nhs.uk in using the H1 of a page for its URL slug. Once you get a few levels down this can result in really long URLs, eg: https://www.nhs.uk/conditions/coronavirus-covid-19/coronavirus-vaccination/coronavirus-vaccine-people-with-severely-weakened-immune-system/ https://www.nhs.uk/conditions/coronavirus-covid-19/coronavirus-vaccination/pregnancy-breastfeeding-fertility-and-coronavirus-covid-19-vaccination/

To my mind, both these URLs duplicate info about the content of the page and therefore make it harder to scan and get an idea of what you'll get if you click on them. They could both be shortened to something like this: https://www.nhs.uk/conditions/coronavirus-covid-19/vaccination/people-with-severely-weakened-immune-system/ https://www.nhs.uk/conditions/coronavirus-covid-19/vaccination/pregnancy-breastfeeding-fertility/

Thoughts?

I imagine this fits in with the longer-term work the Information Architecture team is doing to create a "polyhierarchical structure" (flattening the NHS website's structure) which would likely impact URLs created on the NHS website and align with your suggestions that remove unnecessary duplication @jiggott. @BrieWhyatt have I covered this correctly?

[BrieWhyatt]

Absolutely right @henocookie. Once we have everything sitting in the root folder, it will eliminate the start of the slug /conditions and allow URLs to more directly reflect the content - i.e. things that are currently in the /conditions folder that aren't conditions will no longer have that slug. This will make the URLs marginally smaller while also ensuring that information scent and relationships between content are more accurately represented.

GOV service manual advice also states to not include 'a', 'an' 'the' in the URLs as they are superfluous to understanding. I wonder whether, in this instance, we should look at other words, such as the 'with' in the example James has given above, and consider whether these are also redundant.

[sarawilcox]

Looks like NHS Digital has a role in domain wide network addressing/URLs: https://digital.nhs.uk/services/networking-addressing.

[sarawilcox]

A conversation on the NHS.UK Slack channel: https://nhsuk.slack.com/archives/C6S0QTW9X/p1644933368349049. In short, don't shorten URLs unless you've got evidence they're a problem. Also leave in a/an if not causing problems.

Have I captured that correctly @rhiannonsmith?

[henocookie]

Sent a message on the NHS service manual Slack workspace asking for people who have worked on the design, research or development of creating URLs for website pages or transactional services in the NHS, to help move this forward 😄

[sarawilcox]

We're looking at having 2 vanity URLs, directing people to the same place:

• /update-contact-details
• /updatecontactdetails With the hyphen to make it easier to read and without hyphens in case people type the words without hyphen - or if someone is reading them out (e.g. a call centre) and it's easier to direct them to type them as one word.

[sarawilcox]

Related issue: URL - the acronym #523