Hola! ¡Tenemos nuestra Comunidad en Español!

Best Practices for Links in Content Staging during a Website Redesign Process

SOLVE
Highlighted
Regular Contributor

Hi Everyone, 

 

New to the community, but as a new agency partner I'm excited about what HubSpot can bring to the table. 

 

I'm currently working on a website redesign in the COS with a client who has an existing site. The ultimate plan is to replace much of the existing site since it's seriously out of date.

 

My question centers around relative versus absolute links. Absolute links are preferred in some cases because of the advantages gained in SEO, but what happens to any absolute links in the flow of rich text boxes, etc. when the pages that contain them go live? 

 

It appears that links in Simple Menus and Advanced Menus automatically update the domain from a sandbox version to the live domain upon publish, but do links designated as absolute links in the flow of text follow suit? I'm seeing some that don't. Is there a way to add links so they automatically update from the sandbox domain to the live domain upon publishing the pages? 

 

Once I understand how this works, I can implement a best-practices approach going forward for any site we build or redesign in the HubSpot COS. 

 

Thanks everyone! 

Reply
0 Upvotes
1 Accepted solution

Accepted Solutions
Regular Contributor

When inserting a link into a rich text module the default option is to make the link relative. There may be a way to change this default setting but I haven't dug into the settings to see if that's possible. Absolute links are preferred of course in order to avoid SEO issues, duplicate indexing, spider traps, etc. 

 

Unchecking the "Make links relative" checkbox automatically adds in the full URL and makes them absolute. If this is done in the staging environment it adds the sandbox domain, but if you do this after going live it will adopt the live domain—which is what we ultimately want our absolute URLs to be. 

 

I may use relative links during development so that all the links "technically" work when we go live. I can uncheck the relative checkboxes post launch. It's either that or change all the absolute link domains from staging to live manually. Either way, I have to touch them all. 

 

Using relative links may make for less work overall. Absolute links in staging also create redirects in the COS URL Mappings that point to the absolute links on the live domain. While that avoids dead ends, that's not the best approach.

 

Using relative links in staging and then changing them to absolute post-launch should avoid those redirects and save a couple of steps of work. 

4 Replies
Esteemed Advisor

@CWBourque

 

the reason that the simple menu and advanced menu links update is because when you are setting up a link to link to a specific site page using the drop down, you are actually sett that link  to link to [ PageID ]'s url. The page id is static and specific to that page. The menu module works to find the urls of all of the page id's on the server side before delivering the page to the client side. Because the page selectors are hooked to the page id, the urls of the page id can change and the server would just grab the new one when processing. 

 

This being the case, if you are just pasting the url of the other pages into the page then that would be static and will not change. The rich text editor has a link creator that uses the pages drop down, but I am not sure if it just prints the url into the editor statically or if the url is processed each time the server loads the page. the Latter is what you would need for the links to change dynanamically as pages are moved. 

 

You should test the rich text editor link creator to see if it does what you are are needing. If it doesn't or for links that are out side of the editors and menu creators you have 2 options:

  1. get weird with HubL to try and assign link hrefs dynamically
  2. keep a google sheet of links that will need to be updated so you can go through and switch them at launch (this is what I do)

hope that helps. 

- Jonathan Sumner
Regular Contributor

Thanks Jsum.

 

That makes complete sense regarding the [ PageID ]. Thus far my pages have been a mix of copy/paste links in some cases plus the link creator in rich text boxes for some others. I haven't published enough pages to test if the link creator strips the "sandbox" domain elements away automatically using [ PageID ]. I plan to test this asap and I'll report back.


Yes, getting a little crazy with HubL to pull [ PageID ] into each URL could be an option, but perhaps not a practical one in some cases. 

 

For now, I'll simply mark this down as a checklist item to be checked upon launch. Each site needs to go through a thorough QA process anyway so compiling a list of links to swap would simply be part of that launch checklist. There's some hard-coded HTML I'll need to swap links in already so this would be one more step to the link checking process.

 

I'll post my findings on the link creator here once I test a bit further. If the link creator works, the key component there would be to preplan as many pages as you can and create at least placeholders for those pages to use from the link creator as you populate pages with content.

 

Thanks!

Reply
0 Upvotes
Regular Contributor

Okay. When you use the link creator it does NOT automatically update links in rich text boxes. 

 

What HubSpot DOES do when you publish a page is create a redirect from the staging domain link to the live domain link. This means that all links will "technically" work, but of course using a redirect isn't the best method and will slow things down overall for the site. 

 

So, for links in rich text boxes, we'll need to simply update those by hand. It would be a wonderful "add" for the HubSpot dev team to look into a way to update the domain for all links in the staging environment. I'm collecting a list of suggestions that would be helpful for making developing sites as easy as managing them once they're set up.

 

Relative links would eliminate the need to switch the links manually later, but from an SEO perspective, absolute links are preferable. 

 

For now, menu items or other modules that use [ PageID ] can be relied upon to update automatically. All links in rich text boxes need to either be relative links (if SEO isn't a serious concern for the destination page) or updated manually after launch. Once all the links are updated, the redirects in the COS URL Mappings can be eliminated. 

 

I plan to do some testing using a link checking tool after eliminating the COS URL Mappings using something like The Internet Marketing Ninjas SEO Tool

 

Thanks Jsum for your help and insight! 

 

Regular Contributor

When inserting a link into a rich text module the default option is to make the link relative. There may be a way to change this default setting but I haven't dug into the settings to see if that's possible. Absolute links are preferred of course in order to avoid SEO issues, duplicate indexing, spider traps, etc. 

 

Unchecking the "Make links relative" checkbox automatically adds in the full URL and makes them absolute. If this is done in the staging environment it adds the sandbox domain, but if you do this after going live it will adopt the live domain—which is what we ultimately want our absolute URLs to be. 

 

I may use relative links during development so that all the links "technically" work when we go live. I can uncheck the relative checkboxes post launch. It's either that or change all the absolute link domains from staging to live manually. Either way, I have to touch them all. 

 

Using relative links may make for less work overall. Absolute links in staging also create redirects in the COS URL Mappings that point to the absolute links on the live domain. While that avoids dead ends, that's not the best approach.

 

Using relative links in staging and then changing them to absolute post-launch should avoid those redirects and save a couple of steps of work.