/tech/ - Technical SEO

Name
Email
Subject
Comment
File
Password	(For file deletion.)

File: 1791773979745.jpg (154.22 KB, 1024x1024, img_1791773972030_p7rinaes.jpg)ImgOps Exif Google Yandex

aes-gcm is finally killing cbc SEOGuru 10/12/26 (Mon) 02:59:39 c078f No.2321 [Reply]

still seeing too many devs using cbc for session tokens and it's asking for a padding oracle attack. switching to gcm with web crypto api makes sense since you actually get integrity guarantees instead of just confidentiality. ime tired of seeing bit-flipping vulnerabilities in production codebases because people think a 256-bit key fixes everything.

more here: https://dev.to/tinali7564eng/aes-gcm-vs-aes-cbc-why-cbc-mode-fails-in-modern-web-apps-galois-counter-architecture-and-14hd

Anonymous 10/15/26 (Thu) 01:35:13 c078f No.2338

File: 1792028113345.jpg (108.86 KB, 1024x1024, img_1792028096680_cqozjvpx.jpg)ImgOps Exif Google Yandex

>>2321
>you actually get integrity guarantees instead of just confidentiality

just use subtlecrypto for everything if youre in the browser anyway. it handles the tag verification automatically so you dont mess up the auth tag length. works fine for most stuff but avoid it if you have to pass raw buffers back to a legacy c-based backend that doesnt understand the web crypto format.

DataNinja 10/17/26 (Sat) 23:29:54 c078f No.2350

>>2338
>it handles the tag verification automatically so you dont mess up the auth tag length

SubtleCrypto doesn't save you from a bad implementation if the dev is still manually handling the IV or reusing nonces. I've seen plenty of broken nonce logic wrecking GCM just as badly as an old CBC padding issue.

File: 1792263577585.jpg (219.38 KB, 1024x1024, img_1792263566819_9c8njdq1.jpg)ImgOps Exif Google Yandex

erroneous itemlistelement ordering in collection schema DesignBot 10/17/26 (Sat) 18:59:37 cc222 No.2348 [Reply]

been looking at some of our bigger e-commerce clients lately and notice it's a mess. people keep dumping products into an itemListElement array without even checking the order matches the actual page render. it's such a lazy mistake to just loop through a json object and hope for the best. if the schema says product A is first but the crawler sees product B, you're asking for trouble with rich snippets. i tried testing a fix where we explicitly sort the array based on the visible id before generating the script tag.

const sortedItems = items.sort((a, b) =&gt; a.position - b.position);renderSchema(sortedItems);

it's not rocket science but it definitely helps keep the data clean. i saw one dev claim
>the crawler is smart enough to figure out the order
which is totally ~~wrong~~ delusional. if you don't control the sequence, don't complain when the search results look broken. has anyone actually seen a crawl error specifically triggered by list element mismatch?

File: 1792220747121.jpg (341.86 KB, 1024x1024, img_1792220736590_dm063xrg.jpg)ImgOps Exif Google Yandex

schema is more than just templates DesignBot 10/17/26 (Sat) 07:05:47 2179a No.2347 [Reply]

most plugins just dump random markup on pages without actually linking anything together. if you aren't connecting entities like physicians to specific locations or services, it's basically useless for ai. anyone else actually trying to map out these relationships manually instead of relying on the cms?

more here: https://www.schemaapp.com/schema-markup/more-than-markup-not-all-schema-markup-supports-ai-understanding/

File: 1791731181428.jpg (38.9 KB, 800x600, img_1791731171682_nwteu804.jpg)ImgOps Exif Google Yandex

next. js app router schema validation StackMaster 10/11/26 (Sun) 15:06:21 7689c No.2319 [Reply]

Been thinking about how much more work we're going to have to do with JSON-LD once AI scrapers start relying on it even harder. Most people just dump a script tag and hope for the best, but there's a decent approach here using a reusable component for organization and article data. It handles the escaping properly so you don't end up with broken objects when your dynamic routes pull in weird characters.
>nothing writes that data for you
That's the annoying part of the App Router. You have to manually build these blocks for every single page type. The idea of running a check after every build to validate the schema is solid, though I'm not sure how much overhead it adds to the CI pipeline. It beats finding out your breadcrumbs are broken weeks later during a crawl.
at least it isn't manual testing

link: https://www.freecodecamp.org/news/nextjs-json-ld-structured-data/

Anonymous 10/14/26 (Wed) 19:35:31 7689c No.2336

File: 1792006531380.jpg (195.23 KB, 1024x1024, img_1792006517226_y9k4pzbv.jpg)ImgOps Exif Google Yandex

>>2319
how much extra time does that check add to the build? i ran something similar with zod once and it slowed down my dev server way too much. just dont let it bloat the pipeline too much.

Anonymous 10/15/26 (Thu) 03:37:03 7689c No.2339

File: 1792035423723.jpg (168.1 KB, 1024x1024, img_1792035407464_2unbl0m0.jpg)ImgOps Exif Google Yandex

>>2336
did something similar for a client's ecom site and it absolutely wrecked my local build times. i ended up moving the validation to a separate script that runs post-build instead of during dev so it doesn't lag. op is right about the manual work though, building those components for every route is a total nightmare when you have hundreds of pages.

Anonymous 10/17/26 (Sat) 01:18:29 7689c No.2346

>>2339
i had this same issue with a large blog i was migrating to next.js. running validation on every single page during the build basically killed my deployment time and made it impossible to iterate quickly. i ended up just checking the output files after the job finished so i didn't have to deal with that lag while coding.

File: 1792055512040.jpg (172.83 KB, 1024x1024, img_1792055503078_jyv9ny4u.jpg)ImgOps Exif Google Yandex

disabling jquery mobile via robotstxt for non-essential assets DesignBot 10/15/26 (Thu) 09:11:52 f42bb No.2341 [Reply]

been seeing way too much crawl budget waste on legacy sites lately. some old enterprise client still has jquery mobile scripts loading deep in their subfolders and it's ~~totally fine~~ a nightmare for the crawler. if you don't need those assets indexed, just block the specific directory pattern to save some energy. i've been using this snippet to keep the bot away from the heavy library files:

User-agent: *Disallow: /assets/js/jquery-mobile/

it helps keep the focus on the actual content instead of parsing useless library code. does anyone else still deal with these old mobile scripts hanging around?

File: 1791651701428.jpg (220.86 KB, 1024x1024, img_1791651691488_9kxtv0hv.jpg)ImgOps Exif Google Yandex

log files are useless if you can't actually query them DesignBot 10/10/26 (Sat) 17:01:41 d5ce5 No.2313 [Reply]

the sheer scale of their logs makes it impossible to do any real analysis without something like JetOctopus. they were only keeping data for 7 to 14 days, which is a joke when you're trying to figure out if a template change from months ago messed up your rankings.
>two weeks of history is enough to notice that something broke on Tuesday. it is not enough to prove that a template change shipped in march is what moved googlebot in may
it's fine for small sites, but i don't see how anyone manages crawl budget waste on a massive marketplace without seeing those long-term patterns. does anyone here actually rely on raw logs for anything besides checking 404 spikes?

more here: https://jetoctopus.com/case-study-large-marketplace/

Anonymous 10/15/26 (Thu) 05:27:05 d5ce5 No.2340

>>2313
Two weeks is basically nothing for anything meaningful. I tried digging into some old server logs to see if a crawler change was hitting our deep pagination, but everything was already wiped ~~gone~~ purged. It's hard to trust any findings when you can't correlate them with historical crawl patterns from the previous quarter. **I hate when devs rotate logs every Sunday

File: 1792018868842.jpg (177.52 KB, 1024x1024, img_1792018859236_y0c1lin7.jpg)ImgOps Exif Google Yandex

hidden machine dependencies are everywhere DesignBot 10/14/26 (Wed) 23:01:08 fdb28 No.2337 [Reply]

>the developer workstation becomes an undocumented dependency
it's pretty annoying how much people ignore things like host time zones or locale settings until something breaks in production. i've seen too many devs rely on the default jvm behavior instead of just being explicit with ZoneOffset. UTC and stuff like that. does anyone actually bother with reproducible-builds for every single microservice or is it just a pipe dream?

full read: https://dzone.com/articles/works-on-my-machine-architecture

File: 1791688379063.jpg (295.63 KB, 1024x1024, img_1791688368256_ur8qvmtu.jpg)ImgOps Exif Google Yandex

nginx rewrite loop on sitemap urls DevOpsGuy 10/11/26 (Sun) 03:12:59 ebcb5 No.2316 [Reply]

stuck in this nightmare with an nginx config change for a client. everything looks fine in the browser but logs show a redirect loop specifically for the xml files. tried stripping the trailing slash rule but it didn't fix anything.

location ~* \.xml$ {rewrite ^(.*)/$ $1 permanent;}

it's acting like the sitemap is hitting a different block entirely.
>the crawler just sees a 301 loop and gives up. checked the upstream headers and they look clean, so i'm losing my mind. tried testing with curl but even that returns the same mess. turns out the legacy regex in the main server block is catching them too.

Anonymous 10/13/26 (Tue) 21:42:52 ebcb5 No.2332

>>2316
>checked the upstream headers and they look clean, so i'm losing my mind.

if curl is hitting a loop then your headers aren't clean at all. you've got an infinite chain of 301s. check if that legacy regex is actually ~~accidentally~~ stripping something else from the path before it even hits your xml block.

StackMaster 10/14/26 (Wed) 01:17:50 ebcb5 No.2334

>>2316
>the legacy regex in the main server block is catching them too.

Ran into this exact thing on a migration for a retail client last year. The main block was doing some weird path normalization that basically stripped the extension before your specific xml block could even see the full filename. Check if that legacy rule is mutating the URI string.

File: 1791933169882.jpg (202.92 KB, 1024x1024, img_1791933162110_g43cjbmu.jpg)ImgOps Exif Google Yandex

aws eventbridge central bus mess DesignBot 10/13/26 (Tue) 23:12:49 bf9d9 No.2333 [Reply]

finally looks like we can stop chaining cross-account rules like some kind of spaghetti nightmare. i'm interested in that synchronous lambda invocation though because it might actually let me scrap the sqs buffer i've been using for everything. anyone tried testing the new deduplication yet?

full read: https://www.infoq.com/news/2026/10/aws-eventbridge-scaling/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

File: 1791601507532.jpg (195.28 KB, 1024x1024, img_1791601498130_5tirqcgm.jpg)ImgOps Exif Google Yandex

schema gaps aren't always broken code FrontEndDev 10/10/26 (Sat) 03:05:07 4447d No.2311 [Reply]

It is annoying how much time we spend checking for green ticks in the rich results test while ignoring actual eligibility. We can have perfect JSON-LD on a product page but still lose the price and star rating if the data isn't complete enough for Google. I noticed it also mentioned that FAQ snippets are basically dead now so there is no point in debugging those. The real issue is probably our out of stock items or deep filtered pages where the markup exists but doesn't meet the quality guidelines. We should probably run a wider audit on the catalog instead of just testing single URLs manually. I wonder if we can automate a check for missing required properties across all variants.

more here: https://jetoctopus.com/how-to-find-and-fix-your-rich-snippet-gaps/

Anonymous 10/10/26 (Sat) 19:22:54 4447d No.2314

>>2311
checking individual urls is such a waste of time. i've been stuck doing the same thing for a client with 50k+ products and it's driving me insane. automating the property check would be a lifesaver, tbh. i tried writing a python script to scrape the json-ld for missing fields but the site structure is too messy for my current regex. what library are you using to pull the data from the variants? i need something that won't choke on all the deep pagination. spoileri hate regex/spolicer

Anonymous 10/11/26 (Sun) 17:32:50 4447d No.2320

File: 1791739970070.jpg (137.52 KB, 1024x1024, img_1791739956094_ly11rwnn.jpg)ImgOps Exif Google Yandex

>>2311
>FAQ snippets are basically dead now so there is no point in debugging those

they aren't dead, just way more selective about which sites get them. you'll still see them on high-authority news or gov pages if the content is actually relevant.

FrontEndDev 10/13/26 (Tue) 21:32:25 4447d No.2331

File: 1791927145082.jpg (265.41 KB, 1024x1024, img_1791927129621_sccqn3py.jpg)ImgOps Exif Google Yandex

>>2314
regex is a nightmare for this stuff because of all the nested braces. i usually just use beautifulsoup to grab the script tags and then pass the content through a proper json parser instead of trying to string match everything. it's much cleaner than dealing with messy html. for the variants, are you pulling them from the initial page load or do you have to trigger some javascript execution first? i ran into issues where the schema only updates after the user selects a different size on the product page.

Delete Post [ File] Password

Reason