colin.irwin

If you have a lot of pages where the only difference is the .php you can use a wildcard /[name].php -> /[name] 301

/history.php -> /history 301 Should do the trick

There was a (relatively) recent update that means now it is very easy to find out which Squarespace template your site is using. Open the Pages panel for your site Scroll to the bottom of the panel. You’ll see the version number I recently updated my blog post with instruction video on how to check your Squarespace version.

Delete your cursor {} rule for the body and use the following instead html { cursor: url(https://mouse-giraffe-2zm7.squarespace.com/s/custom-cursor.svg), pointer; }

What are you trying to achieve with the custom css? It looks there are rules in there to hide the social icon svgs and you're trying to replace them with background image pngs?

The following css will shift the addons below add to cart. .pdp-product-add-ons { order: 4 !important; } Choosing an add on doesn't update the displayed price because: The displayed price is a unit price for the item with selected variants. Changing a variant updates the unit price. Add ons are standalone products, rather than being bundled with the main product.

You could always install Google Analytics and use it to gauge whether LinkedIn or Squarespace's referer statistics are the most reliable.

It would be useful if you could post a link to the page that contains the form.

As mentioned in the first response above, it can take some time for Google to find a new website and then more time for it include results from that site in its index. The .com and .org.uk sites are treated as completely separate entities by Google, so there's a danger that your old site will continue to rank higher than the new one because it has been around longer. To resolve the situation I would do the following: First, install Google Analytics (GA) on your new site. You'll need this later and it's best to do it before you move on to the next step. Second, add the old .com domain name to your .org.uk Squarespace site while ensuring the .org.uk remains as the default domain. This is achieved by changing the DNS settings for your old .com domain as per instructions in Squarespace admin system. This means that your old site is no longer accessible and people trying to access .com will be redirected to .org.uk This is only part of the solution because the page names will be different between the two sites and visitors could be directed from search results to a 404 - Page not available error. Third, look at the landing pages to your new site in the Google Analytics site you set up. 404 errors will show up as page names from the old site. If any of them are getting significant traffice you can set up URL mappings . These URL mappings should point from the page url of the old site to the most relevant page url on the new site For example: /aboutus.html -> /about-us 301 /oldurl -> /newurl 301 When I've done this for some large site migrations we often set up a lot of URL mappings in advance and then check Google Analytics for any that slipped through the cracks. Depending on the level of inbound traffic to the old site from search, links on other sites & blogs, social posts, etc you should be able to set up all the URL mappings you need by initially checking Google Analytics hourly (for busy sites) or daily for most sites. After a few days I would then switch to checking once a week for a couple of weeks. That should trap all the 404s that are getting any significant traffic.

The links to the other language pages don't go anywhere. Shouldn't they go to different pages? If so, adding the correct page links will solve your problem.

It’s not advisable to use unsafe-inline or unsafe-eval because they open up cross site scripting opportunities. See: https://content-security-policy.com/unsafe-inline/ https://www.invicti.com/web-vulnerability-scanner/vulnerabilities/an-unsafe-content-security-policy-csp-directive-in-use/ https://www.iothreat.com//blog/csp-script-src-unsafe-eval

I've had a client's insurers flag up the lack of a CSP. The single domain fix used by @Cinthetic and @mdemartin breaks the editor because the CSP needs to include all domains that provide scripts, media, etc. Effectively, the CSP meta tag is blocking loading of the editing interface. I've experimented with a multidomain CSP meta tag <meta http-equiv="Content-Security-Policy" content="default-src 'self' *.squarespace.com *.squarespace-cdn.com *.squarewebsites.com www.google-analytics.com ajax.googleapis.com www.gstatic.com www.googletagmanager.com static1.squarespace.com"> However, it still breaks sites because inline styles and scripts are blocked by the Content Security Policy and I can't see a way of signalling them as being trusted.

I've been experiencing video banner problems for months on a number of sites. The site in your link shows the same console error as I see. The performance script throws a 500 error. I suspect the performance script includes code for building video backgrounds and retrieving content from Vimeo / YouTube. The only solution I've found (and I'm not certain it's a robust solution) is to upload the videos to the Squarespace site via the video loader. They seem to work that way but video uploading is only part of 7.1 sites.

If you're putting css in a header/footer or page injection point you need to wrap it in <style> </style> tags. <style> //Your css here </style> If you insert the css into to custom css injection point you don't need the style tags.