Jump to content

redirect homepage


jploch
 Share

Recommended Posts

Hey folks,

currently Iam working on a website for one of my clients and I need some advice on how to approach this in PW.
The website is for a company, that offers holiday houses in two locations. 

The client wants the homepage to show the first location. Normally I just have a home template for the first page, but here the URL should reflect that you are in Location 1. So when you visit the URL casamani.com it should redirect to casamani.com/location-1. Not sure if this makes sense at all.

Whould it be bad for SEO and performance reasons to redirect home to the Location-1 page?
Another approach would be to render the Location-1 template on the home template or do an include like discussed here.

Here is how the tree looks:

– Home

– Location 1 (Homepage)
     – Creation
     – Adventure
     – Sustainability

– Location 2 
     – Creation
     – Adventure
     – Sustainability


Thanks for looking into this!

Link to comment
Share on other sites

11 minutes ago, jploch said:

Another approach would be to render the Location-1 template on the home template or do an include like discussed here.

The link above is broken.

  • Like 1
Link to comment
Share on other sites

1 hour ago, jploch said:

Whould it be bad for SEO and performance reasons to redirect home to the Location-1 page?

Not necessarily in a noticeable way, but I'd expect that it would sooner or later bite you in the backside. If another redirect happens for any reason (https upgrade, change in subdomain, etc) beforehand, Google sees two consecutive redirects when accessing / and immediately penalizes you. Outside of web apps, I try to use redirects only for two reasons: either the site moved to a different domain, or the path to a page changed.

1 hour ago, jploch said:

Another approach would be to render the Location-1 template on the home template or do an include

That's the way I would do it. And make sure that you also set a canonical header in your home page that points to the Location-1 page so search engines know to treat them as one page instead of duplicated content.

  • Like 1
Link to comment
Share on other sites

14 hours ago, BitPoet said:

That's the way I would do it. And make sure that you also set a canonical header in your home page that points to the Location-1 page so search engines know to treat them as one page instead of duplicated content.

That will work, exept that the URL for the homepage would be casamani.com and not casamani.com/location-1. 
Or is there any way around this? Not sure Iam thinking it through. 

Link to comment
Share on other sites

1 hour ago, BitPoet said:

Not necessarily in a noticeable way, but I'd expect that it would sooner or later bite you in the backside. If another redirect happens for any reason (https upgrade, change in subdomain, etc) beforehand, Google sees two consecutive redirects when accessing / and immediately penalizes you. Outside of web apps, I try to use redirects only for two reasons: either the site moved to a different domain, or the path to a page changed.

Doing a redirect would be an easy solution. As I understand it, Google allows two redirects without a penalty. The only other redirect that could happen is the http to https or www to non-www. There are no subdomains planned, it's a very small website that is unlikely to grow much in the future. Do you think in this case the redirect would be ok?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By SwimToWin
      BACKGROUND
      SEO matters and so hiding pages behind a "section" is not necessarily good - example:
      Current practice is to show the pages "Foo, Bar, Baz" in a section. https://www.example.com/resources/foo https://www.example.com/resources/bar https://www.example.com/resources/baz For SEO reasons, it's better to show the page at root level like so: https://www.example.com/foo https://www.example.com/bar https://www.example.com/baz PROBLEM: LACK OF ORGANIZATION WHEN ALL PAGES ARE PUBLISHED AT ROOT LEVEL
      This design is fully possible today. However, the root folder becomes disorganized when all pages are published in the root - and the pages tree structure is not of much use when all pages are published in the root.
      SOLUTION: VIRTUAL PAGES TO THE RESCUE
      As a publisher, when publishing many pages that have a root level url, I want to organize my pages below a Virtual Page (that doesn't have a url), so that pages are organized in a Pages Tree Structure (using "Virtual Pages").
      What is a "Virtual Page"?
      Virtual Page can never have a name (Admin -> Page -> Settings -> Name). The Name field is simply blank The Name field is never used in the url for child pages. Virtual Page is a container used to organize other pages. Virtual Page is never shown in the front-end. Virtual Page is shown in the Editing interface only. Virtual Page might have a Template - but the template can only be used in the Admin interface. Virtual Page might have fields (Title, Summary, Text etc.) - but the contents cannot be shown online.
    • By Sanyaissues
      I hadn't developed a website for a while, but here we are. It's a very simple minimalist website to showcase the latest work of Dominican Artist Patricia Abreu Mota.
      Site: https://patriabreu.com
      Modules:
      Procache ❤️ Seo Maestro Profiler Pro Lister Pro ProcessRedirects
    • By Mike Rockett
      Docs & Download: rockettpw/seo/markup-sitemap
      Modules Directory: MarkupSitemap
      Composer: rockett/sitemap
      ⚠️ NEW MAINTAINER NEEDED: Sitemap is in need of developer to take over the project. There are a few minor issues with it, but for the most part, most scenarios, it works, and it works well. However, I'm unable to commit to further development, and would appreciate it if someone could take it over. If you're interested, please send me a private message and we can take it from there.
      MarkupSitemap is essentially an upgrade to MarkupSitemapXML by Pete. It adds multi-language support using the built-in LanguageSupportPageNames. Where multi-language pages are available, they are added to the sitemap by means of an alternate link in that page's <url>. Support for listing images in the sitemap on a page-by-page basis and using a sitemap stylesheet are also added.
      Example when using the built-in multi-language profile:
      <url> <loc>http://domain.local/about/</loc> <lastmod>2017-08-27T16:16:32+02:00</lastmod> <xhtml:link rel="alternate" hreflang="en" href="http://domain.local/en/about/"/> <xhtml:link rel="alternate" hreflang="de" href="http://domain.local/de/uber/"/> <xhtml:link rel="alternate" hreflang="fi" href="http://domain.local/fi/tietoja/"/> </url> It also uses a locally maintained fork of a sitemap package by Matthew Davies that assists in automating the process.
      The doesn't use the same sitemap_ignore field available in MarkupSitemapXML. Rather, it renders sitemap options fields in a Page's Settings tab. One of the fields is for excluding a Page from the sitemap, and another is for excluding its children. You can assign which templates get these config fields in the module's configuration (much like you would with MarkupSEO).
      Note that the two exclusion options are mutually exclusive at this point as there may be cases where you don't want to show a parent page, but only its children. Whilst unorthodox, I'm leaving the flexibility there. (The home page cannot be excluded from the sitemap, so the applicable exclusion fields won't be available there.)
      As of December 2017, you can also exclude templates from sitemap access altogether, whilst retaining their settings if previously configured.
      Sitemap also allows you to include images for each page at the template level, and you can disable image output at the page level.
      The module allows you to set the priority on a per-page basis (it's optional and will not be included if not set).
      Lastly, a stylesheet option has also been added. You can use the default one (enabled by default), or set your own.
      Note that if the module is uninstalled, any saved data on a per-page basis is removed. The same thing happens for a specific page when it is deleted after having been trashed.
          
    • By theoretic
      Hi guys and ladies! And thanks for Processwire!
      It appears i've got an interesting issue concerning the template-settings-based PW redirects dealing with access control. Any PW template has some access control options i.e. "Login redirect URL or page ID to render". If this option is used for a page having a template with this option filled, a redirect will occur if user is not logged in and/or has insufficient access rights.
      I like to hook PW events. In one of my current projects i decided to write an addHookBefore('Session::redirect', ...) which should store the page we are being redirected from. With "regular" redirects like $session->redirect('/somewhere/') this hook works like a charm. But it was strange to see that it doesn't work with the template-settings-based redirect.
      I'm too dumb to dive deep inside PW and to examine the whole PW session mechanism. But it could be rather logical if ANY redirect ( no matter template-settings-based or using $session->redirect() ) could be hooked in the same manner.
      Okay okay i can forget about template-settings-based redirect and write my own. Just a couple of lines of code, and it works. But it's less elegant than hooking the template-settings-based redirects.
      So am i missing something? It this behavior a bug, or is it intended by PW team? Thanks in advance for any comment!
    • By daniel_puehringer
      Hey,

      so we all know about SEO and the importance of performance. Basically we do it, because if no one finds the website we just built, it´s frustrating. We all try to write clean markup, css and js code and most might have a webpack/gulp/whatever pipeline to minimize css&js.
      But when thinking about it, optimizing your pipeline might save you a few (hundreds) of kb, compared to loading an image with 1 mb that´s literally nothing and frankly just ridiculous.

      Don´t get me wrong, frontend pipelines are great and should be used, but let´s shift your "I will optimize the shit out of that 3 css lines" focus to something different: try to serve images as fast as possible, this is where the performance boost really happens.

      I´m no pro on processwire so far, but I built a very easy to use picture element, which some of you could find interesting:

      1. the picture comes with 3 different sizes: one for mobile (keep in mind the double dpi, therefore width of 828px), one for tablet and one for desktop
      2. the picture generates a webp version and the original file extension as a fallback
      3. the filesize of each element is rendered within the "data" attribute
      4. lazy loading(sooo important!!!) is done via the native 'loading="lazy"' attribute.


      Please try it out and see the difference 🙂

      I posted this so others can easily optimize their images, but I would also like to hear your suggestions in making it better. Maybe you could decrease the rendering time or maybe you have some easy improvements.

      Please let me know.

      Greetings from Austria!


       
      <picture> <source data="<?php echo($oElement->repeater_image->width(828)->webp->filesize);?>" media="(max-width: 414px)" srcset="<?php echo($oElement->repeater_image->width(828)->webp->url) ?> 2x" type="image/webp"> <source data="<?php echo($oElement->repeater_image->width(828)->filesize) ?>" media="(max-width: 414px)" srcset="<?php echo($oElement->repeater_image->width(828)->url) ?> 2x" type="image/<?php echo($oElement->repeater_image->ext)?>"> <source data="<?php echo($oElement->repeater_image->width(767)->webp->filesize) ?>" media="(min-width: 415) and (max-width: 767px)" srcset="<?php echo($oElement->repeater_image->width(767)->webp->url) ?> 2x" type="image/webp"> <source data="<?php echo($oElement->repeater_image->width(767)->filesize) ?>" media="(min-width: 415) and (max-width: 767px)" srcset="<?php echo($oElement->repeater_image->width(767)->url) ?> 2x" type="image/<?php echo($oElement->repeater_image->ext)?>"> <source data="<?php echo($oElement->repeater_image->webp->filesize) ?>" media="(min-width: 768px)" srcset="<?php echo($oElement->repeater_image->webp->url) ?>" type="image/webp"> <source data="<?php echo($oElement->repeater_image->filesize) ?>" media="(min-width: 768px)" srcset="<?php echo($oElement->repeater_image->url) ?>" type="image/<?php echo($oElement->repeater_image->ext)?>"> <img data="<?php echo($oElement->repeater_image->filesize) ?>" class="img-fluid" loading="lazy" src="<?php echo($oElement->repeater_image->url) ?>" alt="<?php echo($oElement->repeater_image->description) ?>" type="image/<?php echo($oElement->repeater_image->ext)?>"> </picture>
×
×
  • Create New...